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
Consider removing the optimization where delite pauses listening for new Elements added to the document when upgrading custom elements and when calling attachedCallback().
Rationale:
For performance reasons, delite was designed to not monitor Elements added to the DOM during custom element creation, and in a similar vein, Elements added to the DOM during attachedCallback(). The idea was to avoid overhead when custom elements create thousands of child elements, for example a complicated chart widget creating lots of SVG nodes.
This is somewhat confusing to application developers though, since it means that code that runs on Chrome might not run on Firefox or IE. (Albeit, that will always be the case to a certain extent, since the calls to attachedCallback() on IE and Firefox are asynchronous.).
Also, it never worked perfectly, since listening wasn't paused for asynchronous custom element rendering, like for a deliteful/List or Chart widget that gets its data asynchronously from a store and then renders.
Additionally, it's not as important as it used to be, since all modern browsers (even mobile) support MutationObserver, so we only get notification about DOM trees added to the document, rather than notification about every Element within the DOM tree. We do however still call querySelectorAll("custom-element-tag1, custom-element-tag-2, ...") on the DOM trees.
The text was updated successfully, but these errors were encountered:
Hmm, on second thought this might be problematic on page load. For example, deliteful/samples/Buttons.html has about 24 custom element, and on page load the initial parse() call generates 65 mutation records. A lot of those are about text nodes but it's still a bit scary. There's basically a mutation record for every (direct) Element child of a <template>. And on each of those children we need to call querySelectorAll("custom-element-tag-1, custom-element-tag-2, ...") to look for nested custom elements.
wkeese
added a commit
to wkeese/delite
that referenced
this issue
Apr 13, 2016
Consider removing the optimization where delite pauses listening for new Elements added to the document when upgrading custom elements and when calling
attachedCallback()
.Rationale:
For performance reasons, delite was designed to not monitor Elements added to the DOM during custom element creation, and in a similar vein, Elements added to the DOM during
attachedCallback()
. The idea was to avoid overhead when custom elements create thousands of child elements, for example a complicated chart widget creating lots of SVG nodes.This is somewhat confusing to application developers though, since it means that code that runs on Chrome might not run on Firefox or IE. (Albeit, that will always be the case to a certain extent, since the calls to
attachedCallback()
on IE and Firefox are asynchronous.).Also, it never worked perfectly, since listening wasn't paused for asynchronous custom element rendering, like for a deliteful/List or Chart widget that gets its data asynchronously from a store and then renders.
Additionally, it's not as important as it used to be, since all modern browsers (even mobile) support
MutationObserver
, so we only get notification about DOM trees added to the document, rather than notification about every Element within the DOM tree. We do however still callquerySelectorAll("custom-element-tag1, custom-element-tag-2, ...")
on the DOM trees.The text was updated successfully, but these errors were encountered: