Yes, I want to mention, since I was up-thread, it is solved but not all tooling or environment are setup for that.

When the app is small you likely don't need it. And then it grows and you absolutely do.

It's better, in greenfield to use framework/tooling that is ready for it.

Good to hear you found it solved!

> It's better, in greenfield to use framework/tooling that is ready for it.

I don't really agree. Tooling, and even more so, Frameworks, come with giant trade-offs. Some are "paint-in-a-corner" trade-offs. So I would caution against pulling in a framework just to solve potential future issues. So much so, that I think it is one of the top10 things that will cause your project or startup to fail or get into serious trouble. It's really a form of "premature optimization".

In fact I solved a similar issue in my JS reactive micro library in just 500 bytes: https://github.com/jbreckmckye/trkl

I was not aware of trkl. Well done! I wrote rmemo (Reactive Memo) which solves the same problems & is a similar size. Different semantics though.

https://github.com/ctx-core/rmemo

Nanostores is also small https://github.com/nanostores/nanostores.

And if you only need reactivity in the browser (not server side), VanJS is small & includes reactive primitives. https://vanjs.org/

That looks great! Thanks for sharing!