Personal thoughts after dealing with this dilemma at work. TL;DR: vote for Redux.

The attitude towards Redux for fellow React developers is complicated. Although they know it and often appreciate its usefulness, they tend not to use it. For a number of reasons. It’s complex. It’s an external library. It has coarse patterns. It’s often overused. It’s (let’s be honest) too conventional.

Avoiding Redux became craft challenge and proof of an architectural skill. Presentations closed with words “and we don’t need Redux at all” had a guarantee of loud applause. Yep, I also clapped…

Sooner or later though, all those smart solutions had to face the real life and deal with the creativity of the project owners. That’s when the second punchline enters — “Ok, let’s switch to Redux”. Maybe not followed by an applause, but by not so quieter sounds of laughter and relief. Even from the one who is assigned to implement it.

I have participated in this ritual often enough to become smart in advance. I request the Redux store before the rest of the team admits that it is necessary. To install it before the complexity of code already written gets bigger than these ugly Redux upper snakes.

Life became a bit more bearable. But then suddenly, React 16.3 introduced new Context API and here it came again… “now we don’t need Redux at all”.

“O Caesar! These things are beyond all use”

“Redux is a predictable state container for JavaScript apps.”

“Context provides a way to pass data through the component tree without having to pass props down manually at every level.”.

These definitions are taken from the docs. They seem to clearly define their purpose. Redux is for managing the state of the application, Context is for passing props. On the face of it, there is no conflict. If you ask literally what to choose, Context or Redux — the answer is RTFM. But we all know that the real question is hidden in the context (🙃). It is older than React 16.3 — Does my app need Redux?

Many projects I did were not using Redux. They were those where I did not even think about using a global store from the draft concept stage. Where the boundaries of data containers were clear and obvious. Where their processing and calculations could fit in some simple methods and not overflow the component code. For instance they were collections of articles with one-route-one-fetch rule. Other times, it was a dashboard with sections for departments that do not share anything in common.

The most difficult condition is the certainty that this would not change. Because everything can change in Agile. The popularity of this approach is so indisputable that often people work with its paradigms without naming it so.

So then some global status occurs — user preferences and data which, as it turned out, these departments have in common. The first significant “Redux Alert” blinked. When this alert appears later cyclically, more and more frequent, it leads to the point mentioned in the introduction — “Ok, let’s switch to Redux”.

“We are standing on the shoulders of giants”

The ideal component-based design is built with independent blocks. Blocks controlled just from above via props, that can be reused, removed or modified without affecting the rest of the structure.

This model isn’t strict, nor impossible to achieve, nor obligatory as well. As long as our job is not to chase the absolute, but to make stable apps with clear code to meet client demands, a sense of control over the project is more important.

When I set avoiding global state as my architectural goal, I ignore the Redux Alerts, but keep the code flexible, DRY, KISS and SLAP. It leads me to a wonderful custom solutions and patterns. They were, for sure, a very valuable contribution to the heritage of global technical thought, but made my project such a special child, that only I can love it.

Reinventing the wheel is fun, especially if you know the original wheel. But all this mechanisms already have the patterns that every new guy with “React/Redux” in CV will get at once. Not even mentioning debugging tools and the whole ecosystem grown around Redux for this years. (By the way, it can also be an argument for the discussion “Redux vs other state managers”).