> ``` const template = document.getElementById("templates-materialization-base").content;
this.appendChild(template.cloneNode(true)); ```
It was pointed out to me that `this.appendChild(document.importNode(template))` is faster due to "adoption" (`importNode` clones and adopts the nodes for the current document at the same time/single tree walk, saving appendChild from having to do a separate adoption pass/tree walk; template.content exists in a fake separate document so the nodes need to be "adopted" by the current document).
Which is a point in favor of the current complexity of the JS API for working with templates. I agree that "HTML Modules" would be nice to have and more declarative template usage that doesn't require the Shadow DOM would be lovely. Both are still proposed standards going through various debate cycles.
> making it so that you have to have to make a more complex "update_render" function to work around that
One potential simplifying answer when trying to deal with batched updates to attributes is a simple "dirty flag" and requestAnimationFrame callback as your "update_render". Most things changing more than one attribute at a time are likely going to do it all between animation frames and even if they can't, rAF provides other throttling that prioritizes user interaction.
There's still complexity in that approach, but it is isn't as complex as trying to build a throttling timer.
> I usually have a function `_set_handlers(boolean)` that is used on connected and disconnected callback but this is just plain js organisation:
It looks like you could replace some or most of your `_set_handlers` function by implementing `handleEvent(e)` for the Web Component. It's an auto-registered/unregistered handler at the component level of the event bubble.
this.appendChild(template.cloneNode(true)); ```
It was pointed out to me that `this.appendChild(document.importNode(template))` is faster due to "adoption" (`importNode` clones and adopts the nodes for the current document at the same time/single tree walk, saving appendChild from having to do a separate adoption pass/tree walk; template.content exists in a fake separate document so the nodes need to be "adopted" by the current document).
Which is a point in favor of the current complexity of the JS API for working with templates. I agree that "HTML Modules" would be nice to have and more declarative template usage that doesn't require the Shadow DOM would be lovely. Both are still proposed standards going through various debate cycles.
> making it so that you have to have to make a more complex "update_render" function to work around that
One potential simplifying answer when trying to deal with batched updates to attributes is a simple "dirty flag" and requestAnimationFrame callback as your "update_render". Most things changing more than one attribute at a time are likely going to do it all between animation frames and even if they can't, rAF provides other throttling that prioritizes user interaction.
There's still complexity in that approach, but it is isn't as complex as trying to build a throttling timer.
> I usually have a function `_set_handlers(boolean)` that is used on connected and disconnected callback but this is just plain js organisation:
It looks like you could replace some or most of your `_set_handlers` function by implementing `handleEvent(e)` for the Web Component. It's an auto-registered/unregistered handler at the component level of the event bubble.