Intive Blog

The Utopia of Single-State Applications

The cliché that goes “If you have to force it, leave it” is also applicable in Systems Engineering, with a more technical than philosophical sense. Seriously though, how often have you spent hours wondering if your application justified a single-state? If you had to consider it too long, maybe that’s not what your product needed. We asked Marcelo Zapaia about this issue in our React meetup. He’s a specialist in front-end architecture with more than ten years of experience, and he’s passionate about React.

React-Redux and the Single Source of Truth Theory

When coding an application in React, a technology based on components, it may seem obvious that the next step is to adopt a single-state and use Redux, a popular state manager —a tool to manage application states. The urge to use Redux comes from the need to share data between components in a less structured way, to maintain more interactive relationships among objects, and to break unidirectional ties that don’t allow upward, downward or horizontal interactions. Thus, we arrive to React-Redux applications and the Single Source of Truth (SSOT) Theory, also known as the Center of Truth: a big, read-only global variable accessible by all components that can only be modified through methods. It’s the solution for programmers who need to centralize information and access it from other parts of the code.

However, sometimes Redux includes concepts or information persistence that don’t fit the size of the product to be developed. That’s why we first need to ask ourselves, what’s the reason for a single-state? Is the state manager used correctly, or is it used to insert microstates along the code? “As developers, we sometimes cheat,” confesses Marcelo. We use Redux to store data just in case. We store every query string of the url and whatever is in the local storage: “We can persist information and then retrieve when desired.” We are not sure about the purpose, but we do it all the same. So, we have an application state without clear limits, a bomb of information whose component doesn’t understand where it comes from.

If that was the purpose, we could use “no single-state” tools like Hooks or Context Typescript, which are ideal for developments of lower scale such as Vanilla Javascript, since maintaining a single state in small applications or solutions is too forced.


According to Juan Carlos Rengifo, front-end engineer and React TL in one of our biggest projects, it’s essential to plan the storage scheme, since that’s where the global state of the application is stored. In low-scale projects with fast cycles, it may be complex to decide whether to use a state manager or not, which often results in halfway implementations or an absence of a state manager directly. He insists on planning and organizing the development from the start, in order to ensure scalability and an effective maintenance of the application.

“Usually, Redux slows development times at the beginning but provides huge advantages in UI control and progression, since a decentralized state can be reused and gets automatically synchronized because it lacks duplicity. Even though you need actions, reducers and selectors which need to be tested, this is recommended for middle- and large-size projects,” explains Juan Carlos. For the tool to be effective, each component must be environment-agnostic and should only deal with what it’s designed to, he adds. That’s why purpose and planning are fundamental.

Ilein González

Ilein González has a degree in Social Communication, journalism mention, graduated from the Andrés Bello Catholic University. Since May 2018 she has been working as a Quality Analyst at intive, in one of the most challenging projects of the company. Ilein is also an enthusiast of innovation and processes.

Add comment