I'm having a bit of trouble following exactly what this approach does, but I'm seeing a couple things that look like a bad idea.
First, re-running persistence logic in a component seems awkward at best, and doing so in componentWillMount is definitely a bad idea (if only because that lifecycle method is now deprecated).
Second, a reducer definitely shouldn't be interacting with local storage. That makes it no longer a pure function, and while the code might work, it's distinctly a bad practice.
Finally, this whole recursion aspect also seems overly complex. One possible approach might be to load the data as its own distinct action, and have appropriate reducers be responsible for filling in defaults as needed.
thank you so much again for your suggestions, the reason why i wrote this article was because this was actually a pretty difficult implementation for me to understand, so i wanted to solidify my understanding of what was going on by writing an article, im still a junior dev training
I also wanted to also maybe help out the community if i could with my experience.
thank you so much for the suggestions, we are actually in the process of refactoring our actions and stores to a new version, and i can fit your suggestions into the new version of the reducer
we will definitely be taking it out of component did mount.
using an external library to handle local storage sounds like a good idea, especially if its a library tailored to redux.
thanks for your suggestion about removing local storage from the reducer , i wouldnt of known another way.
my senior engineer actually suggested that this be built this way, so i will bring up these suggestions when we refactor
i dont quite understand what you mean by loading the data as its own distinct action?
it is its own action , that happens once at the root component . could you maybe show me a code example of what you mean?!
thanks so much for reading ! :D really appreciate your time
You could also have each individual slice reducer look for "PERSISTED_DATA_LOADED" and separately respond by pulling the bit of data it cares about out of action.data or action.payload or whatever you want to call it, and return that.
As for setup, typically persistence handling is done when you're creating the store on app startup, either by grabbing the persisted data first and passing it to createStore(), or dispatching some kind of "load the data" action right after you create it:
I'm having a bit of trouble following exactly what this approach does, but I'm seeing a couple things that look like a bad idea.
First, re-running persistence logic in a component seems awkward at best, and doing so in
componentWillMount
is definitely a bad idea (if only because that lifecycle method is now deprecated).Second, a reducer definitely shouldn't be interacting with local storage. That makes it no longer a pure function, and while the code might work, it's distinctly a bad practice.
Finally, this whole recursion aspect also seems overly complex. One possible approach might be to load the data as its own distinct action, and have appropriate reducers be responsible for filling in defaults as needed.
There's dozens of existing Redux addons for persisting your state - I'd suggest evaluating some of those, and using one of the existing solutions instead of something homegrown.
thank you so much again for your suggestions, the reason why i wrote this article was because this was actually a pretty difficult implementation for me to understand, so i wanted to solidify my understanding of what was going on by writing an article, im still a junior dev training
I also wanted to also maybe help out the community if i could with my experience.
Wow!
thank you so much for the suggestions, we are actually in the process of refactoring our actions and stores to a new version, and i can fit your suggestions into the new version of the reducer
my senior engineer actually suggested that this be built this way, so i will bring up these suggestions when we refactor
i dont quite understand what you mean by loading the data as its own distinct action?
it is its own action , that happens once at the root component . could you maybe show me a code example of what you mean?!
thanks so much for reading ! :D really appreciate your time
As a simplified example, you could have a higher-order reducer that looks for a
"PERSISTED_DATA_LOADED"
action and returns that:You could also have each individual slice reducer look for
"PERSISTED_DATA_LOADED"
and separately respond by pulling the bit of data it cares about out ofaction.data
oraction.payload
or whatever you want to call it, and return that.As for setup, typically persistence handling is done when you're creating the store on app startup, either by grabbing the persisted data first and passing it to
createStore()
, or dispatching some kind of "load the data" action right after you create it:But, as I said in my first reply, there's many existing libs that do this kind of stuff for you automatically once you set them up.
whoa! this is genius!
thank you so much for taking time to explain this to me !
its much clearer seeing the code for it.
Didnt even cross my mind to have a higher order reducer , what a great idea !
Will suggest a change to our team !
But first, I will look into the other library options for this first of course!
thanks again so much for your time