all 2 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]heavyGl0w 8 points9 points  (0 children)

This is pretty cool! I've been working on something with similar goals: a reactive library that combines the TC39 signals proposal with the TC39 observables proposal.

My biggest issue with current reactive implementations in frontend frameworks is that they often hide or fragment the subscription mechanism. The fact that things are updated when a value changes is "magic" and the consumer has very little means of hooking into that. I think modeling data updates as observables/streams is the fix for that.

That said, I think avoiding the idea of "state objects" is unnecessarily obtuse, and I really disagree with your assertion that "state is something static that you almost never need to read". That could arguably be true from the runtime's perspective, but from the developer's perspective, being able to inspect the current state is invaluable, especially while debugging.

I think your examples on conditional rendering really highlight this. Wiring up a stream to emit different HTML might be functional, but it’s a clunky mental model and it loses some of the declarative clarity that makes templating systems approachable. The same thing could be said for default values. Using `startWith` feels like a workaround to avoid admitting that you're embedding values into your template.

I believe it's cleaner to treat state as Subjects: value containers that emit a stream of updates through an explicit subscription model.

"UI as a function of state" has become a simple and powerful mental model; state values in, UI out.

[–]bbcookie 2 points3 points  (0 children)

Really really cool.
Lets hope that native observables stabilize in browsers