`watcher.watch(signal)` and `Signal.subtle.watched` callback when signal is not up to date

[divdavem]

Hello,

I am opening this issue because while trying to implement the proposal based on our tansu signal library, I came across a question that I mentioned very quickly with @NullVoxPopuli in one of the Zoom community meetings some time ago but that I had not formally reported, so I am doing it here.

Basically, as far as I understand the proposal, it is possible to call watcher.watch(signal) even if signal is not up to date.
This will synchronously call the Signal.subtle.watched callbacks on all dependent signals:

const a = new Signal.State(true);
const b = new Signal.State('b', {
  [Signal.subtle.watched]: () => console.log('b watched'),
  [Signal.subtle.unwatched]: () => console.log('b unwatched'),
});
const c = new Signal.State('c', {
  [Signal.subtle.watched]: () => console.log('c watched'),
  [Signal.subtle.unwatched]: () => console.log('c unwatched'),
});
const d = new Signal.Computed(() => (a.get() ? b.get() : c.get()));
console.log(d.get()); // displays 'b'
a.set(false); // now d is outdated, it has to be recomputed
const watcher = new Signal.subtle.Watcher(() => {});
watcher.watch(d); // displays 'b watched' (but if d was up-to-date, it would not watch b but c)
console.log(d.get()); // displays 'b unwatched', 'c watched', 'c'

As shown in the previous example, this leads to call the Signal.subtle.watched callback on some signals that would no longer be used if the signal was up to date.

Of course, we could consider that it only makes sense to call watch on up-to-date signals.

But, as reported in #227, I am in favor of also calling the Signal.subtle.watched and Signal.subtle.unwatched callbacks when reading the value of dependent signals.

In this case, calling get before calling watch would call the Signal.subtle.watched and Signal.subtle.unwatched callback twice.

Should watcher.watch also update the signal in a single operation ?
(For info, I have implemented this suggestion with tansu here)

[divdavem]

Note that the signal being watched while not up-to-date, also leads to the fact that a change to some of the no longer used signals triggers the notification:

const a = new Signal.State(true);
const b = new Signal.State('b', {
  [Signal.subtle.watched]: () => console.log('b watched'),
  [Signal.subtle.unwatched]: () => console.log('b unwatched'),
});
const c = new Signal.State('c', {
  [Signal.subtle.watched]: () => console.log('c watched'),
  [Signal.subtle.unwatched]: () => console.log('c unwatched'),
});
const d = new Signal.Computed(() => (a.get() ? b.get() : c.get()));
console.log(d.get()); // displays 'b'
a.set(false); // now d is outdated, it has to be recomputed
const watcher = new Signal.subtle.Watcher(() => {
  console.log("notified!")
});
watcher.watch(d); // displays 'b watched' (but if d was up-to-date, it would not watch b but c)
b.set('b2'); // displays 'notified!' even though this change is not relevant

[R2D221]

I'm facing a similar issue while trying to implement the spec in my personal component library.

The question I have is, shouldn't watcher.watch(computed) ensure the computed is clean? That is, shouldn't it evaluate it synchronously?

The spec doesn't say it should, but I found out that when I create a component, if I just watch the attribute computeds, I end up with an empty component that will only be filled after the next render. So, understandably, the effect I implemented calls computed.get() immediately before watching it... but I can't think of a scenario where I would need to watch a computed without evaluating it.

I think this bug report shows that watching a dirty computed is actually undefined behavior per the current spec.