proposal-signals
proposal-signals copied to clipboard
Allow `state.set` during `Watcher(notify)`
This is important for composing reactive selectors like:
declare function createSelector<T, U>(
input: Signal<T>, mapper: (isSelected: boolean) => U
): (matchValue: T) => Signal<U>;
const classNameSelector = createSelector(selectedIdSignal, (isSelected) => isSelected ? "active" : "");
const itemClassName = classNameSelector(itemId);
Without it the derived itemClassName
cannot be updated synchronously when selectedIdSignal
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.
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).