Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(stable-selector): dispatch event with shadow DOM #10087

Conversation

IgnacioBecerra
Copy link
Contributor

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.

<dds-card get-shadow-dom></dds-card>

in document:

  window.addEventListener('dds--card', (e) =>
    console.log((e as CustomEvent).detail.shadowDOM)
   // do stuff with it
  );

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.

          exampleCard.dispatchEvent(
            new CustomEvent('edit-heading', {
              bubbles: true,
              composed: true,
              detail: {
                elementTarget: 'dds-card-heading',
               newText: 'this is a new heading'
              },
            })
          );

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

  • {{new thing}}

Changed

  • {{changed thing}}

Removed

  • {{removed thing}}

@ibmdotcom-bot
Copy link
Contributor

@ibmdotcom-bot
Copy link
Contributor

@ibmdotcom-bot
Copy link
Contributor

@ibmdotcom-bot
Copy link
Contributor

@andy-blum
Copy link
Contributor

Due to AEM having a hard time accessing the shadow DOM

I'm curious what you mean by this. Is the AEM software having a hard time accessing this or is it the AEM developers? Why is that information needed?

Also do they need a reference to every instance of the Shadow DOM or just a vague idea of what the render functions put out? If you only need one per class, that kind of information could get wrapped up when the component is defined as part of #10080

@jeffchew
Copy link
Member

I'm curious what you mean by this. Is the AEM software having a hard time accessing this or is it the AEM developers? Why is that information needed?

Also do they need a reference to every instance of the Shadow DOM or just a vague idea of what the render functions put out? If you only need one per class, that kind of information could get wrapped up when the component is defined as part of #10080

This is in reference to a request from the Adobe Target team. This issue was originally brought up and closed:
#9630

This request is being brought up again.

@kennylam
Copy link
Member

kennylam commented Mar 3, 2023

@IgnacioBecerra this can probably be closed, since we're going to be taking a different approach with the Target team?

@IgnacioBecerra IgnacioBecerra deleted the aem-render-event branch March 3, 2023 22:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants