Are Signals Worth the Hype? by Atila Fassina
HTML-код
- Опубликовано: 5 сен 2024
- From basically every framework across the board to TC39, signals are all the rage nowadays. A lot has been said about the performance benefits, but that's not all it is. Let's talk about how signals provides a better mental model to render user interfaces, and how they make developing apps more predictable and, likely, error-free.
jsconfbp.com/s...
Atila is a DX Engineer, SolidJS team member, and Google Developer Expert for Web Technologies. He's been working with the web for over 10 years with multiple stacks and creating content either at speaking conferences, publishing youtube videos, or writing articles.
Real talk starts at 04:00
Thanks
Thanks
🎉 thank you!
Thank you
gigachad
Cool talk. I like react. I use it from PureScript, it's great. I'm curious if I can make this work in PS
Awesome! While every other JS framework already has support for signals in their latest versions, React's concern for implementing a compiler surely won't provide performance gains as we can see by that presentation.
god i hate react lmao
I still don't see why React need to support signals.
Would be nice, but how intensive need your app rendering be to it make any sense?
@@neociber24 to support fine grained reactivity in react you should monkeypatch React.createElement function so the only parent node will be rerendered (check how preact-signals did do it)
and as Dan Abramov said React will never adopt signals and neither should react developers
@@neociber24 my point is that it's not about avoiding rendering or improving rendering performance. My point was about improving DX and UX by having a better way to understand how your framework handles your inputs and user's interactions.
While React can reach decent performance without Signals, having a Pull based system implies a lot of code is written (by you or the framework) to protect such performance and it's really easy to fall out of those optimizations unknowingly. So, imho, signals are a better architecture to describe data in apps.
I’m dreading the Signals proposal in JS. The way signals are implemented force devs to write many wrappers around pretty much everything. This means it will always be just a library. There is a better abstraction that used to exists, which signals could be built on top of: Object.watch() and Object.observe(). It allows devs to register a callback that gets called whenever a variable value changes or whenever an object property changes. Just from that description you can see how signals can be implemented on top of that. What this gives library authors is clean minimal syntax to respond to changes in the app. E.g if variable data changes, re-render my table. It’s subtly different and lower level than signals. Signals track dirty state and have an update step. This is just “ when you do a variable assignment, your callback gets called”. There’s so separate methods for setting a value vs reading the current value. This means there are no wrappers upon wrappers upon wrappers. Library authors can make cleaner code, and opt in to signals if it’s actually needed, which most often it is not.
Dayumn! Loved it. I really enjoyed the svelte's implementation of signals (called runes as you mentioned), as always they focus on DX very verrry much. The whole "React" way of component style/structure should really start to change. I hope as every framework learned from solid to move towards signals, solid can take inspirations from others to move away from structuring components in a "React" way. I'm really eager to see that happen and what you comeup with (if its worth it)! What are your thoughts on svelte's implementation of signals? (specifically the DX and component structure)
Can you update and get the latest signal value outside react components and hooks?
Not sure I get the question.
React components don't have signals.
getting data update outside of your framework system may be possible, but it depends on the framework and tooling you're using to handle those states.
In Solid it would be possible outside of "components" - but to have reactivity enabled, you'd need to be within a "reactive root", which we have a helper to allow you to declare them.
i rise my hand and say I'm not really hyped for something which is nearly undebuggable . You putting lambdas(anonymous functions ) into a blackbox. Lambdas alone aren't the icing on the cake because on very low level view they are function pointers which obscure where your actual function is and then this is hiding them on top of it. There more views to this:
1. The idea behind it only update parts of your code when its needed/ certain inputs are happening isn't new this is a common optimization strategy but most of the time without lambdas and nobody gave it a name because its trivial.
2. The whole concept is a bandage to the problem with the DOM tree and how webdevs want to change everything in it all the time and then have weird synchronization problems. You can argue who is to blame about it browser devs and international committees who natively only support webpages or webdevs who wants webapp.
Why is useState only "pull" system according to Atila?
useState is like signals but only setState pushes not to subscribers to this particular value but it tells vdom that current component should be rerendered
and then vdom also like signals aggregates all the setState calls and then in rAF rerenders only components that are need to be rerendered
under the hood the logic is pretty the same as signals
so it's also push-pull system
btw I hate react
Hello!😊 thanks for your question!
`useState` is Pull-based exactly because it doesn't push to subscribers. The system has no idea what is being used. What happens on `setState` is that from the point in your tree where a state update is triggered, it tears down the whole branch and renders it again with the new data.
In Push-Pull systems (like signals), when there's a data update, the subscribers are notified and only the value is updated. There's no teardown involved because the system can track exactly the point in which the data is.
So this statement:
> vdom also like signals aggregates all the setState calls
is not true. The vDOM is completely removed and added again with the fresh data, regardless if it's a single element which has been changed.
What the compiler is trying to do is memoize (cache) the components that _don't_ depend on that data and thus re-render less. But that doesn't mean it updates only the data that changes, it means that it will try to prevent adjacent components that have nothing to do with the data.
@@AtilaDotIO I'm talking about the logic of useState hook under the hood (implementation of signals and useState in react)
I'm not talking about what parts of ui it rerenders (I know that whole function reruns again and whole branch is being removed)
@@user-mz2lm1vb1q the fact that the UI re-renders and reruns the whole thing is a consequence of it not being Push-based. So we can't argue how the API behaves without considering how it works under the hood.
So, the TL;DR is: it works in a much much different way than Signals do, but it can reach similar performance if the right measures and preventions are put in place. Even if the performance can reach "close enough" levels, it will still be Pull-based though.
7:20 push-then-pull: like a skinny web hook.
I cry on the inside when I see people use a wrapper to write JavaScript.
He is truly biased.
He's using useEffect() wrongly for the derived data.
He can just calculate the derived data without useEffect()
He can get the derived `double` state without useEffect() in react.
Also, `setState(...)` in react isn't synchronous like in solidjs.
To get the same result as in solidjs, move the console.log(...) to useEffect() and move the derived `double` data out of the useEffect() and delete the useState() for `doubleCount`
He did mention about it, I think you missed it