4 ms·

I've submitted a comment on the site but I'll post it here as well: I think this looks neat. However, last time I implemented something like this, I ran acros

I've submitted a comment on the site but I'll post it here as well: 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...

bryhoyt 9y ago
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.