Redux, in some flavor, is available for any modern JS framework we choose to make our applications better. In a world of SPAs and scalable component-based development, the abstraction and handling of data in a global sense are vital to clean architecture. Despite all the benefits it brings us, it quite often gets overused. So that leads us to one question, when is the wrong time to use redux?
How Redux Works
In short, redux is a global project data store that makes data accessible without being directly tied to components. This then allows us to keep business logic outside of components and stored in a project-agnostic space, allowing them to be used freely. This is just one of the few ways you can go about in creating “dumb” components. All that sounds great and makes you see all the benefits. But how does it work?
Redux can be broken up generally into a few parts: actions, reducers, and state. Actions are handlers that are used to dispatch to our redux cycle that a certain action is happening. Once an action is notified if there are any functions designated as side effects of that action they’ll then run. These are called reducers. As side effects, reducer methods are assigned to an action and once it’s called, its logic runs. It then returns the updated state from its logic. This then brings us to state. The state is the current state the redux store is in and is where our applications pull there data from.
Below you’ll find a diagram that explains this pretty well.
Why We Use Redux
As mentioned before, redux allows us to create dumb components by storing business logic and data models. This is important because the goal in most things we build as engineers should be to make our code as reusable as possible. Removing project specific logic outside of them, and only focusing on functionality, is the most straightforward way in doing that.
When To Use Redux
Now, this is the tricky part. While redux is a great resource to use in any project, it’s necessarily needed in everyone. For example, imagine you have an application that doesn’t need to share data across multiple places. Every view state has distinctive data needs to properly function, and there is no need to share any information between them. Would it really make sense to use it here? NO!
In this case, it would make more sense to create a parent level component that can store business logic, and then pass it down to its dumb children. The then said children can be used between all parent components, representing view states here, freely. This way we still keep the desired goal of having the majority of the project be reusable code and cleaning separating business logic into a general place smartly.
In Closing
Redux is a great tool that greatly improved code quality in the Javascript world. However like with all great new tools, they’re only great when used responsibly. Despite how much good it does, if used in the wrong way it can create overly unnecessary structured project. Use it smartly, and enjoy the benefits!