State-based vs Signal-based rendering
jovidecroock.com
State-based vs Signal-based rendering
1–10 of 64 posts
Re: State-based vs Signal-based rendering
#2knockout js is that you?
Re: State-based vs Signal-based rendering
#3Preact 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 }) {
// ...
}Re: State-based vs Signal-based rendering
#4"Traditional state management like React hooks triggers..."
Traditional? I remember when React was the new kid on the block. I am getting old! :-D
Re: State-based vs Signal-based rendering
#5I 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 value (whole document), not its components (a single paragraph).
Also the article mentions rarely used preact and doesn't mention Vue. Vue can track mutable object graphs (for example, text document model). But Vue uses JS proxies that have lot of own issues (cannot access private fields, having to deal with mixing proxies and real values when adding them to a set, browser APIs break when a proxy is passed).
Also I don't like that React requires installing Node and compilation tools, this is a waste of time when making a quick prototype. Vue can be used without Node.
Re: State-based vs Signal-based rendering
#6Are Angular signals the same as Preact signals?
Re: State-based vs Signal-based rendering
#7knockout js is that you?
I was about to mention this too.
Compare: "import a specific lightweight library and wire together as needed" vs "write the whole app in terms of a bloated framework".
I've been out of the frontend game for a while, but what does react give you that knockout and maybe some url management logic do not?
I guess components are supposed to standardize modularity, so you can easily import some random widget?
Re: State-based vs Signal-based rendering
#8This 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.
Re: State-based vs Signal-based rendering
#9I 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…
Immutable does not mean you have to copy the whole structure. You can store only the changes. This is how immutable data structures work in functional languages such as Haskell.
Re: State-based vs Signal-based rendering
#10I 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…
React is crazy because someone thought this was too complicated for developers:
event.listenTo(render);
event.emit();
property.listenTo(render);
property.set([property.get()[0]]);