5 ms·

You make it sound like react is a dark box with a lot of magic behind the curtains, but I always found the react model very easy to reason about. Modifying stat

by kabes 3y ago

You make it sound like react is a dark box with a lot of magic behind the curtains, but I always found the react model very easy to reason about. Modifying state is explicit and is the only thing that can trigger a rerender. These rerenders can only happen down from where in the tree the state change happens.

softfalcon 3y ago
I mostly agree with you. Unfortunately, many React apps use Relay (another Meta product) and it opens up a world of “magic” that is sometimes a real pain to reason about.
- satvikpendem 3y ago
  What do you mean by "many?" While I like Relay, I've almost never seen Relay used in the wild. It's sad as it's quite an elegant concept; just as you define your props for your React component, you define your "props" coming from the server as well, through the GraphQL notation. I've been looking at ways to combine both concepts so that there is no client- or server-side state at all, it's all just state, from a cache that determines whether to refetch from the server or to keep the state local.
  - softfalcon 3y ago
    Maybe it's isolated to me and my work here on this repo: https://github.com/coralproject/talk https://github.com/coralproject/talk I agree that Relay CAN be simple, but it isn't for what we do. Have a look at this ReplyListContainer and its nested Relay logic. I didn't originally write this, but I can see what they were trying to do and how Relay made it difficult for them. Your thoughts are welcome, I won't judge you for being critical of our code and welcome any other Relay dev's opinions. https://github.com/coralproject/talk/blob/develop/client/src/core/client/stream/tabs/Comments/ReplyList/ReplyListContainer.tsx https://github.com/coralproject/talk/blob/develop/client/src...
- kabes 3y ago
  Relay tries to solve the problem of: let a component define its (server) data dependencies. It indeed does this with more magic. But it's not exactly the same problem and you can't really fault react for it. It's also a problem other frameworks don't try to solve.
satvikpendem 3y ago
React is honestly how I used to write my code in jQuery too, for some pages that had a lot of state. Basically, just like in game dev, I had a render() function that I'd call at the end of the file that would re-render everything. The pattern itself is very easy to understand, re-rendering efficiently is the hard part, but for React users today, that's an implementation detail. Hooks are also very interesting, they're basically functions that run at specific times, or that is to say, they're `f(...parameters, state)`. They hold state inside the function, sort of like a closure.
- bafe 3y ago
  Indeed, seeing hooks as closures helped me to understand how they are use for state management. It's really a "poor man's object" with all the advantages of FP in terms of reasoning about state changes, lack of side effects etc.
- truetraveller 3y ago
  Same here. For complex UIs, I almost always had my own 'render()' function.
ttfkam 3y ago
Let's be honest: the state (see what I did there?) of React state management is a dumpster fire. https://fe-tool.com/awesome-react-state-management https://fe-tool.com/awesome-react-state-management That's an article listing the top 18 state management libraries for React. 18?!? React devs can't even agree on a common development model for state, but you think it's explicit and very easy to reason about? Folks don't adopt utility libraries for things that were already easy to reason about on their own. I'm glad you've found peace with React's basic notion of state, but it's a far cry from optimal. And the "state ecosystem" of React is a dumpster fire. Layers upon layers of madness that acolytes peer through and proclaim insight. > These rerenders can only happen down from where in the tree the state change happens. Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness.
- hajile 3y ago
  React isn't a state manager and why should everyone be forced to use the one "blessed" manager? Despite there being so many, only a handful (redux toolkit, jotai, zustand recoil, and mobx) see much real-world use and they are basically just 3 approaches (reducers, signals, and directed graphs) with varying levels of complexity and features. > Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness. Not true. It only needs to diff the leaves of the part that changed and some of those sub-trees can be skipped too if they are functionally pure (or uses shouldComponentUpdate). This is how they reduce complexity down from O(n^3) to something generally closer to O(n)
  - Exuma 3y ago
    I use vue, so I’m assuming that is the “signals approach”. I use pinia btw Can you explain how all 3 state mechanisms you mentioned, and how they are different ?
- rmilejczz 3y ago
  I’ve written a lot of react apps (first used it in a hackathon in 2014) and this list is really just fluff. hooks + context make all of these libraries pretty much unnecessary for most react apps as they are not that complex I think the more glaring criticism is the lack of any unified component library. The amount of different Button implementations alone is astounding

by kabes 3y ago

softfalcon 3y ago

I mostly agree with you. Unfortunately, many React apps use Relay (another Meta product) and it opens up a world of “magic” that is sometimes a real pain to reason about.

satvikpendem 3y ago
What do you mean by "many?" While I like Relay, I've almost never seen Relay used in the wild. It's sad as it's quite an elegant concept; just as you define your props for your React component, you define your "props" coming from the server as well, through the GraphQL notation. I've been looking at ways to combine both concepts so that there is no client- or server-side state at all, it's all just state, from a cache that determines whether to refetch from the server or to keep the state local.
- softfalcon 3y ago
  Maybe it's isolated to me and my work here on this repo: https://github.com/coralproject/talk https://github.com/coralproject/talk I agree that Relay CAN be simple, but it isn't for what we do. Have a look at this ReplyListContainer and its nested Relay logic. I didn't originally write this, but I can see what they were trying to do and how Relay made it difficult for them. Your thoughts are welcome, I won't judge you for being critical of our code and welcome any other Relay dev's opinions. https://github.com/coralproject/talk/blob/develop/client/src/core/client/stream/tabs/Comments/ReplyList/ReplyListContainer.tsx https://github.com/coralproject/talk/blob/develop/client/src...
kabes 3y ago
Relay tries to solve the problem of: let a component define its (server) data dependencies. It indeed does this with more magic. But it's not exactly the same problem and you can't really fault react for it. It's also a problem other frameworks don't try to solve.

satvikpendem 3y ago

React is honestly how I used to write my code in jQuery too, for some pages that had a lot of state. Basically, just like in game dev, I had a render() function that I'd call at the end of the file that would re-render everything. The pattern itself is very easy to understand, re-rendering efficiently is the hard part, but for React users today, that's an implementation detail. Hooks are also very interesting, they're basically functions that run at specific times, or that is to say, they're `f(...parameters, state)`. They hold state inside the function, sort of like a closure.

bafe 3y ago
Indeed, seeing hooks as closures helped me to understand how they are use for state management. It's really a "poor man's object" with all the advantages of FP in terms of reasoning about state changes, lack of side effects etc.
truetraveller 3y ago
Same here. For complex UIs, I almost always had my own 'render()' function.

ttfkam 3y ago

Let's be honest: the state (see what I did there?) of React state management is a dumpster fire. https://fe-tool.com/awesome-react-state-management https://fe-tool.com/awesome-react-state-management That's an article listing the top 18 state management libraries for React. 18?!? React devs can't even agree on a common development model for state, but you think it's explicit and very easy to reason about? Folks don't adopt utility libraries for things that were already easy to reason about on their own. I'm glad you've found peace with React's basic notion of state, but it's a far cry from optimal. And the "state ecosystem" of React is a dumpster fire. Layers upon layers of madness that acolytes peer through and proclaim insight. > These rerenders can only happen down from where in the tree the state change happens. Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness.

hajile 3y ago
React isn't a state manager and why should everyone be forced to use the one "blessed" manager? Despite there being so many, only a handful (redux toolkit, jotai, zustand recoil, and mobx) see much real-world use and they are basically just 3 approaches (reducers, signals, and directed graphs) with varying levels of complexity and features. > Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness. Not true. It only needs to diff the leaves of the part that changed and some of those sub-trees can be skipped too if they are functionally pure (or uses shouldComponentUpdate). This is how they reduce complexity down from O(n^3) to something generally closer to O(n)
- Exuma 3y ago
  I use vue, so I’m assuming that is the “signals approach”. I use pinia btw Can you explain how all 3 state mechanisms you mentioned, and how they are different ?
rmilejczz 3y ago
I’ve written a lot of react apps (first used it in a hackathon in 2014) and this list is really just fluff. hooks + context make all of these libraries pretty much unnecessary for most react apps as they are not that complex I think the more glaring criticism is the lack of any unified component library. The amount of different Button implementations alone is astounding