Managing React State: 10 Years of Lessons Learned

Hello, we're going to talk about effective React state and 10 years of lessons learned. I'm lucky enough to have been working in React since it was open-sourced about 10 years ago, so these are some lessons I've learned along the way.

This whole talk is going to be about state management. We've got about 20 minutes to work with here.

Let's start off with one of the things that I see most commonly in code reviews which is separating related state. This solution is quite simple which is to unify related state. Now, when I talk about related state, the concept here is to think about state where properties apply to one another, where they relate to one another. A good way to think about this is if I jump over here for a moment, I have a little app set up which is using Vite. I'm going to zoom in a little bit here, make sure everybody can read the screen, and then I have the app running over here on the left so we can see the words hi over there. Now, what if I were to come in and I were to say, create some state, and I wanted to create some state like my address and set address, and my city and set city, and my country, and so on, so you can start to see how I've created this separate state for address, for city, for country. And this is what I mean by related state. These are related because presumably when I'm actually going to go save this state to the server, what I'm going to do is send one HTTP call to send my address, and my address is composed of my street address, and my city, and my country, and so on. So what's useful here is instead of having three pieces of state, is to just have one piece of state, which might be called my address, and set address, and then this would be an object that would contain things like my city, state, country, street address, and so on. So unifying that related state has a couple of benefits. One benefit is, notice that I have one use-state call here rather than two, three, four, five, six. Could be a high number. The other thing is, when I go to initialize this, it's simpler because think about what might happen. Imagine this is a form that is going to be populated with data from the server. So I'm gonna go fetch some data via HTTP, and then I'm gonna put that data into state. Well, if I'm going to do that, it's easier to take the object that I get back from the server and put it into one piece of state than to split it up into separate pieces of state. The other reason this is useful is, when I go to send this back to the server, presumably, I'm going to want to send one object to the server, not a bunch of separate HTTP requests. So when I go to send this back, it's also simpler. Excuse me. Okay, so that's the first lesson, just grouping-related state.

Another place where you'll commonly see this might be where somebody chooses to create state like for user information, and I might have first name and last name and all these other pieces of data that relate to the user, maybe their age and their pets, who knows, whatever information we're happening, where you happen to collect. Again, group this into a user object, we have one piece of state, it's easier to hydrate and easier to send. So that is the first lesson that I've learned.

The second one that I've learned is, watch out for when we make multiple use state calls in a row. And when we see this sort of thing, it's often a sign that we should either unify those set states together by unifying the state, much like what I just showed earlier, or it could also be a sign that we should consider using UseReducer. Now, I will say, I just recently did a poll on Twitter and it surprised me because about half of React developers have literally never used UseReducer, and this was thousands of people that replied to my poll, and then there's a fair amount that say that they virtually never use it.

So UseReducer is an underutilized tool, and it really is a wonderful hook that I think people often forget about, so I'd encourage you to think about using it more. And when I talk about unify, if I come back over here, I'm going to click on unify so you can see what I'm getting at here. So these pieces of state, this is not as powerful as UseReducer. I can't test it in isolation. I can't validate that data before setting it. So it's probably preferable to go ahead and use UseReducer instead, but this is what I was getting at. When we talk about UseReducer, one of the things that it does really nice is protecting our state. So I found that can be pretty useful. So we can look here. I could actually check and say, okay, I'm not going to actually set this state because I want to do some kind of logic here just to make sure that the payload that I've received is what we expect. And this is one of the powerful things about UseState or I'm sorry, about UseReducer is it protects our state. Think about UseState, it doesn't protect itself. We can just call the setter whenever. So that is a benefit that's unique to UseReducer. And also with UseReducer, I can end up avoiding making multiple set state calls. So here you'll notice that I'm calling SetUser and I'm calling SetIsLoading. Well, instead I could just dispatch and say SaveUser and then behind the scenes, the UseReducer call, the reducer inside of it, can actually update one or more pieces of state at the same time. So what I look for is in code reviews, when I see setstate getting called multiple times in a row, it makes me think maybe I should unify that state if it's related or maybe we should just consider UseReducer instead. So that was point two.

All right, let's pop back over here and look at the next one. Another thing I often see is syncing state and useEffect. And by that, I mean, sometimes we will see someone use useEffect to say, there is this state change that just happened in my component. And then when that state change happens, I wanna come over here and run some logic and then update other state. The problem with that is, it's needless. It's actually a sign of needless state altogether because what you can typically do instead is deriveState. And derivingState is an underutilized tool as a React developer.

And I can show you a very contrived example if we pop over here into the code again. Imagine for instance, that I have a simple state right here. Well, in fact, I have it handy right here. So I've got firstName and lastName, and I'm gonna do something silly in here. I might come in here and say, okay, I'm gonna go ahead and use useEffect. And I'm going to use useEffect to do something like this. I have const fullName right here, and I'm gonna have a setter for fullName right here, and I'll just set it to an empty string initially here. But then in this useEffect, I might wanna say that I wanna set fullName to firstName and lastName, and I would want to run this anytime that firstName or lastName change. Now, you'll look at this and you're gonna think, well, this is silly. I wouldn't do this. I recognize that I could get fullName by just taking firstName or lastName and gluing them together. But in reality, we can easily make this mistake when we end up with more state and we don't realize that we could derive values from that existing state. So what I encourage you to do is pay close attention to whether you could derive the values that you need from the existing state.

Now, in this case, the solution is not to use useEffect, and the solution is not to even declare a separate piece of state. It's merely to instead have a value that derives the two. So I could say const, fullName is equal to firstName plus lastName, just like this, or I could use a template string. Now, again, this seems silly, this seems obvious, but I point it out because it's an easy mistake to make when things get more complex. A place that I use this is, you'll often see people declare a piece of state to hold errors for a form, to hold that validation state, to say, okay, here's the errors on the form. You don't necessarily need that state because if you think about how errors work on a form when it's validating, those errors can be derived from the values in the form. So once I know the values and once I know what fields are required, I can actually calculate what validation errors are occurring on every render and then decide whether to show them based on the state of the form itself. All right, so that is tip number three.

Let's bounce over here to tip number four. This one is very common, fetching and use effect.

We've been fetching and use effect since, well, hooks came out long ago and before that we were doing it in component-did-mount. And I consider this a mistake. I know that that is a strong word, but the reason I did consider it a mistake is as React developers, we should probably be using abstractions now and there's lots of good abstractions. And to emphasize, those abstractions are still using React use effect, but those abstractions give us a whole set of goodness that we don't get in use effect.

The tricky thing about use effect is it is so easy to get it wrong and it's easy to forget a number of things that are really important. And when I say that, this is emphasized when you look at tools like React Query, for instance, which is one of my favorite ways to handle this problem. Think about what React Query gives us. It is giving us loading state, error handling, data to store the actual, or I should say state to store the data that we fetch back. And then it's gonna do things like refetch when my connection comes back, it's also going to give me the ability to cache records so that when I move around the application, I instantly see the data that's been previously fetched. I can also clear that cache using keys. It's gonna refetch when I go to a tab, the list goes on. Lots of stuff that is easy to forget. So tools like React query or SWR are really attractive.

Now, I also wanna emphasize though that the other benefit that you get here is just a whole lot less code. So I'm gonna pop out of this for a second. And what I wanna show is, well, I'll go ahead and show this tweet real quick since I have it on the screen. If use effect is the answer, I may be asking the wrong question. So if I ask, how do I sync state? The answer is don't, try to derive it just like I showed in the previous example. If the question is, how do I fetch and play in React? Well, I suggest don't try to use a library that does the use effect behind the scenes for you. And if the question is, how do I copy URL values into state? Don't, we'll use the URL as your single source of truth. So those are some examples where someone might reach for use effect needlessly.

Okay, so let's come over here to the browser for a second. And if I pop into here and well, actually, I can't show it that way, it doesn't want to, I'm just going to pull this browser over instead. Okay, so I'm gonna go over to Twitter because I have a pin tweet that I wanna show here. And this pin tweet is 10 lessons I've learned about handling React state. So you might find this useful because it is definitely relevant to what we're talking about here in this talk. But I wanted to show this particular image. And this image helps emphasize why I say using useEffect to fetch data is really something that should be in the past. What we wanna use is some kind of an abstraction that takes our code and collapses it down. Like you look at the before there.

You look at all the code that's sitting in this begin. Notice that we had to make sure that we put in a finally so that we set loading to false properly. We had to have a catch so that we could have an error and then decide what to do with it. We had to declare three different pieces of state. And then we have to have logic down here for handling all of this. So all this code collapses if you use a custom hook.

Now I actually have a course called Managing React State out on Pluralsight. I just updated it a couple days ago. So the published date is fresh as of 2023. And I actually show how to build this useFetch hook. Now I show that just so that you can understand how to create your own but I don't actually recommend using it. I show it as a teaching tool so that you can see how to use tools like React Query and why they are so useful. So this is just one example. But if I used React Query, my API here would look very similar to this custom useFetch hook that I just showed.

Okay. So we only have 20 minutes. So I wanted to make sure though, that in these 20 minutes that I showed this particular slide. This is the way that I think about React State. And I were to summarize the core opportunity for any React developer here is, make sure that you keep these eight ways to handle React State in your head. One of the most common mistakes I see is forgetting about the URL. We are often declaring state via useState or useReducer that actually belongs in the URL. And a good sign of that is, ask yourself, if I share the URL with someone else, will they see the same things that I'm seeing right now? And if the answer is no, that's a sign we might wanna put it in the URL. Some places that we make this mistake is, when we forget to look at things like, is this accordion open? Is this tab selected? Where am I scrolled to on the page? What header am I closest to? Those are the sorts of things that are really nice to put in the URL. Another example is what page am I on? Or what search or what filters have I run? Those all are wonderful in the URL, so I can bookmark it, and so I can share it. Some of these others I'll breeze past, web storage is not really tied to React, but yes, consider local storage or IndexedDB, those sorts of tools. Local state is the default that I recommend. Declare a used state, put it in one component. If you need to share it with a few, then lift the state, cut and paste it, put it in the parent. As much as you can, try to derive state from existing state. And sometimes maybe you don't even wanna render that state.

You just wanna hold onto the value. You might wanna use a ref. Refs can hold state as well. Keep in mind that refs are also useful for things like undo. So it's something that you wanna hold in the background. It's any variable that I don't wanna render.

Refs are a tool. Consider context if I have global state or global functions. And then finally, third party libraries are wonderful for specific types of state like global state or remote state. When I say remote state, I mean state fetched from a server using tools like React Query, SWR, RTK Query, and so on.

Okay, so we are just about out of time, but I do want to draw your attention to, if you go to twitter.com slash housecore. I've got this pin tweet that has some of the key points that I have made in this talk and others that I didn't have time to make. At the bottom of this tweet, you'll also see that I have a link to my latest course, which is managing React State on Pluralsight. There's a free trial that's available. I will also share these slides so that you can get to the rest of them. Because again, in 20 minutes, I don't have time to go over all the tips I have for state, but I wanted you to have them. So I've put them here. There's about 19 in here, so can't cover 19 in 20 minutes. So if you want to reach out to me, my company is reactjsconsulting.com. I travel around the world and I train teams and I consult companies. I do code reviews, architectural planning. My business is helping React developers be more effective. So I've gotten to do that all over the world. Also, if you want to follow me on Twitter, I tweet once a day about different topics, but often about front-end development in JavaScript. You can find my courses at Pluralsight.com.