Question: why does this test pass?

[emilefokkema]

I was comparing the algorithm with this test and I encountered something I didn't understand. I hope someone can help me understand.

What happens in the test is:

• there is a Signal.State
• there is a Signal.Computed whose computation uses above Signal.State
• the Signal.Computed's get() is called, which leads to a get() on the Signal.State, but because none of this is watched, the Signal.Computed is not added to the sinks of the Signal.State (as per this rule).
• Now the Signal.State's set() is called, but because it (i.e. the Signal.State) has no sinks, nothing happens. The Signal.Computed is not notified in any way.
• Now the Signal.Computed's get() is called again, but because it (i.e. the Signal.Computed) does not know that any of its sources are dirty, it considers itself clean and does not re-run its computation callback
• And yet the callback is expected to have run again!

Am I missing something?

[DavidANeil]

I have been reading the spec as it is in the README and I can't find where it describes this, so your confusion is warranted.

How it works (to my best understanding) is that, if a computed has no sinks then it never becomes ~clean~. I think the state transition from ~computing~ to ~clean~ is replaced with a transition from ~computing~ to ~checked~. The transition from ~checked~ to ~clean~ is removed.
This means that--for a dependency graph with no sinks--each value read requires a full traversal of the entire dependency tree to figure out if the cached value can be re-used.

This is sped up in some cases by using a global "generation" number that is incremented whenever any state value is updated. This allows subsequent reads without any sets to be much faster.

[emilefokkema]

@DavidANeil Thanks for helping me figure this out. Would you agree that the algorithm in the README should maybe be updated to specify exactly how that global "generation" should be used? I'm talking specifically about the Signal.State.prototype.set(newValue) section and the "finding deepest computed that needs recomputation" part.

[DavidANeil]

I think in general most of the README was written assuming that all nodes were always live, and then that was changed to allow for unwatched nodes, but not done perfectly.

I'm not an official champion of this proposal, so I don't have any authority, but I guess that they would generally be thankful for PRs that make the algorithm descriptions more accurate.