This article was originally posted here.
Redux is a predictable state container for JavaScript apps. - redux.js.org
As a relative newcomer to all things web development, I came across Redux mere seconds after I started using React.
After what I would say is a fairly steep learning curve, having only just been introduced to state and props, I slowly but surely began to understand how to use Redux, and why it is such a useful weapon when developing web apps.
And that is where my troubles started, I fell into a Redux quicksand of sorts. Every new component I created had its own Redux store. Every single API call had at least one Redux action, and I was forever calling 'SetCurrentUser', or 'ClearCurrentUser' actions just to keep track of things!
Just because you can, doesn't mean you should
I had built multiple redux stores, all with the same functionality for slightly different components, my redux folder was becoming bloated, and sure, my component files were nice and slimline, but at what cost.
So now when I create a new component, and I reason as to whether to Reduxify it, I as myself the following:
Do I need the data from the page to persist when I navigate away? Or can I just make the call again when I come back to the page?
More often than not, the answer (to the first part of the question!) is no! And I can just use the components state to handle the data.
I now use Redux for things like Auth, and Permissions, bits of data that I need in more than one place.
This is a massive oversimplification of a complex topic and there are many great articles out there about it, but this is my hot take and a great place to start.
Top comments (0)