Redux/Flux is often (usually?) not needed
I have found that many developers that are new to React assume that Redux is part of the platform. It’s not. Having worked with many teams getting started with React I know pretty well what problems they encounter. And, of the top 10 problems people have using React, none of them are solved by Redux or Flux.
Side note: Flux is the pattern and Redux is the framework that implements the pattern. I’m really talking about both here.
I’m not the only one who has brought up this point. Here is a quote from Pete Hunt (one of React’s creators):
A lot of people sit down to build an app and want to define their data model, and they think they need to use Flux to do it. This is the wrong way to adopt Flux. Flux should only be added once many components have already been built.
And here is a whole blog post from Dan Abramov, the creator of Redux, basically saying the same thing: You Might Not Need Redux. This is the only blog post he keeps pinned to the top of his blog.
And here is a quote from Ryan Florence, a respected luminary in the React ecosystem and frequent conference speaker:
Flux hampered React innovation: led everybody right back to events and “templates” and intimately knowing data changes.
Back-Office CRUD Apps
Here is a specific category of app that I don’t think needs Redux: your typical business crud app. Many of my clients and students fall into this category. The app may have 100s of screens, each with their own route. But most of these screens can stand-alone, mainly integrated through the database. So while the app as a whole may be very complex, no individual screen is all that complex. Not complex like, say, Facebook.
So When to Use Redux?
If I had more time, I would like to go into the details of exactly what problems Redux solves and when to use it, but I’ll save that for another post.
But generally, when a client starts naming off reasons why they need Redux, I can often tell them how to address those same problems using plain old React with much less ceremony.
Rebirth of the Event Bus
Redux is cousin to an older UI pattern: the global event bus. While not exactly apples-to-apples, the global event bus and redux are addressing similar problems with a somewhat similar solution.
In both cases, in my opinion, moving to a global state and global events (redux calls them actions) makes the interconnections between components less explicit.
Over the years, some of my attitudes in this regard have evolved. Old Dave is a bit more tolerant of some extra typing if it makes the code more explicit.
My Recommendation
Wait until your app grows in complexity, and you encounter some specific problems that you are sure can be solved by Redux. If you need some of the specific features provided by Redux (like time-travel debugging) then maybe use it. But if you have a complex app with lots of complex state and events and cross component communications and you think that redux is magically going to make that complexity go away you will be disappointed. In most cases it just replaces one type of complexity with another.
Conclusion
In summary, I would say that Redux should not be the default choice for most apps, and in particular, for the types of CRUD apps that many of my students and client’s are creating. I would argue that there are at least 100 things that they should learn before diving into Redux.
