wkeese
commented
8 years ago 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.
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.