You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of the heavy work in the Signal graph is done in what I am calling "protocol functions", and a common interface.
If these protocol functions were exposed to JS, then implementations with varying behavior could be implemented.
One goal here is that an implementation of State, Computed, and Watcher could be implemented in JS, with only minor performance degradation, as most of the graph logic would still be handled in native code.
This would allow the spec to remain narrow in scope while still allowing variations by users for efficiency.
As an example of this, imagine a reactive node that starts out as one value, and may eventually change to a different value, but once it changes once it will never change again. If appropriate protocol functions were exposed, then a compliant implementation could look like this:
exportclassReactiveOneShot<T>implementsReactiveProducer<T>{publicvalueVersion=1;publiccheckForActuallyChangedValue(): void{// Do nothing. We know exactly when we have changed.}
#flipped =false;
#value: T;constructor(value: T){this.#value =value;}publicget(){if(!this.#flipped){Signal.protocol.producerAccessed(this);}returnthis.#value;}publicshoot(finalValue: T){if(!this.#flipped){this.#flipped =true;this.#value =finalValue;++this.valueVersion;Signal.protocol.producerNotifyConsumers(this);}else{thrownewError('ReactiveOneShot already finalized');}}}
While this example is possible without any of the protocol being exposed, it requires creating and (hopefully) throwing away a bit more memory:
Most of the heavy work in the Signal graph is done in what I am calling "protocol functions", and a common interface.
If these protocol functions were exposed to JS, then implementations with varying behavior could be implemented.
One goal here is that an implementation of
State
,Computed
, andWatcher
could be implemented in JS, with only minor performance degradation, as most of the graph logic would still be handled in native code.This would allow the spec to remain narrow in scope while still allowing variations by users for efficiency.
As an example of this, imagine a reactive node that starts out as one value, and may eventually change to a different value, but once it changes once it will never change again. If appropriate protocol functions were exposed, then a compliant implementation could look like this:
While this example is possible without any of the protocol being exposed, it requires creating and (hopefully) throwing away a bit more memory:
The text was updated successfully, but these errors were encountered: