Remark 1: In this article, when I say "store" I refer to the "Flux architecture" and its implementation represented by Redux.
Remark 2: The article is not dedicated to any specific Front-End framework/library. Arguments stated here may be applied to React as well as to Angular and other modern Front-End tools.
First, of course, you can use Store, it’s very helpful and makes our lives simpler. The reason I decided to go with the title is that applications that use store very often misuse it by not understanding when and where it should be applied. As a result, usage of store can bring you more headaches than profit.
In this article, I would like to describe situations when the usage of Store is a good decision and situations when it will only cause problems.
You may object: “But in the nowadays Front-End wave more and more companies tend to avoid using Redux, replacing it with other tools like React Hooks & Context API”. You’re right, but 1) according to different sources number of applications that use Flux architecture in React apps is above 50%, so we will need to keep living with the technology for some time, 2) most other store management tools/approaches have new names, but most of them use components of Flux, like
reducers, what leads to the same issues.
Before we start, let’s talk about why we love using Store and why we hate it.
Ok, to answer this question, let’s answer another one: “What kind of problems does the store solve?”.
The points above sound pretty reasonable, right? But it's not that simple. Every technical decision comes with its pros and cons, and here’s a list of drawbacks you will need to deal with:
interfaces). Some projects (even small ones) have hundreds of files related to store only.
We already discussed the main advantages and tradeoffs of using Store. Now let’s talk about when is the right time to use it and when not. If I was asked to answer this question within 280 characters, I would show you this Dan Abramov’s (creator of Redux) tweet:
As it follows from this tweet, the main problem with Store is that it is often used in places where it’s not required. In many projects, I saw a situation where developers mindlessly were extending the app’s Store not asking themselves if it is necessary in this particular case. As we discussed above, such a reckless way of using the store leads to increased code update complexity and a bigger amount of boilerplate code. You can avoid it by simply using the store in places where it’s justified to use, and in the rest of the cases use the component’s local state instead.
Let’s outline a few examples of when the usage of Store will be justified and not.
✅ We have user data, which is reused on Profile, Settings, and multiple other pages.
✅ We need to pass data to a component that’s 5th descendant of the current component.
❌ Data is used only on one page and not going to be reused.
❌ We need to pass data to a child component.
Before creating another domain in your Store stop and ask yourself the next questions: “Is the data going to be reused elsewhere?”, ”Can I use here local state instead?”, and “Does the store usage here contribute to a better app’s architecture?”. Honest answers to these questions will help you to make a better decision in any particular case.