3 ms·
> “Interesting that React is not in that list” Signals are not a part of the core React API, unlike Preact. My vague gut feeling is that signals are too much
by pavlov 3y ago
> “Interesting that React is not in that list”
Signals are not a part of the core React API, unlike Preact.
My vague gut feeling is that signals are too much like a generalized useEffect() and would only introduce further confusion into React by muddling what happens during the render cycle. For better and worse, React takes a different tack to updates than signals do. But maybe I’m wrong about their applicability.
- whizzter 3y agoMy feeling is that it's philosophically outside the purview of React whose focus is rendering (and components and their state but not global state), RxJS and and MobX are both usable with React and have signals whilst Redux goes another route and React is "above" that choice.
- troupo 3y agoRendering in React would benefit greatly from fine-grained reactivity (which what signals offer). However, for some reason the React team insists that the lowest level of reactivity in their system os the component, no matter how large or complex it is.
- Fatalist_ma 3y agoThere is an interesting debate about React and signals in the comments of this article, between Dan Abramov and Ryan Carniato - https://dev.to/this-is-learning/react-vs-signals-10-years-later-3k71 https://dev.to/this-is-learning/react-vs-signals-10-years-la...
- pavlov 3y agoI read it until the point where he defends the idea that these two functions obviously do something completely different: function One(props) { const doubleCount = props.count * 2; return <div>Count: {doubleCount}</div>; } function Two(props) { return <div>Count: {props.count * 2}</div>; } It honestly made me wonder whether the article was dated April 1 and I’d been had. More generously, JS framework design is hard. If you’re ambitious at all, you end up fighting the language and your runtime paradigms will hang like ill-fitting clothes on its syntax. The One/Two example above shows how easily expectations break in this world of extensions to extensions. There’s no way to know what an apparently simple piece of code will actually do without knowing the specifics of a given framework.
- __s 3y ago> There’s no way to know what an apparently simple piece of code will actually do without knowing the specifics of a given framework. Yes. In solid-js JSX interpolation needs to be read as having implicit lambdas. You need to know how a framework works to use it It's somewhat what the discussion was getting at between Ryan & Dan. solid-js having fine grained reactivity involves a lot of lambdas, in JSX they're implicit, but code outside of JSX has to spell them out explicitly
- eyelidlessness 3y ago> I read it until the point where he defends the idea that these two functions obviously do something completely different > [code] > It honestly made me wonder whether the article was dated April 1 and I’d been had. They don’t do anything different if your model of components is that they rerun. But that model is only one way to implement components, and JSX is unopinionated about semantics exactly like this. Intentionally, by design. If you’re only familiar with React and other frameworks with a similar rendering model, of course it’ll be surprising that those two functions would behave differently. But if you’re familiar with other JSX implementations like Solid, you’ll spot the difference right away: components don’t rerun, only the JSX does. The first function will always render the same thing because `doubleCount` is set up on component creation and static for the remainder of the time the returned div is mounted. You are welcome to prefer React’s model. It certainly has some cognitive advantages. But it’s not inherently the only correct model either.
- recursive 3y agoThere are those of us for which this actually makes sense. More sense than react anyway.