An App Developer's Guide to React 19: What You Need to Know and Everything You Can Safely Ignore

Hey, thank you so much, everyone, for being here. I know that right now in the big theater there is a, like, the future of React. Everything is going to be coming down the pipe in the future. And I was actually really excited to have the opportunity to be in a smaller room with people to talk about what React actually means for us today.

For the last, I guess, like five years, I've been doing developer education with various teams. I worked at Storybook and Chromatic for a little bit, and more recently with WorkOS, kind of figuring out the auth thing for everybody. And before that I worked as a front-end architect for a company for, like, ten years. And something that I got to do was communicate how we were going to successfully migrate to whatever new thing that we needed to migrate to and kind of build up a plan for that.

So in this session, you're going to see a lot of diffs, you're going to see a lot of, you know, charts, opinions about kind of what the, like, today, next week, the next handful of months look like for you as you start migrating your apps and building with React 19. So if you're in, let's go.

Okay. So I made the unadvisable mistake of making all of these slides a webpage on my website. So it may be kind of glitchy, but you will have access to them. So if you want to pull those up, you can kind of go through those, click around, do everything. You should be seeing everything that I'm seeing. If not, I'm sorry. It should resolve at some point soon. I have, like, my frame is a little bit weird. I don't know if I did something.

Okay. So first, I'm Chan Tastic on, like, social medias. I used to do a podcast that you may have heard called React Podcast. I stopped a while ago due to my midlife crisis, unfortunately. So now I just, like, you know, post nonsense about microplastics on my social medias. So if you want to hear more of that great content, you can go there. And like I said, I work for a company called WorkOS. We make the best login box in the world, and it's free for a million active users, and it'll take you everything from a prototype to enterprise ready. It's pretty great. So with that out of the way, let's talk.

I want to make sure that if you end up having to leave, like, in five minutes, that you get the most out of this talk. So the big high level feature or kind of things that we're learning about React 19 are as far as I can tell, like, four big things. So first and foremost, if you look at the migration docs, there is a huge emphasis on really encouraging TypeScript. You'll see that a lot of the runtime type safety features that have been in React previously are fully going away. And like half of the migration doc just talks about improvements to types, type, like, partnerships with the TypeScript definitely typed, et cetera. There's also endorsing the testing library philosophy, where you kind of test from the outside in. This benefits accessibility of your components. It's like really is the best way to test. It makes your tests more durable. We're getting away with test utils and shallow rendering and all that kind of stuff. We're going to cover that.

We're also embracing compilers. Other frameworks like Svelte have been doing this since day one. And we're starting to see a lot of motion in that. We're not going to cover that. Sridhar gave a really good talk that includes a lot more detail on the compiler. The docs are probably the best place for that. It's really like an integration thing at this point.

And finally there's just a lot of things where they're embracing the platform a little bit better. Like we'll talk about those features. But they're embracing the platform in a way that I'm really excited about as someone who came up learning HTML and CSS. And I've always felt a little bit at odds with React for how much it owns everything and makes you a React developer. So we're getting a little bit back to the web.

Now, this is kind of, I made a little quadrant graph, if you will, of how I see these features playing into your applications in your life today. So there are things that are internal to React. So things that are core to the React library. There are things that come with a framework, may that be Next.js or Remix or Redwood or other frameworks that haven't even been invented yet. We have removed APIs in React 19 and new APIs. Now I'm thinking about this a little bit like today, what you can do. So there's a version React 18.3, which is 18.2, which is the version that we've had for I think like two years now. But it has, it warrants for all of the APIs that are going to be removed. So this is something that you can upgrade to today, get all your code safe for React 19 when that eventually ships. And then, you know, tomorrow, we have some kind of things that are like kind of on this cusp where libraries are going to have to like update from some of the strategies that they've used. And this may be your responsibility to actually update some or fix some of your dependencies, which we'll talk about in a little bit.

We're not going to talk about this quadrant up here, RSCs and server actions, just because they don't really apply to all React developers yet. And we are going to talk about actions, metadata, scripts, and style sheets, the new APIs that we have. So a quick sheet for you to look at. These are all of the APIs that are going to be going away in React 19, and you'll get warnings for in 18.3. So prop types, dead. Default props, dead. Context types, get child context.

String refs, create factory, module pattern factory. Some of these things, I mean, like you may have never seen in your life before. Test utils, React on render, React on hydrate, unmount component at node, find DOM node, the prop types library is dead, React test renderer, shallow is all going away.

Now, one thing that I really love is the React team has been very dedicated to providing code mods for all of these things, and I've found them to be really well documented. So you can check out the code mods repo. They give you instructions on how to run them. It's pretty great way to migrate your app without having to touch all of the code.

Now, something that's exciting about React is that you can no longer get fired for using secret internals. That's pretty exciting. But also, it means that you may have a very hard time upgrading if you have a lot of unmaintained older dependencies. So we're changing the secret internals prefix, and it's going to be changed from secret internals do not use or you will be fired to do not use or warn users they cannot upgrade. Now, I did a little quick search on GitHub, and it looks like there are, let me open this in the right one. Yeah, it looks like this actually grew since I grabbed this number. There are now 12.3 thousand files with references to secret internals do not use. And so I can almost guarantee that something that you depend on today will probably require an update. And something I always like to say is you own what you install. So this is your problem. It could be a problem for you very soon. So take a good, strong look at your dependencies.

Okay, so type safety in React 19. So you're going to see a lot of diffs at this point. We have some really exciting stuff. This is historical code. This is the type of stuff that I came up on. This was my first experience with type safety, was being able to use prop types, and it really kind of introduced me to the concept of type safety, and it's, I don't know, it has a soft spot in my heart. However, TypeScript is just so much better, and now we even have language features in modern JavaScript that allow us to provide default values for some of our things. So all of these APIs are going away. That's great. Whoops. Went too far.

We have better useReducer types. So all of this nonsense that you had to do in order to, like, make useReducer play nicely with TypeScript, that's gone, and you can just write a reducer, you can put your types on there. Super great. useRef requires an argument now, and that is, I don't know, good, I guess. So it does allow us to get rid of some types, so there's a mutable ref type, which would allow you to kind of change the value over time if it was ever null, and now that just gets to go away now that React requires that value up front.

I'm not going to spend too much time on all of these, but you get a ref cleanup is required now for type safety, and React element has changed to unknown from any... There's also a slight change to the JSX namespace. You now have to put that inside of React to kind of eliminate any collision with other libraries. And yeah, testing is officially just useTestingLibrary already. Now, one thing that you will know, with all of those APIs going away, all of the test utils going away, ACT, which is a very important method for testing, has moved into the React proper library, so you should be able to get rid of that testutils dependency altogether.

All right, so, now, one thing that I have just historically loved, we're going to shift gears here a little bit, I read this book a long time ago, it was just called Refactoring, I think, I should probably have figured out the actual title of that, but it got me thinking about the ways in which we think about migrating code, and how, for every type of transition that your code might go through, there are these tiny little steps that you can do to take it from one place to the other, they're predictable, they're repeatable, and it can give you a feeling of safety around making changes that you might not have intended to make, or library changes, etc.

So we're going to start today, I'm going to show you a handful of visualizations to introduce you to a handful of new React features, starting with something that I'm extremely excited about, which is useActionState, this is where we actually bring in some of the browser's great form APIs, not great, but familiar form APIs into the React library. So we're going to start with what you see on screen here, it's just this classic click counter, you have some type of useState, onClick you're going to increment, you're going to call that updater function and increment. So useState just becomes useActionState, we're going to take our increment function and we're going to put that inside of our useActionState. That's one of the major moves, is that action goes inside of useActionState when you're making this migration. After that, you're going to call formAction, and formAction is an API that actually gets added to input, button, and submit, maybe? I think there's one other. But all of the form-related elements you can call formAction on. Then you just change this to a form, and everything works as it did before with your button counter, but now you're actually using proper form elements, which is super exciting. We'll start to see why that's cool in just a second.

So by definition, in React 19, an action is some type of asynchronous functionality. So while we're using the useActionState here, because this isn't an async handler, it's not technically an action. So we can make this asynchronous, still the same thing, but now we've decoupled it from being immediate. And now we can do things like await some type of action. So right now, I'm just simulating with time that some network request is going to happen. Something's going to happen that we don't know how long it's going to take. And because it's asynchronous, this is going to be handled for us. Now I'm actually going to open a playground for this, so we can look at that. You can see kind of how this works. So we went from that kind of classic button example that we're familiar with, and through actions, we've been able to make this asynchronous. And if I click this, you'll see a short delay. And then that number increases. Now we hate delays, though. Delays suck. So we have methods of handling that as well. So useOptimistic is a way in which we can maintain the immediacy of what we had with state, but then also in the background, run this asynchronous process. Now with the code that we had above, let's see. So we have our action here. We're going to introduce a new hook. This is React useOptimistic. We're going to take the count that we get from our useActionState.

And we're going to pull off a optimistic count. So this is a value that's going to optimistically be updated in different to how long the request takes. Sorry, let me zoom this out just a little bit. Okay, cool. Then just like useState, we're going to have an updater function that we pull off, and we're going to define this one in line. We have access to both state and then also the optimistic count that gets sent to us via this action, which is, let's see, when we're calling it, right? Oh, I haven't called it yet. And then all we have to do is call inside of our asynchronous function, this update optimistic with our nextCount value, and change our render function to use the optimistic count. Now the cool thing about this is just with these three lines of code, we've been able to track this data, or React automatically tracks this data for us.

So let's open up our playground for this one. And you can see how our experience has improved. So we're going to click this, and the number automatically updates. So number goes up, but then we have this spinner while that asynchronous process goes along. This is such an amazing experience for users to be able to, like, think about a chat client where people are able to post stuff and have that feeling of real time, even though it's actually going to a network, it might take a little bit of time, there may be delays.

So really cool API here around the form actions. We got 57 seconds left. Let's see how much more we can get through. Now I won't necessarily go through all of these then. The actions are not limited to the buttons. I actually prefer to handle these on the form. And the cool thing about when you do these on the form, you have access to the kind of browser style form data. So if we put a hidden field on this, we can actually take form data as the second argument for our actions, and do whatever we want with it. So super cool API that actually bring web forms back into the fold.

And actually, I think 15 seconds, we can do the last one. So there's this new API called use. It's super awesome, and it interacts with context very nicely. So context, now you can kill these providers. So that's pretty cool. You can just cut those out of the way. We can now use use to conditionally render things that would have otherwise used hooks. So like use context and whatnot. This is super cool because use is not a hook. It allows us to bypass some of those hard required rules of hooks that we've grown to hate. So anyway, I think that's it. I think we just hit time. Hopefully some of these help you. Again, all these examples are up on my website. And I'm really excited about kind of what the near term of React allows us to do. Integrating the greatness of web forms and HTML with React.

So that's it. Thanks so much for your time, and hit me up if you have any questions.

So first of all, is there a benefit in defining your action functions outside of your components? Yeah. I mean, I think there's always a benefit to splitting things just because you can reuse them. I tend to not pull them out unless I'm going to reuse them. That's just me, though. The first React app that I ever built, it was before state libraries. It was this massive, I don't know, 15,000 line component with a bunch of... It wasn't even useState then. It was like setState, I think. And it was great. I loved it.

I think that you always run the risk pulling code out. You end up, how do I say this? When you extract code out too early, you tend to make worse decisions because you'll be looking at that code and you're like, oh, hey, this needs a condition here that would allow me to call it in a different way from another place. Versus if it's in line, you change it there. It's like why everyone loves Tailwind right now. You don't have to think about the whole application into your brain to be like this thing right here needs less padding. So I think there's the benefit. But it would be only in those cases where you know that that exact action is shared across a couple of things. So there is a risk to prematurely pull things out.

Some of the worst code I've ever seen was because someone was like I'm going to pull this out because it looks like it should be isolated or repeated. You kind of want to just take a look at everything you have as a whole and then make decisions from there. Yes. Yeah. It's like you're taking that context away a lot of times, too, right? Because you're like pulling that out and maybe putting a different file. And so now someone has to open up like, you know, 50 tabs just to understand what this frigging form does.

What happens if useOptimist fails? Does it revert the state back? Yes, it does.

And so now someone has to open up like, you know, 50 tabs just to understand what this frigging form does.

Ooh, we have more questions coming in. What happens if useOptimist fails? Does it revert the state back? Yes, it does. We didn't cover that. But if there's a little documentation button on some of the examples, I would definitely look at the docs because they have really great examples of how to handle failure cases. You're probably going to get a lot more familiar with error boundaries and kind of utilizing those. These are very simplistic examples to kind of show you how to just load the feature into your brain. But yes, there are included, like batteries included ways to like roll back the state on there. Oh, that sounds very useful. Yeah. Nice.

Can you help me understand what makes use better than what's already possible with use context? It seems like it might invite some anti-patterns. Yeah. So that's something that I'm still kind of like figuring out for myself. However, a lot of times, you know, context is not like, utilizing context is not like a free operation. And sometimes you may know that that component does not need to be rendered, you know, by virtue of some other state. And by rendering the component, and then putting the condition inside of render, you've incurred the cost of like, rendering that component and kind of doing that, like context lookup. Yeah. And so here, you can just like opt out completely like, hey, this computer, this, this component, we know that this component is not shown, like, don't reach for the context at all, like don't do that connection. And so I think that there, like, I don't know, maybe there may be risks, but it is an optimization opportunity to kind of like subvert some of those, you know, rules of hooks, which is nice. Yeah.

What do you think about the name use? I mean, I saw it, just like, use what? Oh, just use? Everything is, yeah, everything is used in React. Now, especially if you're a Next developer, it's like, use cache, use server, use like, whatever. I mean, it's readable, I guess. Yeah. It's fun.

Yeah. So this is, this is an area where I've been at odds. Like as someone who came up in like HTML, CSS, like progressive enhancement, like all that I'm like very old. So like I, I came to love like a lot of the like APIs of the web, you know, like the first thing that I ever built was like a PHP form and like, I, I love that flow of, of forms and using forms, date form data, using forms holistically as like a single object that you're working with.

And I think that forms have been really problematic in react because they've always recommended using a controlled components. Yes. And I hate controlled components in forms. Like it's just the, they suck. And I've always been someone who's like, Hey, just submit a form, take the form data. Right? And that's never been the react way. It's like, you can do that if you're an idiot and you really love the web platform for some reason, but like, that's not how we do things in react. We use things, controlled state, et cetera.

The cool thing about use, uh, use action state is that those things can coexist now. And you have the benefits of, you know, react, knowing about this form and having it being integrated into the framework. And then also you get to use forms the way that they were intended to be used on the web. So it's like folded back into react and, um, you know, racks, you know, intent for control and, um, has finally kind of like met up with, with, with the web. And that's, that's why I am so excited about the API is because like now we don't have to do something that's not the react way anymore. I can just, you know, it's, it's built in. It's great.

I've been railing against the standard for like a very long time. I just, uh, yes. And so I'm excited about it. Nice. Okay.

I've been, yes. I've been railing against the standard for like a very long time. I just, uh, yes. And so I'm excited about it. Nice.

Okay. So how do you summarize the must do things, uh, when someone upgrade to react 19, uh, will things like, what are some of the things you expect to break? Yeah, so the must do things are going to be, um, uh, blah, blah, blah, blah, blah. So all of the, so that, that list of all the, um, kind of API removals, um, that's going to be like a day one problem. Um, and you have that kind of soft version of, uh, rack 19, three, one, I think is the latest version there. That's going to give you those warnings. Um, and there's code mods for all of those things. So it should be like a pretty easy, like migration. Um, I think a lot of those things are very old APIs that, um, people may have never used. Um, and so I think that, um, day one is just going to be like, you know, carving out all those errors, running the code mods, et cetera.

Yeah. I think the harder problem is going to be that community piece of the, these library. There are a lot of libraries that a lot of people have like come to depend on. I think that many of us are going to have to get our hands dirty in some of those libraries, maybe fork them, like, you know, actually own that code for the first time. Um, or, you know, maybe realize that they're not necessary. It's something that we didn't have time to cover was, um, uh, you know, there's, there are new APIs or new functionality that allow you to just like put scripts, you know, metadata and style sheets, like right in the component. And it will do all of the deduplication for you handle the, you know, preloading and, and whatnot. It does all that for you, which actually kind of removes the need for a handful of libraries that may have historically had a legitimate reason to use some of the, you know, the private APIs. So, um, you may find that you don't need some certain libraries anymore.

Oh, okay. Would you be nice? Yeah. Okay. So I feel like this is a turning point for people to reflect on whether things are necessary or not. Yes. Yeah.

Yeah. I would definitely look at your dependencies like critically, um, and not just assume that you have to like continue dragging a library that's not being maintained, uh, along with you. Awesome.

Okay. Uh, some people aren't convinced RSC should be a part of Core React. Seeing that they've jumped the shark and became more than a UI library. Thoughts? I'm always a fan of anyone who uses the jump the shark. Does anyone know where that reference comes from? I have no idea. No? I thought, yeah. Okay. There's a, there's a happy days episode. Oh, okay. Where the Fonz is on a jet ski or like he's jet skiing and he literally jumps over a shark in the water. It's so stupid. And it's, it's like widely regarded as the moment that this show started to suck. And so, so jumping the shark is when you, you know, do, do a stupid stunt and like start to suck. Uh, it could be. Things I learned. Yeah. Yeah.

Um, uh, it could be, I think, like, um, I dunno, I, I intentionally didn't include much about, uh, RSEs and server actions just because, um, they're not really here yet. You know? And so I think that like, what we're, what we see today is kind of a, like a dim light of what they'll actually be like, you know, um, I think we forget that, like they announced this concept of how to do this, like seven years ago. Uh, it, it's like, it's, it's been in the works for a very long time and it's not here yet. Which means that it's like, it is still evolving, you know, um, next obviously has like a solution that kind of like driving the language and like the, you know, the, the thoughts of it and what they think it should look like. But like, Remix has a very different implementation of it. Theoretically, this should, this should work in any framework, you know, you could, you know, have like PHP, um, do like server components for you or server actions, but it's very, it's very integrated. Like it requires, like it's integrated into the framework, integrated into the bundler. Um, and I, I think, you know, I probably do a lion on that sentiment of, I like, uh, I like things that are closer to the web, you know, like, I mean, like we talked about with the forms or whatever. And so like, I'm excited about those things. I don't like, I really like, um, you know, client only applications.

And so it's not, it's not doing a lot for me. Um, I think that they're very cool and I think that there are, uh, applications that make a lot of sense. But like, I mean, when you look at the things that are being built, um, like next is really heavily investing in, it's a lot of like e-commerce stuff and like, I'm not building e-commerce sites. Like most of the stuff that I'm building, like people just want like a, like a nicely optimistic, you know, updated UI, uh, like single page app.

And so I think that if you have that problem, um, it's great that there's like a solution for you and you know, you're going to be on the bleeding edge and it's gonna, you know, hurt and you're gonna a lot of cuts and bruises along the way. But, um, I don't know. It's just not what I'm building right now. Yeah. So you appreciate it, but it's not for your use case.

Yeah. Like, I, I'd like to, I'd like to see it, um, you know, fleshed out a little bit more before I introduce something into my application that I'm going to have to like just keep chasing for the next like, you know, five years while it's like, oh, actually we like this API better. Like, you know, we, we, we got it all wrong before. It's like, I'm just like, I'm not interested in it. Yeah. Yeah. You can just wait. Be on the sideline for a while.

Yeah, just wait. You can wait. It's like, it's not even here yet. And people are like, oh man, it's like, you know, it's so awesome and whatever. And it's like most people can't use it. So that is to say, be, be patient. Yeah. We don't even know if we've jumped the shark yet, I guess is maybe the answer. Yeah. Yeah. All right. So that's all the questions that we have time for. Thank you so much for taking the time to talk about ReaNyteam. Learned so much. I mean, I learned the phrase jump the shark today. If we needed anything that was it. Yeah. Come talk to Michael after if you have any questions.