Redux is used by too many react developers without thinking twice! Applied mindlessly like that, redux does more harm than good! I will show the fields in which redux shines and — most importantly — I will point out the situations in which redux is the wrong tool in my strong opinion.
Why Redux was Invented
Don’t get me wrong: I think the idea of Flux and its canonical react implementation redux are awesome inventions! They solve a real problem pretty elegantly. It’s just that most developers don’t have that problem!
Redux (and the underlying general idea of Flux) was invented to manage and debug application state in very large software systems. Think Facebook. If your team has hundreds of developers and millions lines of code, it is often difficult to write modular tests and find bugs. Redux makes state changes explicit, localizes them in one store and has strict rules about side effects. This makes your code easier to test and it makes application state easier to reason about.
What I Hate About Redux
If you use redux to develop your application, even small changes in functionality require you to write excessive amounts of code. This goes against the direct-mapping principle, which states that small functional changes should result in small code changes.
Just imagine, you want to add a new variable to your state just to try it out. You think this little change will satisfy your tests and in a pragmatic way, you go for it. Doing so in a non-redux application might need changes in one or two files and take you two minutes. Not so in a redux application. With redux you will have to touch many files and you will have to repeat yourself a lot:
- Define an action constant in
- Import that constant and define an action in
- Import the constant and define a state change in
- Import the action and dispatch it in your component
- Oh wait, before you can do that, you need to connect your component to the redux store by wrapping it in a HOC
- Oh, and before you can do that, you need to define two functions called
- If you’re about to add a variable filled from an API, you will need to do ALL the above x3:
You do ALL the above (maybe minus the API part) for every little variable you add! This has so many disadvantages that I don’t even know where to begin:
- You will forget about the business value you want to deliver, because you’re distracted by writing code in all the right places.
- It will take you considerably longer to just “try things out”.
- Jumping between files hinders a productive coding flow.
- Many indirections make code hard to adapt and difficult to understand.
If you’ve ever needed to react to a client (or to your own wish) wanting to see how this or that would look like, you know how much of a pain and agility-killer redux can be!
You Don’t Need Redux
Most teams I meet — whether in startups or international corporations — are concerned with finding a market to build or grow their business (lean startup, design thinking) or with adapting their software to ever changing market situations and customer demands (customer development, agility). In these cases the burden redux puts on you far outweighs its benefits!
Chances are, you’re building a new application to test a business idea or you’re improving an application to grow your business by catering to new customer segments. You don’t need to hunt strange bugs in your state between millions of lines of code and with a team of hundreds of developers. So you won’t feel much of the benefits of redux, while being bogged down by the lack of direct-mapping and DRYness (=Don’t Repeat Yourself) of the approach.
There are many alternatives to redux. To be honest, I don’t know, why redux is so commonly used by developers. Sure, redux shines in a particular field of applications, but that is most certainly not the majority of software projects out there.
One alternative to redux would be to simply not use the flux approach at all! As I mentioned above, flux is awesome, but only if you need it. Only if you have complex state, a large code base and maybe a big team. And even if you don’t use flux, nothing stops you from adding it back in later, once you approach those problems that flux and redux can solve. After all, you should develop pragmatically, while testing and refactoring meticulously. From that will arise an emerging architecture, which will automatically point you towards flux/redux, once the time for it comes in your code base.
Another alternative are flux implementations like MobX (I’m not affiliated with them). These libraries allow you to reap the benefits of the flux approach, while sparing you from the verbose coding style that is so distracting and harmful with redux. Of course that means yet another dependency, but we want to “stand on the shoulders of giants” and not rebuild a giant from scratch every time!
Although this little rant might seem to go against redux and flux, it does not. I believe the idea of flux and the redux implementation are awesome tools for a very important problem in modern software development! It’s just that most people using redux either don’t have that problem or would be much better off with picking a flux library instead of building the giant themselves for every application with redux.
Even if you have some of the problems redux promises to solve, be clear about your priorities: Is your biggest problem to build/grow a business by quickly experimenting in your market (lean startup) and adapting to customer demands or is your biggest problem reasoning about your application’s state and to minimize dependencies on external libraries? My guess would be, that most react projects fall into the former category.
Please think twice, before you choose redux for your software project!