Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
If any react noobs are reading this, the best React state management setup for you is Redux+Immer. After some setup, it's easy to use, and the docs are very good and up to date.
When I was learning React, I kept putting off Redux because youtube said it was complicated and you didn't need it after useContext. Big mistake. Our app became more complicated because our state management(useState/useContext) was so simple. Switching to Redux dramatically simplified our most complicated components.
Also, the Redux dev tools extension is a game changer. It lets you see every state change, in order, with traces and diffs.
https://github.com/zalmoxisus/redux-devtools-extension
Pros can obviously make up their own mind. I’ve tried Mobx and the tooling just wasn’t there, but I hear their diffing algos are good.
I pressed Pete on what he actually meant by that in the replies [0]. Eventually he listed some specific concerns:
- The React ecosystem has fragmentation because there's many ways to do things, and he feels someone needs to start narrowing down suggestions to reduce confusion.
- There was an article going around on "Why I'll Never Use React for Enterprise Apps Again", and half of the problems listed in the article were about Redux and React ecosystem related issues instead of React itself, so Pete's upset about that
- Pete feels opinionated data fetching tools and explicit state machines solve some use cases better
- Pete thinks it's too hard to dynamically code-split Redux logic
So, those are valid technical points that can be discussed in detail. But those are also a very far cry from "NEVER EVER USE REDUX!", and I'm really not sure how you jump from "one article said they had trouble migrating their code from `connect` to hooks and they aren't happy with Redux-Saga" to "NEVER USE REDUX" either.
I actually pointed out that we have a new upcoming "RTK Query" API that's in alpha right now [2] that drastically simplifies data fetching and caching for Redux, and Pete said later in that thread he thought it looked impressive. He also said he appreciates the work put into Redux Toolkit and our docs updates.
So yeah, Pete said that, but as usual there's a lot more nuance in the later discussion that should be highlighted rather than the clickbait-y initial tweet.
[0] https://twitter.com/acemarke/status/1365824897210064897
[1] https://betterprogramming.pub/i-almost-got-fired-for-choosin...
[2] https://rtk-query-docs.netlify.app
Note that our official Redux Toolkit package is the recommended approach for writing Redux logic:
https://redux-toolkit.js.org
https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
It doesn't eliminate the "dispatch actions" concept, because that's core to how Redux works. But, it does simplify the vast majority of your Redux logic considerably.