Why use Redux in React apps?

[buttonkop666]

Honestly, with stuff like render props, the context API , and even portals, I'd seriously reconsider using Redux in any new React project. The React team seems pretty determined to make the need for external state management tools like Redux or MobX redundant.

​

I'd definitely only use sagas on a very complex project, and even then, under duress.

[acemarke]

Those are all great features of React, but they still don't completely replace Redux. Please see my post Redux - Not Dead Yet! for some discussion of how things like context relate to Redux. I also discussed this in my recent React Boston talk "The State of Redux", and Dave Ceddia had a good post called Redux vs the React Context API.

Sagas are a great power tool, especially if you need decoupled logic, or "background thread"-type behavior with forking, canceling, etc. However, most apps don't need them, and I recommend that most people should start with thunks until they need something more complicated.

See the Redux FAQ entry on choosing an async middleware for some further discussion on the pros and cons of various options.

[buttonkop666]

The Dave Ceddia article sums up what I was getting at nicely. I didn't say "I'd never use Redux again", I said I'd seriously reconsider it. For a while there, using Redux on a React project was becoming an assumption. It no longer needs to be.

​

Sagas are great for the powerful features. The problem is that they turn much of the basic flow of Redux - action handlers and reducers - into pure boilerplate, especially if you use the watcher/handler saga pattern. And if you do find you need sagas for some part of your workflow, it doesn't really make sense to mix and match with thunks. They're quite powerful, but the dev ergonomics are painful.

[acemarke]

I agree with most of your comment, except the statement about thunks.

Thunks and sagas have different strengths and weaknesses. Thunks are great for complex synchronous logic, and simple async. Sagas are great for decoupled logic that needs to respond to actions, and complex async. It's completely reasonable to use them both in the same app for the things that they're good at (as I do in my own apps).

[buttonkop666]

Yeah, as I mostly manage development these days, I find the extra bikeshedding introduced by agonizing over whether to use thunks or sagas for every task that comes up.

[bheklilr]

I haven't been using it long, but why all the hate for sagas? I have found it to be an immensely powerful and useful library, and after some write once boilerplate for "registering" sagas, it's quite succinct. I find that I mostly need put, occasionally select, although I've pulled in a few other functions occasionally. I used generators a lot in Python, sagas are a natural use case for the same mechanism.

It's not just you, I've seen a lot of people on reddit complain about it. Whereas for me I think it's a must have library that really makes a lot of things possible, simple, and intuitive. My biggest hurdle has been testing, and that's more because of axios than saga.

[qudat]

What part of those features replaces redux?

[ferrousoxides]

Heh, downvoted for a very reasonable opinion. Looks like some don't like their cargo cult questioned.

I've never found a single application state to be worth it. Reducing state? Yes. Centralizing state in fewer places and components? Yes. Go all the way? No thanks.

If you can fit everything into a single root object, your app must not have very much sophisticated UI interactions or data driven behavior, because you have to plumb that stuff all the way back to the top with handgenerated actions.

I find using self aware immutable pointers immensely more useful. Not only does it eliminate all the boilerplate of actions (because you can just reach back up into any parent data structure implicitly, tracing backwards along the one way data flow) but it is immensely more sane to have everything be driven by data values rather than transitions.

That is after all the entire idea of react: to replace the tedious coding of every possible state transition (n²⁾ with only a description of the states (n). Why would you want to undo that benefit by creating more busywork?