Re:HTML UI with Emerj.js: A 60-line Answer to React
by bryhoyt on Wednesday November 22, 2017 @01:12PM
(#15759007)
That's cool. I'd be interested to see your code if you ever run across it again.
Part of the purpose of Emerj is to actually avoid overwriting the current .value of inputs -- the idea is to preserve current element state that isn't represented explicitly in the DOM, so you don't delete something the user has just typed in (or <select>ed or whatever).
I haven't run into issues with classes or types or tables, though. I could imagine the implicit tbody potentially causing problems if you generate a DOM structure yourself without one, but in my case this doesn't matter because I use the browser to parse my HTML into a DOM, and it'll add a tbody.
Nanomorph has code to update live input values from the `value=` attribute, but that's actually something I've deliberately avoided for the above reason.
I think this looks neat. However, last time I implemented something like this, I ran across a few elements/attributes that didn't behave in the simple way I expected.
I can't remember the full list (and can't find my old code), but some things like the "class" attribute, and the "type" attribute of <input> don't like being dynamically changed, at least in all browsers. I think something strange happened with tables as well, and maybe <title>.
So, I ended up needing some special handling for these attributes/elements, in some cases creating a new node with the right attributes and swapping it in.
I don't see anything like this in the Emerj code, so I wonder if it has the same awkward corner-cases. I might go digging to see how DiffDom or DOMDiff or whatever it's called handles it...