Latest DOM Changes Are Not Reflected in Hook

[athulanilthomas]

I'm using event listeners to track changes like afteredit, aftercopy, and aftermove. I've noticed that when I apply layout changes, the afteredit listener is triggered. However, when I listen for afteredit after a resize, I'm not getting the updated DOM HTML. It seems like the event handler might be firing before the latest HTML is injected into the DOM. Is there an event listener I can use to capture the latest DOM changes in AEM?

[SureshDhulipudi]

Did you get a chance to check 

MutationObserver  - JavaScript API - that allows you to listen for changes in the DOM - Capture real-time updates when authors edit content in the AEM page editor.

[martin_ecx_io]

I've done a quick test of triggering an alert in an afteredit listener and it's visible that the event fires before the DOM is modified.

In the below the Experience Fragment was previously the full width and I resized it smaller - the alert from the listener fires and only after you click ok does the component html update in the DOM.

Are you able to share some info on what your event listener is doing based on these events?

There may be an alternative method to achieve the same, eg registering a MutationObserver directly on the DOM from a clientlib - this would be guaranteed to catch any change to the relevant DOM elements after they happen.  https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver

[athulanilthomas]

The callback I’m attaching to the afteredit listener is quite resource-intensive, as it reinitializes parts of the DOM. For this process, I require the latest DOM structure. Using MutationObserver would trigger updates for every change, which defeats the purpose of the AEM event listeners like afteredit and aftermove. Additionally, if I modify part of the DOM after it has been updated, it will continuously trigger the mutation observer, resulting in an endless loop.

Even if we limit the number of events fired at intervals, there's still a risk of blocking the main thread, which can lead to a poor user experience while authoring.

C.C: @SureshDhulipudi 

[martin_ecx_io]

It sounds like you have quite a complex use case, so it's hard to give a definitive recommendation.  It seems unlikely that the event handlers themselves would get modified to trigger post DOM update.

One potential work around might be to have the afteredit event listener add a mutation observer on the relevant component, then when the DOM updates, the call back could disconnect the observer to avoiding re-triggering, then fire your exisiting functionality.

[athulanilthomas]

In this scenario, the workaround you mentioned will be effective for resizing cases; however, it will not work for edits. This is because the HTML is injected before the observer is initialized, so any subsequent changes are not detected by the observer. As a result, the callback will not be triggered. also we cannot determine whether the event originated from an edit or a resize

[athulanilthomas]

Does anyone have insight into whether this is an architectural oversight or an intended behavior? If it is intended, could someone provide the reasoning behind it? If it is a mistake, will it be addressed in a future release, or are there any open tickets related to this issue ?