31–40 of 64 posts
> 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.
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.
First-class signals came from functional reactive programming back in 1997. Even JS implementations of signals existed before React's hooks.
It remains a bit of a mystery to me that applications seem to grow further and further from traditional game techniques. Both in how state is propagated through the application, and in how it is represented. Like, I understand why people aren't going full 3d game simulation style for applications. But I don't understand why things are as divergent as they are? Is this just my off perspective?
Can you expand a bit on what you mean? To me (extremely amateur game programmer), that's what, event buses? more explicit state machines?
I have similar questions on asset management. But I think that one makes a bit more sense, though? Game studios often have people that are explicitly owners of some of the media. And that media is not, necessarily, directly annotated by the developer. Instead, the media will be consumed as part of the build step with an edit cycle that is removed from the developer's workflow.
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 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…
Vue can be used without Node.
Relatedly, 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.
Also some examples in the polyfill README [0]. Certainly looks interesting. I wonder some years down the future, if there will be no need for JS frameworks since a lot of what they offer will be integrated into JS itself. https://github.com/proposal-signals/signal-polyfill
> 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.
"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 telling you that what everyone calls signals now has its roots in libs like KnockoutJS from 2010. And everyone has been busy using signals for the past three years.
Given the amount of frameworks that implement signals today (including monsters like Angular), it's React who's not following tradition.
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 }) { // ... }
That consideration is orthogonal to what the useful data is. It could be a signal, or not. In other words, signals are not an alternative to context.