[performance] applying the polyfill in self contained web components with light dom

[tlouisse]

Hi,
as one of the creators of a component library I want to apply this polyfill inside our components (that is, a consumer would load the polyfill and our web component responds to class/attr changes + it calls applyFocusVisiblePolyfill)

The readme states the following code is needed for shadow dom support. If our interactive element lived in shadow dom, this would be sufficient.

if (window.applyFocusVisiblePolyfill != null) {
  window.applyFocusVisiblePolyfill(myComponent.shadowRoot);
}

However, in our situation the interactive element lives in light dom. Thus, we should do within the component:

if (window.applyFocusVisiblePolyfill != null) {
  window.applyFocusVisiblePolyfill(this.getRootNode());
}

See a working example of how this would be applied here: https://webcomponents.dev/edit/NDbZaQP8185CCrMVZ7Rk/src/index.stories.js

Problem here: all siblings will do the same, leading to multiple registrations for the same node.
Would it be possible to make sure the polyfill only handles nodes max 1 time (for instance by maintaing a WeakMap and returning when already handled)?
This way, we can keep our web components self contained (without needing an extra orchestration layer for this) and performant.

Thanks in advance. I hope my explanation is a bit clear :)

[tlouisse]

You could argue of course that it's the responsibility of the parent shadow root to apply the polyfill, but that would not be an easy and straigthforward migration path for our consumers (not as easy as importing a polyfill); it's easily forgotten.

Alternatively, you could recursively apply applyFocusVisiblePolyfill to all shadowRoots found from the document. I don't know what the performance implication would be, but you probably run again into the risk of handling the same root multiple times in case you encounter components already applying this?
Also, you would need to keep track of newly created shadowRoots, so that would probably be undoable (or just way too costly...)