I have absolutely zero idea what your first paragraph even means. It SOUNDS like you want it to violate separations I’m creating on purpose. Templating / view is supposed to hook State, but State is also built for internal tracking and filtering of properties that might not even have, want, or use an associated “view” / Node.

Take a calculator — which is my next example — where you have total, entry, display, totalFlag, and entryFlag on the state. Only the last three would update or be monitored by the DOM, but they themselves would monitor total or entry. Total changes you turn totalFlag on, entryFlag off, and set the display to the total typecasting it to string and number formatting it. Entry changes to turn totalFlag off, entryFlag on, and set the display to exactly what entry says. Display would have a filter to comma format and restrict the output size.

That would be a shit-show if just declaring a property automagically forced an element to exist. It also doesn’t entirely support multiple different Nodes and Elements monitoring ONE state property… which this can do.

As to eventTarget if I send one for every change, It stacks up into a nightmare. If I’m going to have to queue “store” changes in a set anyways to reduce duplication, I might as well brute force all of it.

I could issue an event instead of setTimeout, but I’ve found that to create oddball race conditions. Note that may have just been sloppy event coding on my part… but on the whole I really dislike creating proprietary events for stuff that’s not hardware or user interaction. NOT that setTimeout doesn’t just make an event so…

I’ll have to play with that. Added to my to-do list.