Open robbiespeed opened 1 month ago
IMHO, state.set
shouldn't be restricted at all in the watcher. Not if you block the watcher correctly.
Only time it even could make sense IMHO is when executing a Computed
that depends on it. But even that has a use case: making the computed dirty after its .get()
could be used by a caller tracking dirtiness to, say, loop back and re-invoke it after processing the return value. (This could be used to implement multiple renders, for example.)
For reference, just noticed this is optional in the Angular implementation (from which this proposal's current polyfill seems to be copied).
This is important for composing reactive selectors like:
Without it the derived
itemClassName
cannot be updated synchronously whenselectedIdSignal
changes. This can lead to triggering 2 successive renders vs 1.Allowing this should be possible without risk of corrupting the signal graph, since it can only mark more nodes dirty.