feat(stable-selector): dispatch event with shadow DOM #10087
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related Ticket(s)
None.
Description
Due to AEM having a hard time accessing the shadow DOM, this PR creates a new event that dispatches on component render if any component has a
get-shadow-dom
attribute, containing the shadowDOM as an event detail. This will make it easier to retriever and modify the shadow DOM through the program by listening to the events on load.in document:
As an example, you can open the console in the default Card story to see that the shadow DOM element will be retrieved through listening to the event. We could also add more data to be sent through this event, if needed. Likewise, we could limit the elements retrieved through the event by scoping the query instead of the whole shadow DOM (e.g. only retrieving
.bx--card__wrapper
instead).Another idea is to add event listeners to certain components that would directly modify certain elements, so when a user dispatches events, the component will modify things directly on the component's side.
While this could probably be "easier" on adopters, there might not be a way to generalize this behavior, and worst case scenario we'd have to do this on a case by case basis, which we'd have to take into account if there are ever breaking changes.
The first solution might be a more general one, and provides the shadow DOM to the adopters.
Changelog
New
Changed
Removed