28 ms·

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-

by 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
- eropple 3y ago
  I agree on both points. I used to quite like Redux but, between NextJS simplifying the page model and hooks/context being a lot easier for CRA-style apps, I just don't need them anymore for the sort of things I do. The real kick to the shins is that React Server Components did a number on most component libraries, too. I've been forced to go to Tailwind (and DaisyUI, which is pretty nice) just so my stuff doesn't require 'use client' all over the place. The end result will be way better, it already is when you actually can get there, but right now it's annoying and awkward.
  - WorldMaker 3y ago
    That was something that React Server Components definitely got backwards. The default state of the world before RSC was client components. If a mark is needed it should have been "use server" for the new style of components.
    - eropple 3y ago
      I don't mind that, because I think server components should be the default. They're better. But the profusion of CSS-in-JS solutions (which always seemed unwise to me) take it on the chin because of it.
- bafe 3y ago
  I just write my first fairly complex react app. As a mostly backend/tool Dev with good knowledge of functional programming I agree with this. I could solve almost any problem using hooks + context and memo. I briefly considered using Redux but I quickly realised that a few changes in certain components would take care of most of my state management problems
- satvikpendem 3y ago
  > hooks + context make all of these libraries pretty much unnecessary for most react apps as they are not that complex To be fair, context is not a state management tool [0], an article by acemarke, the Redux maintainer. It does work as a dependency injection tool and for many people, that's enough, but it's not a true state management tool. [0] https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
jakelazaroff 3y ago
> That's an article listing the top 18 state management libraries for React. > 18?!? I mean, the top library has more weekly NPM downloads than every other library in the list combined. > Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness. That is not how rendering works in React.

by ttfkam 3y ago

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

eropple 3y ago
I agree on both points. I used to quite like Redux but, between NextJS simplifying the page model and hooks/context being a lot easier for CRA-style apps, I just don't need them anymore for the sort of things I do. The real kick to the shins is that React Server Components did a number on most component libraries, too. I've been forced to go to Tailwind (and DaisyUI, which is pretty nice) just so my stuff doesn't require 'use client' all over the place. The end result will be way better, it already is when you actually can get there, but right now it's annoying and awkward.
- WorldMaker 3y ago
  That was something that React Server Components definitely got backwards. The default state of the world before RSC was client components. If a mark is needed it should have been "use server" for the new style of components.
  - eropple 3y ago
    I don't mind that, because I think server components should be the default. They're better. But the profusion of CSS-in-JS solutions (which always seemed unwise to me) take it on the chin because of it.
bafe 3y ago
I just write my first fairly complex react app. As a mostly backend/tool Dev with good knowledge of functional programming I agree with this. I could solve almost any problem using hooks + context and memo. I briefly considered using Redux but I quickly realised that a few changes in certain components would take care of most of my state management problems
satvikpendem 3y ago
> hooks + context make all of these libraries pretty much unnecessary for most react apps as they are not that complex To be fair, context is not a state management tool [0], an article by acemarke, the Redux maintainer. It does work as a dependency injection tool and for many people, that's enough, but it's not a true state management tool. [0] https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

jakelazaroff 3y ago

> That's an article listing the top 18 state management libraries for React. > 18?!? I mean, the top library has more weekly NPM downloads than every other library in the list combined. > Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness. That is not how rendering works in React.