Goodbye, useState

Hello, React Summit and goodbye, you states. What do I mean by that? Let's get right into it. So first of all, who am I? Doesn't matter. You just heard, we have way too much to talk about.

But if you really need to know or stalk me on the socials, I'm David K. P. and I'm pretty much everywhere online. I created the library Xstate, which is a state machine library that if you saw the first talk, then you saw it demonstrated there. And speaking of states, I live in Florida, which is a very common migration path from New York.

I know we're not in New York, we're sort of in the wrong state, which is also the theme of my talk. But anyway, also I gave a talk a few years ago called Goodbye Use Effects, a very similar to this one. And in that talk, I explained a lot of the pitfalls of using use effect, why it's sort of a defective hook that is just sort of a really convenient foot gun. And of course, as expected, a lot of people were pretty angry about that talk saying this guy knows nothing about React.

Use effect is super useful. But then, you know, stuff like this happens. And it happened again today, OK? I didn't plan it. I didn't cause it. But yeah, Foul Player is down again. I think they're still down. I'm not sure. It's because of use effect. But the React team actually came out with docs saying you might not need an effect. And these docs were pretty much my Goodbye Use Effect talk. So I might do the same thing for use effect that I did for use date because, honestly, we need to talk about it.

You know, this is not really OK. You know, we do have people online going like, hey, yeah, all we have to do is add another use date because what's the big problem with this? But I'm going to try to argue that you shouldn't do this, and we're going to explore some better patterns. Because you might be thinking, like, hey, use date is fine. I add one to my app. It's one of the simplest hooks. There's nothing really wrong with that. But then, you know, you add more, and it turns to use 8, and then things just sort of spiral out of control. And at that point, you're not vibe coding anymore. You're doing vibe state management. So it becomes a huge problem.

But, you know, what exactly is the problem with use date? It's not just use date in isolation. It's how use date interacts with everything else in your app logic, where you might have a use date being used in a use effect that needs to also update another use date. And then that might affect props in another component, which might trigger a use effect there, which calls use date internally in that component, which updates a prop, which calls use effects somewhere else. So it just becomes this huge, huge mess. This is actually an example of some real public code I've seen. And I mean, just look at this handler. I'm not saying this is bad. I'm not trying to shame them. This is actually a small startup.

And I understand that with small startups, like, you really just need to ship quickly. You don't have time to really think about best patterns or anything. You just gotta get something working. This small startup is named Microsoft, by the way. And it lets us...

But you know what? You might not be even the one writing the use date code. It might be generated by Cursor or GitHub Copilot or one of the butthole AI logos. You know, there's three of them. You need to understand that LLMs weren't trained on good code. They were trained on your code. Not your code, but just developer code in general. So I do want to reiterate that the problem isn't...

Oh my gosh. There's so many use dates in this component. It's more so that it's hard to understand when you have a lot of use dates and they're being used in many different parts of the component, which makes it harder to test and fix bugs because you have to create that mental map of how everything is interacting with each other, which in turn makes the code really hard to maintain because of all of those bug fixing and just the mental load of understanding it. And besides that, even if all of that was fine, you have performance issues once you have more than one use date inside of your component. And I'll explain that in a minute because everything re-renders.

And of course you have too much... Sorry, I didn't mean to add that one in there. You didn't see that. All right, so let's first talk about overusing states. This is something that we see a lot where we're using states for more primitive values like strings and numbers and booleans and stuff like that. I want to say it's absolutely okay and even recommended to group-related data. The way that you use date is a little bit different once you do this. And you do have to do some finagling of the objects to get the proper properties to work, but there's solutions for that too. You could, for example, use emir, which if you haven't used emir before, it's sort of like immutable JS without all of the fancy ceremony because you just write your code as if you're mutating it. You're not really mutating it. It feels like it is, but yeah, you could just update it directly.

When I have nested data, which is also something you should avoid, use something like emir or mutated, which is another library to actually update that nested data. Also controlling re-renders. So like I said earlier, performance does become an issue with use date, especially when you have a lot of use date in the same components. So if you've been working with React for any amount of time, you can immediately see the problem with this where any change in value is actually going to cause this entire components tree to re-render. So there's two strategies for that. The first one is you could actually localize dates to just the components that need it, or you could also use context.

So in this case, we have a value provider and we're using value context in each of these components, it becomes a lot cleaner. Now, I know some of you are going to be thinking this, like, hey, this is a problem. My provider. I will actually argue that it's not a problem. This is actually not that bad. In fact, it's a feature in Next.js so that they can fit more triangles inside of your app. But, you know, if you really, really hate this, there is a solution. Go into your VS Code settings, set your tab width to zero, problem solved. Okay? You don't have to deal with that. Another thing that you can do is when you have states that actually doesn't really need to re-render the component, that's also an indication where you shouldn't actually be using use date. So in this instance, we're tracking the number of times the button is clicked, and this is actually a really good way or a really good use case for use ref where you could use ref instead and sort of avoid going through that re-render cycle, because this will not cause a re-render. So just remember, if states do not need to cause a re-render or are not involved in rendering, including passing props, use ref instead. Use ref is for internal state, not related to rendering.

Another big one. This is when I see where this pattern might look fine, where we're controlling whether a table is ascending or descending. But the problem is when you refresh the page or when you want to share the page, all that status is lost. And that's actually a sign that you can use URL states or query states. So Nuxt is actually a great library for this, where instead of use state, you use query states at the default value, and all of a sudden, this is actually part of the URL. And so it's like a superpower to use states for URL query parameters to highly recommend this library. And also Nuxt and ShadCN are great libraries with weird names, so.

Yeah, but it's, you know, any time you see a library with a weird name, try it out, it's probably really good. Here's another big one. Fetching data. Okay, so we've probably all seen this code before. In fact, I dare you to look in your React code bases and search for set loading or set is loading. You're going to see a ton of this stuff where you're just regurgitating these same patterns over and over again. And I know some of you might say, fetching and use effect is fine, but you end up with all of these use states and your components get really messy. We have better patterns for this in React 18, React 19.

And then finally, we have RSC, React Server Components, where you can just await in the components and then just use it directly in the rendered JSX. There's another pattern which I do wish people used more, which is use transition. So use transition actually facilitates async, you know, async requests and actually having that is pending state as well. So in this case, this is just almost straight from the docs. We're getting the number of saved slices from, you know, this await update slices function. And then we start a transition to set the slices again. That will update our states over there. And we already have our pending state, so we could use it directly in the component. This looks so much cleaner than our, you know, fetch inside of a use effect example. Or you can just use React, well, I guess it's called Tanstaff query, because it's honestly going to handle fetching data and caching better than you will for more advanced use cases, and even for the basic ones, too. Forms are another huge culprit as well. You know, we will let's say we'll have a user bioform where we have to add the first name, some other variables, set the bio, et cetera. And we have to include this in the components, make it controlled, add it to the value. And when it changes, we need to update the state. It's all very, very manual.

And then we're reading that inside of our function. And this is a closure. Closures cause problems, too, if you're not careful. But there are better patterns. In fact, this one is built directly into the browser. It's called form data. So the idea is that you actually don't need to make this a control component. You just give it a name. And then in handle submit, all of that data is inside that form event. So you could just read it from new form data of that events.target. And if you want to make it type safe and also run time safe, you could parse it with Zod. And you could be assured that the data is exactly what matches.

This zero use date, it makes it really, really easy. And this is actually the pattern that Vercel recommends a lot. They use the use action state hook to update that state, and you could actually read it inside of a server action. So we have create user here. We have the form data there. And that's all you need to do to hook up that form data. Now, if there is anything more advanced you need to do, then just use something like tan stack form or react hook form or even final form by Eric Rasmussen, because they handle complex forms better than you, probably.

Another one, discriminated unions. And this sounds like something really bad politically, but it's actually really good in React. Let's go back to our loading example. We have data, loading, error. But the problem is that these are three separate use dates. What if loading is true, but we also have an error, but we also have data? Now, you might say, hey, that could never happen in my code. But there's nothing here that prevents that from happening. So we could have an impossible state. We could have conflicts in our states. So one way that we can mitigate that is we could have a status as a string enum instead, so instead of Booleans, we know we can only be in one of these states at a time. Idle loading, success, or error.

And then we could use it down here and set the status. And then we could render based on that. There is one small problem with this, though. We still can't guarantee whether we have an error or whether we have data when it is success. So what we could do instead is create that discriminated union. And so this combines the status and the data or the rest of the state that is related to that status. So we know that when we have an error, there's going to be an error string. And when we're in the success date, there's definitely going to be data. And so we just set that all at the same time, which makes things pretty convenient. So now we're reducing our use states to just one call. And as a result, we have perfectly type-safe states.

All right, moving on to the next one, and I know we're moving fast. Like I said, there's a lot to talk about. Derived states. This is a huge one that I see even senior developers make the mistake of making. So we have our core states, our essential states. So for example, the number of donuts that we have selected. Let's say that we're having an order form. But we also have derived states where this information can actually be derived from our essential states, like the total number of items, subtotal tax, et cetera, price. And then you typically see this, in a use effect, you're recalculating every time one of those things change. And there's only one item in this dependency list, but I've seen really long dependency lists where they're using all of that state to derive that data.

So what's a solution here? Just derive it directly in Render. So this should be basic knowledge, but I guarantee, look in your code bases, whether you're junior or senior, you're going to see that you have a lot of state that could be derived, and you could get rid of so many of those use states. I know what you're thinking right now. Not this, sorry. You might be thinking, I hate use states. There's so much in my app. I'm here to tell you about useReducer. And you're probably thinking this. I know, I know.

It gives Redux 1.0 vibes, but useReducer is actually really useful, because before we had these ad hoc functions, we had useState over here, and we could instead convert this to a reducer. Now, I'm not going to try to sell you hard on useReducer. I'm just going to say that by using a reducer, we centralize our logic, and that makes it actually really easy to do things like separate that logic and write tests for it. And you might think, I don't want to write tests. That's why I use one of the butthole logo companies to do it for you. And in my opinion, using direct states manipulation, it does lead to ad hoc logic, because that logic is spread out everywhere, and you don't have a centralized place for it. But by using event-based logic, you get to centralize that logic, which again, makes it easier for testing, easier for understanding, and things like that.

There's also a really cool hook called useSyncExternalStore. And this is part of the other hook section in React. And I'm not going to talk too much about this, because you probably won't be using this in your day-to-day application development. But I do want to mention that one of the most powerful patterns that you could do is having a store, just a store instance, and passing those into composable components, instead of having these God components with a massive list of props for you to manipulate the internals and to check when things change. A store works wonderfully, and it's evidenced in libraries such as TipTap and other related libraries, where you just create the store and pass it down. And all those are most likely powered by useSyncExternalStore. So it is something to try.

The React docs will tell you, like, hey, maybe you should use state and useReducer instead. Give it a try, okay? But that leads me to third-party libraries. So how do we get to this point? Because some people might say, oh, we only need useState and useReducer. Do we really need anything else? Of course, if you want state, you use state. If that state has special logic, that's a great use case for useReducer. If you need to share that between components, then useContext, which this is an outdated hook, it's just used now. It's causing too many re-renders. So you might use, like, a subscription pattern. You might not need the entire state, so now you have to create this custom useSelector sort of thing, also to prevent too many re-renders. It's increased my rent. You use Saran Lambdani. And congratulations! You have just reinvented Redux. And Mark Erickson would be really proud of you. So there's two ways that stores typically manifest themselves in apps when you use a third-party library. You could either import it directly, or you could share it via context. And there's a lot of options for state management.

And of course, since I have the stage, I'm going to tell you not about XState, but about XState Store. Because XState Store is a smaller library. It doesn't let you create a full-on state machine, but it works just like Zestand and Jotai combined to allow you to provide context, transitions for how the data changes, and you could subscribe to that state or that store, you could trigger events to send to the store to update state, and you can use it inside your components as well.

So in this case, let's say we have a donut ordering app, you just use selector, read from the store, and then you just trigger actions or trigger transitions, just like you would with anything else. Hopefully you hate this less. I recommend you give it a try. You could use it as a global store. You could use it as a local store. And you can even use atoms as well. So you could create an atom, set it, you could change it. You can have derived atoms where they will automatically update when the atoms that it's reading are updated as well. And you could subscribe to that. And using them in React can't be easier. You use atom, get the value, and then set the atom wherever you want.

Real quick, I want to sort of talk to you about the future of state management. And that's with local first state or sync engines. Now, the idea is that instead of manually fetching data back and forth between your database, you will sync data instead. So whenever your local data updates, it will update the database. Whenever your database updates, it will update your local states too. It works magically. And this is how things like Linear and Notion work as well. There's a lot of companies behind this. And so I just wanted to give you a preview that stuff like this, it's still very early days, but I believe that this is going to be the future. And yeah, so let that sink in. Okay. Sorry. All right. So use states. Use it for truly components, internal UI state, because not all state is UI state.

Use it for truly components, internal UI state, because not all state is UI state. And ask yourself, is there a better pattern? Because there usually is, especially with React 19. And of course, there are docs as well. One of the most important docs that I feel like you should read is choosing the state structure because it goes through all of these strategies, grouping related states, avoiding contradictions and redundant state, avoiding duplication in states, which we talked about with derived state, and avoiding deeply nested state as well. So please make this required reading. So start with used state, refactor to better patterns, and focus on maintenance, because simple is better than easy. And so with that, thank you so much, React Summit.

All right. Okay. So we got a question from Andrew here. He's asking, is use memo a good alternative solution for handling derived state and ensuring it isn't recomputed each render? I would say use memo only when you need to because what you save in computation cost, you incur in memory cost with use memo. So if you have too many use memos, it could actually cause problems. It's one of those things where you'll know when you need it. It's like, wow, this is slow. This is causing a lot of calculation. So then use memo. And also React compiler, I think now if you use it, it is out right now, I believe. But you can actually use that instead of use memo, because it will automatically do all that. Yeah, that's a good question, Andrew.

Are there any existing linters to help encourage better practices around the use state? I believe there are, not to the extent that I talked about in this talk, but because sometimes it is hard to tell, like, hey, this date is derived, but it's not immediately obvious from traversing the AST or anything like that. But that's a good idea. I might write one. Oh, inspiring. It looks like the connection loss, but I got it. OK, and this one's from JD Collins. In 2025, is there still a place for Redux? Of course, yeah, especially with Redux toolkit. If you are still thinking about the old Redux, you know, with your actions dispatcher, etc., please, please give Redux toolkit a try. Honestly, it's only similar by name and by philosophy, but it's a very different API. I would say that you can't go wrong choosing a state management solution that helps you centralize your app logic, and Redux toolkit does that well, as Dustin does that well, Xstate and Xstate Store try to do that as well as I could.

I would say that you can't go wrong choosing a state management solution that helps you centralize your app logic, and Redux toolkit does that well, as Dustin does that well, Xstate and Xstate Store try to do that as well as I could. So, yeah. So, yes in 2025, and you think in the next coming years? Yes, I believe so, because take a look at a React code base that doesn't have any centralized state management. If it looks fine and if it works fine, then the state management is probably really simple too. Not all apps have that simple level of complexity. So, when things get more complex, centralized state management, whatever you decide to use is the way to go. Just don't try to roll your own. At the very least, use Reducer in context. Sounds good. So, the answer is keep it.

OK, from Katie, is there a difference between Adams and Ustate? Yeah. So, with Adams, which was popularized by Solid and then Recoil, then Jotai also has Adams. The idea is that these are tiny pieces of state where you update them and they should cause updates. So, they're reactive. So, any Adam that's reading that Adam, that Adam will also update due to that Adam. So, it's more for granular, I would call it more data management than state management because you're updating tiny pieces of data, and it is a lot simpler than having a full-blown store or a state machine. So it is a little different than Ustate, yeah. Yeah. Oh, it's up.

Is there a cheat sheet available somewhere that helps reference all of these alternatives to Ustate that you just presented? There's two things. There's the React docs, especially the ones that I linked on one of the last slides that's choosing the state structure. And there's the opposite of a cheat sheet where it's a five-hour workshop that I gave at Frontend Masters. If you have a subscription, then I teach it there too. Nice. Well, I'll write a blog post or something that summarizes it all. Are you sure you just don't want people to listen to you talk for five hours? No, I can't talk for five hours. No one wants that. Oh, wait, we have an imposter here. The better Daphne.

The better Daphne. I did not ask that, but sure. Does that imply that someone else thinks... Okay. How do you encourage your teams to avoid Ustate and affect loops? I mean, that's up to your team, really. You can do it at the code review stage or you could just show better patterns. I would say nowadays, one of the things that we really disliked about UseReducer is just how much boilerplates and how much we had to type the actions and dispatch events and everything like that. But with AI-Assisted Coding, you just tap, tap, tap, and it will do it all for you. And AI-Coding assistants love explicit code where all of the text is right there. So honestly, give it a try. UseReducer is easier to write now than ever. Yeah, AI-Assisted. I cannot look at the logos the same. I'm sorry. I saw it somewhere. I'm like, you know what? That does look like a body part. Yeah.

How would you handle form validation state from nd? When you get to form validation, there's a couple of things you could do. You could use either the built-in HTML5 validation API. But if you get anything more complex than that, that's when people would argue, oh, I need use state, etc. That's when I would actually go to one of the form management libraries, like Final Form, TanStack Form, or React, the Hooks Form. Yeah. Makes sense. This one is from Mark. Why are event-based update patterns more maintainable in the long term? It really depends. If you have very simple states, then it might not be, because it's like, okay, I just need to update. I don't need this indirection. But the main reason that they are is it allows you to centralize your logic so that instead of having a handler that calls 20 use states, it's like, imagine if you forgot one of those or if another developer on another team decided to call use state directly on something where you're like, oh, no, you're not supposed to call use state directly there. It helps you centralize your logic and have it all in a single place, which it's good for understanding, because you only have one file to read.

It helps you centralize your logic and have it all in a single place, which it's good for understanding, because you only have one file to read. And it's good for testing too, which I think is extremely important. You should be able to test your logic in isolation. Yeah, that sounds super helpful.

What is your favorite sync engine to try out from Kiran? I have actually, I wouldn't call it a sync engine directly. I have been using Convex. I would also recommend LiveStore by Johannes Schickling. Yeah, I've heard of Convex. Cool.

What are your thoughts on using 10-Stack Query Global Cache for a global state management solution? I haven't used it yet. Don't tell Tanner he's in the other room, so he won't hear me. But I trust everything that Tanner does in all of 10-Stack, so I would definitely recommend trying his stuff. Sounds good. The secret stays in this room. And from Brendan, what are your thoughts about use effect events? Do you think that will make the relationship between use state and use effect more stable? Use effect events is like one of those required hooks now, because I believe a lot of people are still using use callback and having that huge dependency array. So use effect events allows you to really avoid that ugly dependency array. It avoids the stale closure problem, and it's something that you definitely should use more often. Awesome. All right. That's all the time we have for questions. Give it up for David one more time. Thank you.