> Traditional state management like React hooks
Oh boy. The youth of the author is really visible.
State-based vs Signal-based rendering
11–20 of 64 posts
Re: State-based vs Signal-based rendering
#12This 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.
that's the theory, but it's quite easy to end up needing to micromanage react to avoid pathological rendering scenarios
Re: State-based vs Signal-based rendering
#13This 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).
Re: State-based vs Signal-based rendering
#14Are Angular signals the same as Preact signals?
I can't say as I'm not familiar with Preact signals, but I do know the Angular team brought on the author of SolidJS to implement signals in Angular. Though I think I remember reading at some point that Preact signals were essentially directly ported from SolidJS, so they're likely similar if nothing else. (Someone correct me if I'm wrong)
Re: State-based vs Signal-based rendering
#15I don't like the style of code in the article, with weird functions like "useState" and "useSignal". Looks ugly to me. Also, it seems that with signals you must use immutable values only. Imagine if you have, let's say, a text document model, and you need to create a new copy every time the user types a letter. That's not going to work fast. And there will be no granular updates, because the signal only tracks the va…
> Imagine if you have, let's say, a text document model, and you need to create a new copy every time the user types a letter. That's not going to work fast. And there will be no granular updates, because the signal only tracks the value (whole document), not its components (a single paragraph).
Funnily enough, back when storage was slow enough that saving a text document involved a progress bar, one of the big advantages Word had over competitors was lightning fast saves, which they accomplished by switching to an immutable data structure. That is, while others would update and save the data, Word would leave it untouched and just append a patch, skipping lots of time spent rewriting things that an in-place edit would shift.
The “copy everything” mental model of immutable programming is really about as wrong as a “rewrite everything” mental model of mutable programming. If it happens it’s bad code or a degenerate case, not the way it’s supposed to happen or usually happens. Correctly anticipating performance requires getting into a lot more detail.
Re: State-based vs Signal-based rendering
#16[deleted]
Re: State-based vs Signal-based rendering
#17Preact 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 }) { // ... }
Could you explain why?
Re: State-based vs Signal-based rendering
#18> Traditional state management like React hooks Oh boy. The youth of the author is really visible.
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.
Re: State-based vs Signal-based rendering
#19knockout js is that you?
Rich Harris of Svelte often mentions Knockout when talking about Svelte’s signals.
Re: State-based vs Signal-based rendering
#20Relatedly, there is a stage-1 proposal to add first-class signals to Javascript: https://github.com/tc39/proposal-signals
It's a collaboration between multiple library maintainers, attempting to standardize and unify their shared change-tracking approach.