[Proposal] Temporarily switch fluent web components to use closed shadow dom

[EisenbergEffect]

Describe the feature that you would like added

At present, all web components defined in the fluent web components package create their shadow dom in open mode. We propose temporarily switching this to closed mode.

Why closed mode? In working with some partner teams, we've seen that the incorporation of telemetry libraries presents some challenges with determining what element triggered a given action. For example, while a fluent-button may have triggered an action semantically, it may have originated from a native button within its shadow dom. When building larger web component experiences, telemetry libraries need to inspect the composedPath for an event in order to find the true origin, but the library cannot differentiate between what we want the origin to be (fluent-button) and the internal implementation detail (button). By moving the fluent web components to closed mode, the button will no longer exist within the composedPath and telemetry libraries will be able to use this API to accurately determine the the element to record.

Why temporary? As a practice, the community tends to avoid closed shadow dom mode. So, we'd really like our components to use open mode long term. Unfortunately, in order to meet our requirements, we need to default to and "hard code" things to closed mode today. However, over the next 2-3 months we'll be implementing a new provider model in FAST. This new model will allow the consumer to control more aspects of the registered web components in the library. Through this new API we can allow partners to opt into closed mode if they have a situation that requires it. So, when we land the new provider model, we would switch the components back to open mode by default, thus re-aligning with community practices, while enabling control for individual consumers.

What component or utility would this be added to

This would be a config code change within the web components package.

Have you discussed this feature with our team, and if so, who

This has been discussed within the FAST team and with several members of a partner team who reported the issue. We'll be running a test next week to ensure that moving to closed mode does not cause any issues. We do not anticipate anything at this point. Pending the successful completion of that test and if there is no strong pushback from the community, we'd like to move ahead quickly with this. Again, remembering that this is temporary and will switch back to open mode once we've got the new provider API in place.

[chrisdholt]

Thanks @EisenbergEffect - I think this should be reasonable and appreciate the agreement and call out to rolling this back once the new provider work in FAST is supported. So long as there are no unexpected side-effects, I think we'll be fine to implement this temporarily.

[msft-github-bot]

🎉This issue was addressed in #15382, which has now been successfully released as @fluentui/[email protected].:tada:

Handy links:

• Release Notes
• Official NPM Release

[EisenbergEffect]

@chrisdholt @awentzel Once we've got the Beachball integration on our FAST repo, I think it would be great to incorporate this msft-github-bot as well. It's very nice having an automated comment that links the release that the issue was addressed in. Bonus for the release notes links.