Shay Lewis

I think the mental model we want to give here is: - Each time the computation runs, we keep a "trace" (the dependency set) of what signals it read. That's...

I'm trying to understand this use case but I don't think I quite have my head around what you're (hypothetically/previously) trying to achieve. Can I try to rephrase the pieces...

Would you want the watcher callback to be invoked immediately when unblocked, or to just not get notifications from any dependencies dirtied while it was blocked until/unless those dependencies are...

> My understanding of the push-then-pull model is that dirty flags are pushed first through the graph, then only signals which are attached to some watcher endpoints (effects) are then...

So, two things: Some kind of batching process is the norm for UI use cases. The proposal doesn't explicitly need to include this as a named feature because it leaves...

> After re-reading this, I wonder: How does a system which pushes "dirtiness state" down the graph solve for this problem? The watcher will receive a notification that a node...

This API is somewhat less expressive than the current Watcher interface, if `track(fn)` always resets -- it keeps you from being able to incrementally add things to a Watcher without...

On the algorithm: > You can't really do watcher reactions without at least indirect state -> watcher references. Even the polyfill has them indirectly. > > Having each State hold...

I think the "use an extra computed signal" trick exposes basically exactly the performance tradeoff here: if you're willing to hold onto previous values values (at a memory cost) and...

This is definitely worth considering! It would be a bit more flexible and less magical to be able to have multiple signal graphs rather than one global state. On the...