Expose AutomationOption Setter for ChildSite

[vineethkuttan]

Description

#15611 This PR removed fragment based automation for content island that is connected using childsite.
This PR is exposes the automation option setter in builder.

Type of Change

Erase all that don't apply.

• Bug fix (non-breaking change which fixes an issue)

Why

This will make sure that other content island which will connected in childsite can customize their automation option

What

• Exposed the getter which set will set the childsite automation

Screenshots

xamlws.mp4

Testing

Tested in the SampleFabricApp

Changelog

Should this change be included in the release notes: yes

Expose AutomationOption Setter for ChildSite

Microsoft Reviewers: Open in CodeFlow

[acoates-ms]

We shouldn't be adding Xaml specific code like this.
The xaml case indicates that different controls may require FragmentBased or FrameworkBased automation options. I imagine a custom WPF control, if WPF adds support for ContentIslands would also want framework based. One option would be to add a property to the build to specify which you want. Alternatively, we could expose a getter for the ChildContentLink, so that the custom control can customize it as desired.

[vineethkuttan]

We shouldn't be adding Xaml specific code like this. The xaml case indicates that different controls may require FragmentBased or FrameworkBased automation options. I imagine a custom WPF control, if WPF adds support for ContentIslands would also want framework based. One option would be to add a property to the build to specify which you want. Alternatively, we could expose a getter for the ChildContentLink, so that the custom control can customize it as desired.

@acoates-ms exposed the setter for ChildSite Automation

[sundaramramaswamy]

Signed off with comments. Please handle them.

[sundaramramaswamy]

Why is this an optional? Is it because ContentAutomationOptions::None can be set by the 3P module and we want to differentiate that case from not being set all?

[vineethkuttan]

Yes Sundaram. Since it is enum class , it will have default value which is None. So added optional to differentiate that case from not being set at all.

Or I may need to set the default value as frameworkbased in the contructor.

[sundaramramaswamy]

Suggested change

	if (m_builder && m_builder->ContentIslandChildSiteAutomationOption().has_value()) {
	automationOption = m_builder->ContentIslandChildSiteAutomationOption().value();
	}
	if (m_builder->ContentIslandChildSiteAutomationOption()) {
	automationOption = *m_builder->ContentIslandChildSiteAutomationOption();
	}

1. Can m_builder ever be nullptr within the lifetime of this object? If yes, then won't every usage of this member variable be starting with a if (m_builder) check? That would be unperformant, ugly and noisy, yes?

2. std::optional::operator bool automatically does what has_value() does. Excerpt from std::optional:

When an object of type optional is contextually converted to bool, the conversion returns true if the object contains a value and false if it does not contain a value.

3. operator* returns the value within.

---

Even better is to use std::optional::or_value which gives the value if there's a value else defaults to whatever you pass it.

  const winrt::Microsoft::UI::Content::ContentAutomationOptions automationOption = m_builder->ContentIslandChildSiteAutomationOption().value_or(winrt::Microsoft::UI::Content::ContentAutomationOptions::FrameworkBased);

Shorter, cleaner and clearer to read, no? As a bonus since you initialize the variable in one statement, it can be qualified const now.

Moral: It helps to read the documentation and many things are perhaps already done for you. You just have to use them, for that you've to know them.