41–50 of 64 posts
Earlier quoted context omitted.
First-class signals came from functional reactive programming back in 1997. Even JS implementations of signals existed before React's hooks.
These "signals" don't seem like FRP signals (which are time-varying values, like a "signal" to an EE but not limited to real numbers) but more like Qt signals or MVC "model has updated" notifications.
This article is completely backwards. We do not want to manually manage what-gets-refreshed-when. The whole point of React was to react to state changes automatically.
It isn't, given that React requires you to provide an array of dependencies when using useMemo and useEffect. The point of React is to automatically update the DOM when a virtual DOM tree gets modified.
Preact signals are far superior to other state management patterns for react, but don't use a ContextProvider as shown is this article, pass the signals as props instead. e.g: function MyComponent({ disabled }: { disabled: Signal }) { // ... }
function MySubComponent({ disabled }: { disabled: Signal }) {
// ...
}
function MyComponent({ disabled }: { disabled: Signal }) {
return
}
Where signals offer an important benefit is in localizing re-rendering. If you use context with regular, non-signal values the entire VDOM tree has to be re-rendered when the context value changes (because there's no way to know what code depends on its value). With signals you can change the value of a signal in the context without changing the context itself, meaning that the only part of the VDOM tree that gets re-rendered is the one using the signal.
With performance considerations out of the way context becomes a really interesting way to provide component composition without having to specify the same props over and over as you make your way down a chain.
Earlier quoted context omitted.
Calling hooks "traditional" in relation to signals seems fine, lest that word be relegated in time to whatever you in particular care about at this juncture. I'm sure some 80 year olds before us thought the same of us using that term.
> Calling hooks "traditional" in relation to signals seems fine, lest that word be relegated in time to whatever you in particular care about at this juncture. "Traditional" hooks are 6 years old. I think it's to early to call it traditional. Given that literally everyone else looked at this "tradition" and chose differently. Namely, signals. Signals were popularized by SolidJS, but SolidJS's Ryan Carniato will keep…
I guess the bigger point is that we could offer the same charity to the OP that I'm lending you here in your use of the wrong "to".
There are meaningful critiques elsewhere in the comments about the piece with some semblance of charitable interpretation. We've elected instead to manufacture a snide, pedestrian haughtiness about wording.
This article is completely backwards. We do not want to manually manage what-gets-refreshed-when. The whole point of React was to react to state changes automatically.
I’m confused by your comment. Signals do reduce manual render management. By default, usestate causes unnecessary rerenders which signals avoid (all automatically).
When you ignore the performance aspect, React has the objectively least amount of boilerplate for reactivity.
The question, that I genuinely don't know the answer to, is a) whether the performance improvement is worth it, and b) whether that's still the case after the compiler.
It's hilarious that the Observable pattern that MVC and Qt are organized around has become "a game-changer for large applications where context is used to distribute state across many components" this year. MVC is maybe 50 years old now?
This article is completely backwards. We do not want to manually manage what-gets-refreshed-when. The whole point of React was to react to state changes automatically.
I’m confused by your comment. Signals do reduce manual render management. By default, usestate causes unnecessary rerenders which signals avoid (all automatically).
Enter a name
One upside of this approach is that the only subtree that needs to be re-rendered is the specific element whose state got mutated.
Another upside of this approach is that the code doing the mutation is very close to the actual UI element that triggered it. Of course, this rapidly turns into a downside as the size of the codebase grows...
Earlier quoted context omitted.
I’m confused by your comment. Signals do reduce manual render management. By default, usestate causes unnecessary rerenders which signals avoid (all automatically).
It's not automatic though. Theres function calls() and you must createSignal for every derived value. When you ignore the performance aspect, React has the objectively least amount of boilerplate for reactivity. The question, that I genuinely don't know the answer to, is a) whether the performance improvement is worth it, and b) whether that's still the case after the compiler.
Earlier quoted context omitted.
These "signals" don't seem like FRP signals (which are time-varying values, like a "signal" to an EE but not limited to real numbers) but more like Qt signals or MVC "model has updated" notifications.
Original FRP was "behaviours" (continuous time-varying values) and "events" (discrete events, which map to current signals).
It's hilarious that the Observable pattern that MVC and Qt are organized around has become "a game-changer for large applications where context is used to distribute state across many components" this year. MVC is maybe 50 years old now?
There’s a difference, see https://www.builder.io/blog/signals-vs-observables