Red(ux)ing the complexity in a React application's state
When the last edition of the wonderful React newsletter landed in my mailbox, one of the links caught my eye: “Why I stopped using Redux”. Pleasantly, the link sent me to Dev.to, a social network of sorts for developers that you must absolutely be a part of.
Now, grumpy devs writing against Redux is nothing new. While for many Redux is the perfect solution for the messy, ugly problem of state management, for others it’s an overcomplicated, over-engineered, half-complete solution that is being rammed down their throats by the snobs of the React world.
So, normally I’d have dismissed this as one of those “why we moved from X database to Y database” articles. But the timing of it rang true to me. I’ve myself suffered from Redux overcomplexity and fatigue, and a while back Facebook itself released a new state management library called Recoil. All in all, things are kind of settling down in the React world, and everyone is beginning to acknowledge that perhaps they got carried away earlier in their over-enthusiasm.
The article talks about why Redux might be an anti-pattern and burden of sorts, and advocates the use of another library called React Query that does state, caching, etc., beautifully. I’ve not checked out the library personally, but I wouldn’t be surprised if it became more popular.
The era of complexity in React is beginning to end — Hooks, Context, Recoil, and the vocal move away from classes and higher-order components . . . the core team itself is signaling that simpler is better. Which is vastly welcome, but I really hope this is the final set of sweeping changes they make. If they come up with another ah-but-we-were-so-wrong-and-here-is-the-latest-and-greatest-way-to-write-react-apps approach next year, I might as well give up on React. 🤣