Daniel P H Fox

The first hurdle I see is that right now, the order of in which dependents are traversed during `updateAll` is undefined because Fusion uses `{[T]: true}`-style sets to store dependents...

Another consideration I'll add onto the above; if we're making dependencies ordered, could potentially also solve a related problem/unintuitive syntax where, in the following snippet, `alwaysTrue` might still observe `false`,...

That sounds awfully like #144! Perhaps lazy execution helps with correctness :o

The problem here is that creating the state object immediately calculates it, right? As far as my understanding of this issue has internalised, this issue wouldn't exist if the only...

I've been busy with non-Fusion work. State objects are next on my list to work on after my current tasks are done.

GVD semantics for Computed/ForKeys/ForValues/ForPairs/similar objects seem to be that the user code remains the owner of the values that the user generates at all times. Right now this is expessed...

Worth mentioning in addition to the above that #184 observed that adding destructors to Value objects did not seem to add any developer experience value. Perhaps the reason why is...

I'm rather inspired by https://docs.rs/reactive-signals/0.1.0-alpha.4/reactive_signals/struct.Scope.html at the moment. It is an idly interesting idea to introduce a scoping syntax that manages a cleanup table using a managed type, so you...

It could be interesting to mandate that users pass in a cleanup table whenever they construct an object - effectively serving as a nudge to make sure the objects they...

Here's an interesting idea: the biggest ergonomic issue with scopes like this is the same as the problem many people face right now with prop drilling in components. It's tedious...