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.
Putting everything in Redux will often be too heavy handed, particularly for aspects like visual states (show/hide/expand/style content); however, data values attributes I will put within the global state as for me it is easier to track when, how, and what data is changing to.
I also find the issue of having some data values being handled within local state, and other within global state a nuisance to debug.
I completely agree with this, I find the idea of putting visual state in a store mental no matter how big the app is.
In my case I use a setup where flux stuff is shared between react and react native so all data is decoupled from platforms which just feels correct to me as it could “live” anywhere, even on the server.
There is no “right” answer for this. Some users prefer to keep every single piece of data in Redux, to maintain a fully serializable and controlled version of their application at all times. Others prefer to keep non-critical or UI state, such as “is this dropdown currently open”, inside a component's internal state.
Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.
Some common rules of thumb for determining what kind of data should be put into Redux:
Do other parts of the application care about this data?
Do you need to be able to create further derived data based on this original data?
Is the same data being used to drive multiple components?
Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
I've talked to people who chose to put literally everything into Redux. You can do that, and I can understand why you might want to do that, but I personally think that's way too dogmatic.
Part of the issue is that Redux's principle of "a single source of truth" gets over-interpreted to mean that you must put everything in Redux, which isn't the case. It's really more like "a single source of truth, for the data that you decide is worth keeping in Redux".
I think much of the confusion around using Redux is because people don't understand some of the background behind it. I wrote a two-part post, The Tao of Redux, Part 1 - Implementation and Intent and The Tao of Redux, Part 2 - Practice and Philosophy, which tries to explain that background and add context. These two posts look at the history and intent behind Redux's design, how it's meant to be used, why common usage patterns exist, and some of the other ways that you can use Redux.
I am puzzled by this. Object oriented programming and local, object-bound states have worked very well for me in the past 20 years. Globals - call them global state, or call them just globals because that's what it is - always cause trouble over the lifespan of a product.
If it's a simple product, you can deal with the trouble (add more cases!). This costs time.
If it's a complex product, you will get into the "unmaintainable, unfixable, basically throw-away" state of codebase very quickly.
The less all the different pieces of code know about each other, and need to know about each other, the better. You get a better codebase, with fewer errors, that is much easier to maintain. The only downside is you have to think about your architecture so your initial implementation might be a bit slower, and you might have to refactor a few times along the way as it's impossible to get an architecture right on the first try.
Don't use global variables is basically one of the tenets of programming. I don't think that there's exceptions to where this would not apply, or that somehow because of some framework, it's OK now.
High coupling is a bad practice in software engineering. Global variables lead to high coupling.
It seems like the same lessons have to be learned over and over again?
Local state always! Global state is an anti-pattern.
Preference for the global state originates from the unawareness of the problems related to global, shared variables. Software development has already learned the lesson and switched to encapsulation, local variables, etc. But I guess not everybody read the right books, or they think the front-end is a different story.
History has proved that the front-end and javascript are going through the exact same path as all other programming languages already did. Therefore, it's only a matter of time that the global state becomes an official anti-pattern in React, too.
BTW, I'm glad to find out that it's not only me who is puzzled with this all global state direction! Thanks for this discussion!
I've never felt the need for Redux (well, VueX in my case).
Global variables were bad before, putting getters and setters on them don't make them good, do they? Am I not seeing something? I'm not being sarcastic, just looking for good reasons.
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.
Putting everything in Redux will often be too heavy handed, particularly for aspects like visual states (show/hide/expand/style content); however, data values attributes I will put within the global state as for me it is easier to track when, how, and what data is changing to.
I also find the issue of having some data values being handled within local state, and other within global state a nuisance to debug.
I completely agree with this, I find the idea of putting visual state in a store mental no matter how big the app is.
In my case I use a setup where flux stuff is shared between react and react native so all data is decoupled from platforms which just feels correct to me as it could “live” anywhere, even on the server.
Hi, I'm a Redux maintainer. I'll quote the Redux FAQ entry on component state vs Redux state:
I've talked to people who chose to put literally everything into Redux. You can do that, and I can understand why you might want to do that, but I personally think that's way too dogmatic.
Part of the issue is that Redux's principle of "a single source of truth" gets over-interpreted to mean that you must put everything in Redux, which isn't the case. It's really more like "a single source of truth, for the data that you decide is worth keeping in Redux".
I think much of the confusion around using Redux is because people don't understand some of the background behind it. I wrote a two-part post, The Tao of Redux, Part 1 - Implementation and Intent and The Tao of Redux, Part 2 - Practice and Philosophy, which tries to explain that background and add context. These two posts look at the history and intent behind Redux's design, how it's meant to be used, why common usage patterns exist, and some of the other ways that you can use Redux.
If anyone's interested, my React/Redux links list has sections on React State Management and Redux Architecture, which point to a lot of additional info on this kind of question.
This is one good answer. Thank you for sharing this!
Local all the way.
But I'm used to a rigid app structure.
State local to screens (=top level components) filled with dumb components.
That's exactly how we do it.
I am puzzled by this. Object oriented programming and local, object-bound states have worked very well for me in the past 20 years. Globals - call them global state, or call them just globals because that's what it is - always cause trouble over the lifespan of a product.
If it's a simple product, you can deal with the trouble (add more cases!). This costs time.
If it's a complex product, you will get into the "unmaintainable, unfixable, basically throw-away" state of codebase very quickly.
The less all the different pieces of code know about each other, and need to know about each other, the better. You get a better codebase, with fewer errors, that is much easier to maintain. The only downside is you have to think about your architecture so your initial implementation might be a bit slower, and you might have to refactor a few times along the way as it's impossible to get an architecture right on the first try.
Don't use global variables is basically one of the tenets of programming. I don't think that there's exceptions to where this would not apply, or that somehow because of some framework, it's OK now.
High coupling is a bad practice in software engineering. Global variables lead to high coupling.
It seems like the same lessons have to be learned over and over again?
Local state always! Global state is an anti-pattern.
Preference for the global state originates from the unawareness of the problems related to global, shared variables. Software development has already learned the lesson and switched to encapsulation, local variables, etc. But I guess not everybody read the right books, or they think the front-end is a different story.
History has proved that the front-end and javascript are going through the exact same path as all other programming languages already did. Therefore, it's only a matter of time that the global state becomes an official anti-pattern in React, too.
BTW, I'm glad to find out that it's not only me who is puzzled with this all global state direction! Thanks for this discussion!
I've never felt the need for Redux (well, VueX in my case).
Global variables were bad before, putting getters and setters on them don't make them good, do they? Am I not seeing something? I'm not being sarcastic, just looking for good reasons.
I was raised with local state so I'm quite biased towards local state encapsulated in object or modules.