adobe / adobe/aem-core-wcm-components

[Architecture] One MutationObserver should be registered, instead of one per component

Open
#458 6 comments 0 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.