I'm a global state kinda guy, but not in a super dogmatic way. I've encountered a few spots in the last little while where encapsulating a little bit of state inside a component just made more sense than having some reducer somewhere deal with it.
In a pre-redux react app, you'll find me utilising local state more frequently. But with redux in play, I'm all about the global, single source of truth and state (with the exception of the few cases I mentioned earlier).
What do you think about the journey from local state to single-source-of-truth as a codebase evolves? Any thoughts about the the ease of this transition if it needs to take place?
That's a really great question. The complexity of the transition can vary pretty wildly depending on the existing architecture of the application.
If I had to give a one sentence answer, I'd say "It's not easy. But it's not super hard either".
In the past I've attacked this transition by incrementally moving an app with scattered local state (and no redux) into a more "thinking in react" style. I'd typically start this process at the smallest leaf node that's managing its own state, and push its state up to a logical parent component (like a form or page) and continue from there.
I don't think I'd consider introducing redux into an application until it had a good Container/Component structure, with most of it's state being managed by a few Containers.
From there it's a hop, skip and a bit of boilerplate to add redux, "connect" those Containers and combine their reducers into one big ol' blob of state.
To expand on my one sentence answer: It can be a pretty big job, but it can easily be done incrementally, which makes the whole thing quite manageable.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm a global state kinda guy, but not in a super dogmatic way. I've encountered a few spots in the last little while where encapsulating a little bit of state inside a component just made more sense than having some reducer somewhere deal with it.
In a pre-redux react app, you'll find me utilising local state more frequently. But with redux in play, I'm all about the global, single source of truth and state (with the exception of the few cases I mentioned earlier).
What do you think about the journey from local state to single-source-of-truth as a codebase evolves? Any thoughts about the the ease of this transition if it needs to take place?
That's a really great question. The complexity of the transition can vary pretty wildly depending on the existing architecture of the application.
If I had to give a one sentence answer, I'd say "It's not easy. But it's not super hard either".
In the past I've attacked this transition by incrementally moving an app with scattered local state (and no redux) into a more "thinking in react" style. I'd typically start this process at the smallest leaf node that's managing its own state, and push its state up to a logical parent component (like a form or page) and continue from there.
I don't think I'd consider introducing redux into an application until it had a good Container/Component structure, with most of it's state being managed by a few Containers.
From there it's a hop, skip and a bit of boilerplate to add redux, "connect" those Containers and combine their reducers into one big ol' blob of state.
To expand on my one sentence answer: It can be a pretty big job, but it can easily be done incrementally, which makes the whole thing quite manageable.