The epic event-driven browser language for UI with functionality in one-liner CSS. Over 100 incredible CSS commands for DOM manipulation, ajax, reactive variables, single-page application routing, and lots more. Could CSS be the JavaScript framework of the future?
Just tracked down a mysterious error, where the draw event was firing twice and for the life of me this afternoon I couldn't work out what was going on.
It turns out that when you do a querySelectorAll, it drills into template tags and gives you elements that aren't actually in the visual DOM. Doh. I'd not realised that - I thought template tags acted like their own DOM, but obviously not. They should be self-contained and unqueryable unless specifically requested - thinking logically - but I'm sure there's a equally perfect and logical reason why they aren't that I don't know about yet.
So my actually drawn element, which comes from a template, was firing the draw event on initialisation, and the one in the template was firing as well, except it wasn't even technically on the DOM.
It was very confusing, as things looked like they were happening once on the screen, but whenever I consoled, I got a result twice, and when I consolled the element the second draw event was firing on, I was getting what I thought was the same element. Of course, it was the same element, but an undrawn version of it from the template. I only worked it out by drilling into the document and confirming by consoling the parentNode, which happened to be the template tag for the second element. It was a 2 minute fix after that.
So the solution is that for draw events, I'm now using querySelectorAll(":not(template )") everywhere where draw events need to fire which solves it (plus some other things of course).
It's done off line and will go up with with 2.6.0 branch. It's worth noting this for further uses of querySelectorAll, and I'm going to check wherever I use this to see if there is anywhere else something might be wasting time on elements from template tags. But the bugs are fixed as far as I know.
bob2517
commented
3 years ago
Just tracked down a mysterious error, where the draw event was firing twice and for the life of me this afternoon I couldn't work out what was going on.
It turns out that when you do a querySelectorAll, it drills into template tags and gives you elements that aren't actually in the visual DOM. Doh. I'd not realised that - I thought template tags acted like their own DOM, but obviously not. They should be self-contained and unqueryable unless specifically requested - thinking logically - but I'm sure there's a equally perfect and logical reason why they aren't that I don't know about yet.
So my actually drawn element, which comes from a template, was firing the draw event on initialisation, and the one in the template was firing as well, except it wasn't even technically on the DOM.
It was very confusing, as things looked like they were happening once on the screen, but whenever I consoled, I got a result twice, and when I consolled the element the second draw event was firing on, I was getting what I thought was the same element. Of course, it was the same element, but an undrawn version of it from the template. I only worked it out by drilling into the document and confirming by consoling the parentNode, which happened to be the template tag for the second element. It was a 2 minute fix after that.
So the solution is that for draw events, I'm now using querySelectorAll(":not(template )") everywhere where draw events need to fire which solves it (plus some other things of course).
It's done off line and will go up with with 2.6.0 branch. It's worth noting this for further uses of querySelectorAll, and I'm going to check wherever I use this to see if there is anywhere else something might be wasting time on elements from template tags. But the bugs are fixed as far as I know.