You should NOT use Store in your web applications

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 actions or reducers, what leads to the same issues.

Before we start, let’s talk about why we love using Store and why we hate it.

Why do we love Store?

Ok, to answer this question, let’s answer another one: “What kind of problems does the store solve?”.

• Sharing global data, which needs to be accessed in multiple parts of an application. The data can be, for example, app configuration or user account data.
• Sharing data deep down to component’s child. It helps you to prevent a situation when data is passed down to a certain child through multiple components which don’t even need the data.
• It helps you to manage your app’s state in a single place and make changes in the state predictable.

What are the drawbacks of using Store?

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:

• Big amount of boilerplate code. Using classic Redux you have to create at least 3 different entities for a dedicated store domain: action, reducer, and selector (optionally effects, constants, and interfaces). Some projects (even small ones) have hundreds of files related to store only.
• High coupling. It means if you want to change something in your store structure, you will have to make it multiple places. The high coupling will make it difficult to change and maintain your code. The more store domains you have, the harder it will be to modify your application.

When should I use Store?

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.

Conclusion

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.