Skip to content

Would you use redux or another state management in 2020?

wolfiton profile image wolfiton github logo ・1 min read

Hi everyone,

I am interested to know if in your react workflow would you use Redux or another state management in 2020?

If you are using something else why are you using it, because it has a smaller footprint and boilerplate or because it is new?

Update: I am considering to try state machines for my project xstate - not scalable(need more research)

Also, it seems that redux wrappers are on the rise so:

If anyone wants to add more to this discussion please feel free to do so.

Thanks in advance for all participants to this discussion

twitter logo DISCUSS (12)
markdown guide

Hi @wolfiton

Last year, I worked on a side project. It was a React app that integrated the Google Places API. In one point I needed global state and using Redux was no.

Also, React Context didn't work because I needed a JavaScript object in another page. My use case was very simple and adding Redux was overcomplicating the app.

What did I found? duix. This is a package that helps managing state in the very precise way without all the boilerplate Redux adds 😅

It was easy to use (for me) and in the end helped me with the specific case I was facing. It is no longer maintained but it shows that a simpler state management is possible. 👍🏽


Thanks for sharing @franciscoquintero, your experience and the detailed reasons why you chose duix.

I really appreciate it.


Saw the update to the post. Go ahead with state machines. Try as much as you can to understand them and see how they could benefit the UIs you build.

In the project I worked we have three different apps.

  • The first one had its UI built with React and state management was done with Redux.
  • The second one is a combo of React, MobX, TypeScript, and XState
  • Third one, same as previous.

This guy couldn't be happier, calmer, and doing stuff faster with the MobX, TypeScript, XState stack. He called stuff with Redux "Mental Gymnastics" xD

Thanks for the quick follow up @franciscoquintero,
I will probably try a simple app with Xstate first to see how the data flows and see what states I will have to take into account, besides "idle".

Update: Did your friend tested his code after using Xstate with Jest, is it even possible?

Yes. He tested his code. In his opinion, it was easier because state machines are more predictable.

He used React Testing Library and Cypress. I think one of those tools made the testing part easier for him. I will ask him :)


I've been using mobx lately because I always had a good experience with observables. My goal is to always use technologies that don't impose an unnecessary cognitive strain when writing code.

The reason why I use React is because - unlike other frameworks - it feels very natural to use. Redux doesn't so I try to avoid it.


Thanks for sharing @michalgacka, the reasons why you use Mobx.

Are you using it with typescript or es7?(because you mentioned observables that are Rxjs and for me that sends my thoughts, towards Angular 9 Rxjs).



It's actually an interesting case as well because I was trying to avoid TypeScript initially similarity to redux. Following the same reasoning, I found that beyond the initial resistance to introduce more complexity, TypeScript reduced the cognitive strain after a few days, while with Redux I never got to a point when I would find it intuitive enough.

I checked the easy-peasy library btw. and I think I'll give it a try on the next project. Looks really good.

I think i will also go with easy peasy or rematch because my stack is scalable by default and Xstate is not.

So I don't want to lose my advantage of scaling by using a nonscalable technology, even though it looks awesome.

Depending on what's your relationship with OOP, I really recommend trying mobx with classes you construct yourself side by side with the functional approaches to really boil the problem down to how you'd solve it if we weren't thrown into this opinionated world :)

I wonder also if mobx felt so natural to me because I only use it for data management (loading, errors, computed, etc.) and transformations and handle the rest using context and local state.


At first glance, Redux looks very complex. I only made my first Redux implementation after 4 months of learning React, but today I can't work without it. Redux is so customizable and adaptable. I don't like the Context API at all because I always feel like something's missing when using it, I don't how to explain. I also work a lot with Firebase and it's just awesome to implement it with Redux.


Thank you for sharing your experience @pedrohenriquewindischand, with Redux and also for explaining why you wouldn't use the Context API.

I was wondering if you would try rematch in the future because it promises to use less boilerplate than Redux but to be very configurable.

Also how do you test your react apps?

Classic DEV Post from Aug 6 '19

What to put in your portfolio as a beginner web dev

wolfiton profile image
I am a certified trainer that likes to share my knowledge with the world. Also, I am an adopter of continuous learning and evolving idea.