You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently, the community has been exploring practical uses of scoped element registries more. A number of situations have arisen that seem to indicate a potential deficiency in the current API surface. Some scenarios include:
Setting innerHTML on a detached element, where a specific registry should apply.
Integrating with a 3rd party framework (e.g. React) that creates elements without knowledge of the appropriate registry.
Existing web components, libraries, and frameworks that don't/can't easily plumb through custom registries into their systems.
The consensus seems to be that none of these scenarios are blockers to the current proposal, but that they do represent key use cases that we should have a reasonable solution for.
Strawman
One potential solution is to provide additional APIs that explicitly control the registry scope in which code runs. For example, we could add something like:
document.runWithScope(registry, callback) - Synchronously invokes the callback, ensuring that all element creation and upgrades use the specified registry.
document.runWithoutScope(callback) - Synchronously invokes the callback, ensuring that no element created will be upgraded, regardless of whether it is defined in the global registry.
Feedback Request
I'd love to get feedback on the use cases and applicability of an API like this. Let's try to avoid bike shedding on the name and where the API lives (I'm not super happy with that myself actually). I think we can figure that out later if we determine first that we want something like this, how it would work, and whether it's feasible for browser implementors.
The text was updated successfully, but these errors were encountered:
For the 3rd party framework case, this seems possibly more powerful than would would strictly be needed since: (1) the main issue is interaction with the global registry not arbitrary ones, and (2) it might be feasible to limit special behavior to disconnected elements.
Here's a strawperson of what conceptually might mostly work:
And in the strawperson-ing spirit, this would be something like:
3. Let registry be document's relevant global object's CustomElementRegistry object.
3. Let registry be...
a. the last registry on the `runWithScope` registry stack
b. or if that is null, the creating context node's root node's registry
c. or if that is null, the document's relevant global object's CustomElementRegistry object.
Background
Recently, the community has been exploring practical uses of scoped element registries more. A number of situations have arisen that seem to indicate a potential deficiency in the current API surface. Some scenarios include:
innerHTML
on a detached element, where a specific registry should apply.The consensus seems to be that none of these scenarios are blockers to the current proposal, but that they do represent key use cases that we should have a reasonable solution for.
Strawman
One potential solution is to provide additional APIs that explicitly control the registry scope in which code runs. For example, we could add something like:
document.runWithScope(registry, callback)
- Synchronously invokes the callback, ensuring that all element creation and upgrades use the specified registry.document.runWithoutScope(callback)
- Synchronously invokes the callback, ensuring that no element created will be upgraded, regardless of whether it is defined in the global registry.Feedback Request
I'd love to get feedback on the use cases and applicability of an API like this. Let's try to avoid bike shedding on the name and where the API lives (I'm not super happy with that myself actually). I think we can figure that out later if we determine first that we want something like this, how it would work, and whether it's feasible for browser implementors.
The text was updated successfully, but these errors were encountered: