Refactoring Reducer Logic
A scalability proposal for reducer logic in a real case.
Oftentimes we started a project creating the logic to supply the current needs. At this time our code tends to be lean and more objective.
Over time, our application may become more complex, with many features in one module or component. That's when we started to have trouble understanding the code.
By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you’ll find that it is easier to extend and maintain code.
— Joshua Kerievsky, Refactoring to Patterns
In this article, I will describe a bit about a problem I've identified due to the expanded responsibilities of the mapped module and will also show the suggested resolution by refactoring reducer logic.
The project was developed using ReactJS and Redux to manage the state of our application.
Below is the first version of my Reducer Logic, very lean and objective:
This second release has gained a bit more responsibility and functionality due to increased components and screen interactions.
Identify Reducer's growing responsibilities and thinking about future possibilities, considering the increased interactions and state management needs in new features to come, we propose refactoring the code to enable this growth without compromising readability.
I hope this article has somehow helped in the readability of your code. If you've had something like this or have other ideas to solve, comment below about it!
