When working in redux recently, my team and I found ourselves writing a lot of unnecessary logic in functions to keep certain leaves of state from firing off because one listener was triggered. By writing a lot of this logic several ideas arose as how we could move some of the logic out of my functions that triggered reducers, and be more dynamic. In doing so we thought of the idea of adding methods to redux that handled certain actions and overall gave me more control over the state object. Some challenges we faced were; distinguishing between keys in a deeply nested state object, intercepting dispatched actions before making changes to state, and making tradeoffs between space and time complexity, something we are still going back to and evaluating.
We wanted to find ways to be able to distinguish between deeply nested leaves of state and maintain a functional approach. We wanted to be able to do many things with this functionality. Rather than having a bunch of listeners be triggered on any state change, the ability to update specifically subscribed leaves of state would allow us to have more control over what was happening across my state tree. The value we see in this currently is as an application scales, it has less work to do than if every listener is triggered or checked. We then deeply compare both the previous state and new state object for changes. By doing this we limit the amount of business logic, and our application has to do less heavy-lifting as its not processing as much data that hasn’t changed.
Second, we found that the ability to access these leaves of state resulted in my ability to lock state, or freeze partials of state. In other words, we were able to abstract a lot of logic out of our functions that would otherwise be needed to prevent certain things from happening through conditionals. For example, we made a simple tic-tac-toe game, that when a box was clicked on, we would lock or freeze that piece of the game board, and no longer needed the logic to prevent that piece from changing. The ability to simply dispatch one action to lock a piece of state was one line of code. If we were in a similar situation in a separate application, the ability to simply dispatch an action and render that piece of state immutable may prove extremely valuable. Of course, the implementation of unlocking a leave of state was also added.
In closing, we decided to create these functions as we saw fit, however we see application in them as a middleware to redux. As we iterate over it and go through the process of improving it, and optimizing, we are wondering what value do others see in it? What kind of application are you working on where you think some of this could be applicable? Give us some thoughts on the subject.
Thanks
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!