proposal-signals
proposal-signals copied to clipboard
Freezing State
Example:
let state = new Signal.State(0);
state.freeze();
state.set(...) // error! frozen!
kinda mirroring the purpose, intent, and benefits of Object.freeze
.
Could this give us a performance boost if we know some data would stop mutating after a time?
idk.
what do others think?
Critically important if it remains a class; still works nicely with my alternative suggestion in #124 :-)
Frozen signals can indeed provide a performance boost, I use exactly this in oby
.
Basically the general idea is that if you know a signal can never change then there's actually nothing to listen to when calling it. For example my function that creates a computed becomes basically a no-op in that case.
Potentially there are other sort of markers like that that can be useful. If you know that a function is going to be untracked already then likewise you don't need to wrap it in a computed when calling it to preserve reactivity in some places, because you are sure already there will be nothing to react to there directly. For example here by function for making computeds just returns a frozen signal for an untracked function.
Another similar concept is the concept of a boolean signal. Let's say there is a reactive if
statement, we don't actually necessarily care when the potential signals in the condition change, we only care when the entire expression as a whole switches between truthy and falsy, so you create a computed that basically maps that to a boolean, and the trick here is that you also mark it as a boolean signals, so if that signal gets passed to another function that needs to also turn the function into a boolean signal then that function can already see that the function it received is already a boolean signal, which skips another computed there.
There are kind of a lot of tricks that userland implementations with total control over every detail of the implementation can pull.
bikeshedding: prefer close
or settle
over freeze
. one could confuse it with freezing the current value of the signal.
that brings up a good question
- should
freeze
also freeze the underlying value?
I don't think so - anyone with access to the value can do that.