Introduction
The most important issues to consider when building an application are:
- Which problems am I solving?
- Which tools are best for solving the technical requirements?
- Do I have a clear definition of the type of application I'm building?
These same considerations also apply when you're trying to decide whether or not to use state management frameworks like Redux.
In this post, we'll walk though whether or not your app will benefit from using a state management framework, with Redux as our primary example. It's important to note that not all applications need a state manager or any other framework, so when using one of these tools, you need to be very clear about your reason for doing so.
High-Level Pros and Cons
This is where we encounter the concept of tradeoffs, which is nothing more than the balance between the benefits achieved versus the costs expended. Let's look first at the cons, using Redux as our state management framework example.
Cons: Using Redux demands that you construct application states as flat objects and arrays, that state changes be tracked, and that application logic be described as pure functions. Aside from this, Redux was not designed to be the fastest way to write code.
Pros: Redux can help you build applications with features that make it easy to persist states in local storage, do server-side rendering, serialize user actions in order to automate bug reports, allow and undo state changes, and promote a collaborative development environment without the need for major code changes.
It is important to state that it's possible to build an application with the above requirements without using a specific framework, with state change traceability and completely predictable behavior.
Primary Redux Concepts
Before we analyze whether or not a particular app would benefit from a state management framework like Redux, we need to know how these frameworks work.
First, let's assume that the state of our application is described according to the plain object below:
Image based on Redux.js
The object described above is like a model, but it does not have any setter; that is, it is not possible to make changes to its properties arbitrarily. For any change to be carried out, an action must be triggered.
An action is a JavaScript object that describes what will happen to the state. Here's an example:
Image based on Redux.js
Assuming that each change is described as an action, it is possible to track everything that is happening with the app. If something has changed, it is possible to know what has changed. Actions allow us to track what happened.
Finally, to unite the actions with the application state, we write a function called a reducer, which takes the state of the app and the action as arguments and returns the new state of the app. It is difficult (and unusual) to write a single function that represents the entire state of the app. Instead, it's more practical to write smaller functions that manage specific parts of the application.
Image based on Redux.js
And then we write another reducer that manages the complete state of our app by calling the other reducers by their corresponding states.
Image based on Redux.js
This is the basic idea behind Redux. So far, the Redux API has not been used. It has some utilities to make the pattern easier, but the main idea is that you describe how your state is updated over time in response to actions where most of the code is just JavaScript, without using Redux itself.
Analyzing the Tradeoffs
At its core, Redux is a simple code pattern. Immutability, serialization, and pure functions are not enforced in any way. It is perfectly possible for a reducer to make changes to its state or trigger an API call. It is also possible for any part of the application to invoke a function and then modify the contents of the state tree directly.
The figure below demonstrates that it is possible to use Redux concepts without even using the library. What the Redux API provides is the creation of a single global object for state management. Therefore, it is up to the developer to use it more or less according to project requirements:
Image based on Redux.js
Redux can also insert promises, functions, symbols, class instances, or non-serial values in actions or in the state tree. These insertions are generally not recommended, but they are perfectly possible.
The fact that Redux code is written in functions, and most of it in pure functions, makes it possible to test without resorting to mocking. However, it is still necessary to consider that each part of the code needs specific tests.
Conclusion
In view of the points discussed above, what makes Redux relevant is its concept of functional programming, which means that there is a certain structure and organization in the code. Although the Redux library brings with it numerous optimization features and productivity gains, not installing and using Redux can also be a positive point, since the application would benefit from a good code architecture standard when employing a state management without the need to install any packages.
The states of an application, whether small or large, can be perfectly manipulated by the tools available within the React library, without the need to resort to an additional framework. Thus, what will really define whether a state manager should be used or not within your application is whether, by adopting it, it will bring with it some measurable benefit, be it performance optimization, technical requirement coverage, development agility, or even its ease of adoption considering the team's expertise.
References
'"Core Concepts." Redux.
"Idiomatic Redux" blog series. Mark "acemark" Erikson. Mark's Dev Blog. I Squared Software.
"Redux is definitely NOT dead" with Mark Erickson. JS Party -- Episode #146. ChangeLog.com.
- "You Might Not Need Redux." Dan Abramov. Medium.
