adobe / adobe/aem-core-wcm-components
[Architecture] One MutationObserver should be registered, instead of one per component
- Dominant language
- Java
- Stars
- 795
- Forks
- 775
- Avg merge
- 3d 22h
- Merged PRs (30d)
- 8
Description
Every core component could have a clientlibrary associated with it, that should contain code to instantiate the JS/dynamic part of the component.
I noticed that a MutationObserver pattern is introduced to handle the situation where a component is being edited through a dialog (and then saved), or when a component is inserted dynamically for whatever reason.
This pattern is a pretty good solution: It nicely fulfills all the use-cases where a component instantiation is required.
However, I have seen that per component a MutationObserver is registered, instead of just one MutationObserver that delegates the calls (for example through events?) to the various components.
This has a performance impact: The more components we create that leverage this pattern, the more MutationObservers (that receive the exact same events, but handle different elements) get triggered!
So I propose to create a generic MutationObserver that can get information about which elements are added (and removed?!) from the page, allowing their components to handle those cases, by subscribing to events for them.
WDYT? I'd like to discuss a little bit about the implementation that we'd like to create here. I can provide a PR, together with my colleague, but then we first need to get the solution clear. :)
FYI: I'm talking specifically about the pattern being used here: https://github.com/adobe/aem-core-wcm-components/blob/657d593626c665042f675c3c7a579b3ba0db45ca/content/src/content/jcr_root/apps/core/wcm/components/form/text/v2/text/clientlibs/site/js/text.js#L131
Contributor guide
Research direction
Start with content/src/content/jcr_root/apps/core/wcm/components/form/text/v2/text/clientlibs/site/js/text.js at the MutationObserver pattern cited in the issue. Review how components currently register observers and determine the event or delegation design before changing it. Done means a shared observer can report added or removed elements to subscribing components without one observer per component.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend, performance
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100