You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 9, 2019. It is now read-only.
You can use it to keep track of all nodes with data-epi-property-name, even if they are dynamically added. It can also monitor for changes to data (Like if it's changed with content-editable), but i think reading the value when opening the overlay would make sense/reduce the performance overhead.
Very basic example of how MutationObserver could detect changes:
The text was updated successfully, but these errors were encountered:
Yes you are correct, the problem could be solved with mutation observers. I actually did a proof of concept on this over a year ago. Unfortunately it has never made it into the product.
With regards to JP's blog post I'm not really sure why it was decided to publish an event. I'm guessing it was an approach that required less changes in our core editing classes. Also, to keep consistency with the previous changes that have been done in this area.
It handles calling the event described in JP's blog post. Maybe not exactly what you had in mind but I don't think we will be moving this into the product just yet.
Reading https://world.episerver.com/blogs/john-philip-johansson/dates/2017/12/taking-more-control-of-client-side-rendering-in-ope-beta2/ i'm wondering if the detection couldn't be solved by using a MutationObserver.
You can use it to keep track of all nodes with
data-epi-property-name
, even if they are dynamically added. It can also monitor for changes to data (Like if it's changed withcontent-editable
), but i think reading the value when opening the overlay would make sense/reduce the performance overhead.Very basic example of how MutationObserver could detect changes:
The text was updated successfully, but these errors were encountered: