React 19 is here!

Welcome to Syntax. On this Monday, hasty treat, we're gonna be talking about React nineteen.

React nineteen is, it's here. It's in Node enough to drink in Canada. It's old enough to drink in Canada. We we just zoomed on up to React 19, it seems. And there's a lot of really cool new features, a lot of cool stuff, and we're gonna be breaking down everything that is new and improved within React nineteen.

So just just coming to that, realization here. Either way, with me JS always is Wes Bos.

Hey.

Excited to talk about React nineteen. The beta just dropped. As as of recording, the beta dropped last week. You're probably listening to this a week or two after.

And it's the 1st major React release in almost 2 years.

You've been able to kind of use the beta in Next. Js for about a year now, but now it has fully dropped with all of the different features. So we're gonna do a quick rundown of, a, what's new, why is it useful, what pain does it solve, and I don't know why I said a, but and b, like, how do you how do you upgrade? You know? Like, if you're on React 18 right now, what does the upgrade path look like? Is this gonna be painful, or is it gonna be gonna be an easy one? Yeah. Sick. Cool. And before we get into this, you're gonna wanna make sure that you have some errant acceptant handling tools if you're doing any migration of any kind or even worse, checking out a beta in production. Who knows about if you're doing that or not? You're gonna wanna check out century.ioforward/

syntax.

And if you sign up, you go 2 months for free. It's a great place to track all of your errors and exceptions, to track all of your performance, to even track metrics.

It's a really, really amazing tool, and it's so Deno. We we use just an endless amount of tools in Sanity ourselves. So check it out, Sentry Scott I o.

Alright. React nineteen.

This post came out April 25th kind of out of nowhere. Right? Did did this did this surprise you when this post dropped? Because it definitely I was not expecting this. Yeah. I didn't I didn't hear any rumblings. And, like like, even, like, a, like, a week or two before, it was

they were even changing APIs Yep. For it. But I I think they're getting ready for, the React Conf, and they wanted sort of everything out the door JS well as, like, they need to get this thing out so that library maintainers can sort of make sure everything works with with it. And and some of the new APIs as well is, like, library maintainers can maybe roll out some new APIs now that things are a little bit easier in some regards.

Yeah. Sick. I I'm I'm stoked to hear your thoughts on it. I I read the blog post like everybody else, and some of it I looked at like, alright. Yes. Awesome. And some of it, I I definitely was a little bit maybe a little bit more confused about why we need, some of this stuff. But maybe let's start off with the 1st and foremost actions, which is really you know, at one point, they were called form actions, I believe. Right? Were they?

Not really. It's it's it's kind of a complex thing because, like, we we have actions which Yarn, like, a sync functions that are meant to be used with Node of the hooks called use transition, and that is used for having loading states and whatnot.

And actions themselves are now can be asynchronous, which will set the stage for everything else. We did a whole show on them. There is actions themselves, and then there is the ability to have pending states, optimistic states, and error handling all in 1 Mhmm. With the use action state hook. And then you can Node a bit once that further, there's also server actions.

We'll talk about that in just a second. We're not gonna dive too deep into it because that in itself was a whole hour long show. So if you're interested a little bit more on React actions that can be run client side and or server side, certainly check out that episode.

Yep. And to clarify, what I was referring to was that the hook used to be called use form state.

Oh, yes. Yes. Yes. Sorry. You're right. Use action state, which to me tell tells me that, like, at some point, they're like, wait a second. This isn't always about forms. Right? Exactly. Because

they can be called programmatically. They can be called on the the benefit to a server action is that you can hook it up to a form action attribute. And when you when you hit submit the whole form data object, all the inputs, all their names, all the values are available to you without having to do some weird state thing and and pull all the values out of there. But, yeah, it was a bit weird that it it was used form state when it was not always used on a form that can be called programmatically. So I I'm rewriting my checkout right now, and I was like, oh, I'll I'll use server actions for this. And it's so good because you can simply just import the server side function to do the server side processing, the Stripe intent API, and the finalizing the payment, the calculating of the amount, applying coupon codes, all of that stuff validation happens server Node, but then, like, the function call is just inside of, like, an on click handler or on submit handler, and you can call it programmatically and pass any data you want.

It's it's so nice to be able to do that. There's no there's no API endpoints. There's no route handlers.

It's just a functioning import, and, and it runs.

Yeah. I like that. And and and speaking of, this is not super duper related, but, you know, sometimes you you go on tangents here. I've been working in some client side only components lately using pocket base.

And, man, there is something so nice about not having the hot potato data from the client to the server. And I know that it some of this is happening behind the scenes, and it's not the same thing. But there is something so nice about just being in your component, being able to execute the thing you wanna execute right then and there regardless of where it actually goes behind the scenes.

Exactly.

Another huge one, which this was at the very end of the blog post. And when I was making the notes for the show, I was like, where's the code? Show me an example. How does it look? What? Show me the where's the cheese? And there's no code out there. I've Vercel stumbled upon, like, 80 blog posts being, like, React now supports Wes components, but nobody showed it actually working. So I went ahead and I made it work, and I figured out how it works. And this is awesome. So Scott and I, big proponent of web components because it allows you to create components that you can be reused between run times. So the downside to making a React component is it can only be used in React.

Right? And a web component can be used in all of the frameworks. And this is really, really popular for people who have design systems or Wes talked to the folks from Wes Awesome, Shoelace.

You wanna be able to build a very flexible component and have it work in anywhere. And it works server side now in React. It works client side in React. It I don't I I did a whole bunch of examples with it, and it I I hooked up a on click handler to some of them. I passed state into React Scott into a web component. You can pass function calls like a like a set state function into the web component. So it's pretty exciting to to see this finally hit React.

Yeah. And you know what too? Here's a here's my conspiracy theory about this. Not that I not that we need conspiracy thinking on this this podcast, but here's my conspiracy. They don't want you to use web components. They want you to use React components. And then the moment you start getting hooked on those dangerous web components, you're not gonna be able to to stop.

So they don't want you to see the code. They don't want you to use them.

It does make me now like, I wrote a web component, and I was like, oh, yeah.

This is kinda awkward. I know it's kinda weird. That's for sure. Yeah. Now I wanna, like, start getting into lit a little bit more. Yeah. That provides some of those niceties on top of it.

Yep. You can author web components with Svelte too. That's pretty cool.

That's that's good, actually. So there's this website, custom elements everywhere, which is a test suite of what framework support web components, and they give it, like, a score. Mhmm.

And React is now a 100%.

Nice.

Which is the very last framework out of let me rattle through them. Solid? Surplus?

What is surplus? Deno.

I don't know. Hybrid.

Hybrid HTML. Stencil. I heard of that one. Omi.

Omi is Oscar. That's what we call that's what I call my like, our grandma in our house, Omi.

Mithril, Riot JS, Lit, Hyperapp, Svelte is in here. Preact.

So that's to say, oh, Svelte, only getting 14 out of 16 advanced pass pass. So Svelte has very poor support, whereas React has a 100% support.

This is the the advanced Wes of the basic test. There's 16 out of 16, and the score is 94% of that. So that's What is it failing on?

Attributes and properties will pass object data to a camel case Node property. Oh, so it it fails it. Oh, I did see, though, that if you wanna have, like, an on click, it's not camel case properly. There's some oddities to pop up there. I don't that's not a big deal. Next Node, the use API. This one is is pretty cool. So React roll out this new API. It's just a function called use. And right now, it does 2 different things. And I think the idea with the use API in React is that it will sort of open up the gates for, a, custom libraries putting out their own things that can simply just be used.

And, b, I think maybe some of these hooks effects Scott. Maybe some of these hooks will be moved over to the use API. I don't know if that's actually the case. Don't quote me on that. But I imagine that now that they have this API in React, they're gonna say, alright. What else can we make into use? So the use API will do fur first with promises. The way that it works is that you can pass a promise into the use, and it will suspend that component from rendering. And in React, we have this thing called React suspense, and a component can be suspended, sort of paused from rendering while something is is fetching data or while something is happening. And you can wrap it in a suspense component, and you can show some, like, loading state.

It simply just knows that a component inside of me has something that is loading. And that's kind of nice because you can put multiple components inside of a suspense boundary, and it'll wait until all of its children have been unsuspended or have been fulfilled. So with the use API, it will take a promise, and it let's say you wanna fetch some podcasts. I did this. I hit the syntax API. So I said use fetch syntax.fm forward slash API forward slash latest. It grabbed the latest episode and then throws it into a variable for me so I can go ahead and display it on. There's no loading states. There's no weird like, if there is a podcast, you know, there's no initial state of, like, an empty array of podcasts. You simply just use it. Downside to that is it does not currently do caching, meaning that unless you're using a framework that is suspense ready, it's kinda useless because it will re fetch every single time it rerenders, which is kind of sucks. We'll probably have to wait until Mr. 10 Stack or something rolls out something that is in there. I kinda look at this and go, well, why can't we just await a promise inside of a component? You know? There's so many things I look at this, and I say,

this is great, but it it's solving problems that ultimately React created for itself. And Yeah. That's, like, my big concern with it is is, like, are these problems that are real problems or these problems that that we invented and and, like, why is it so complex to do things that should be as simple as just a way to function or something. You know? Because because on the server,

we have asynchronous components already. Meaning, you can mark your component as a sync. You can await before the render, and it will just work like every other thing in JavaScript.

And the we will get a sync components in the client. I asked on Twitter the other day, one of the React devs, and he said they're waiting on the, like, sync local storage API to hit, and then that will allow it to work. I I think it's because if if you want suspense to work, it has to have some way to know if it's currently fetching data. And a lot of this also boils down to React doesn't have a compiler, meaning that you can't, like, know ahead of time with these types of things. So hopefully that this this use API is is really cool. I like it, but I also would just like await.

Yeah. It it feels hard for me because at one point, it does feel like, hey. This is useful. This is great. In another point, it's like, this is adding more confusion and more complexity even though I get that it solves these following problems and is probably a bit cleaner than what we were doing before. I I just wonder if, like I don't know. There's a lot of new APIs, and and that's Scott, like, a huge problem. I like a lot of new APIs, but it does feel like it's all getting a bit muddier to me. Yeah. I don't know. I I don't know if it's necessarily muddier. Like, it's it's better

than what we had, but it's not as good as 10 stack query, you Node? And maybe I always like when you can just use these things straight up without having to install a install a dependency.

But then sometimes they're just like, well, it's it's a primitive. You know? It's primitive for for library authors. But the other use case for the use function is with react context. So couple updates to react context, which is now the new new new context.

The 3rd iteration of it's it's not a different context. Still works the same as JS you'd expect in the last couple of years. But now you no longer need to create a provider.

Thank you. Previously, when you create context, you have context itself and then you have a provider and you wrap the provider around your application.

Now your context is your context, meaning that in order to consume it, that was the word I was looking for. You have a a provider and a consumer.

Now the context is both a provider wrapping your application in it, and it is a consumer by simply passing that value to use, and you can access the context from within your your components.

That and it never made sense to me, the provider consumer thing. It always felt like too much. Even this new way of still needing a provider that is just your context now still feels like I don't get why we don't just pull, like, was it recoil or even Zoos stand Wes they pull the state outside of the component tree? I still don't understand why you don't. Yeah. That way.

Like, why can't we just import it from a file? Like, would that be nice? Yeah. You where your state has its own tree. Yeah. Yeah. I would like that as well. That's actually what I have here is I posted this on a real or a TikTok or whatever, and a lot of people have said, oh, does this get around the issue with context Wes if you have data in a context, everything that is below that will will rerender Yeah. Because the data has changed and it it sends it down. And and the answer to that is no. You still have to use use memo, but React is working on this thing, a compiler, which is we're so glad to to finally see this, that they're working on a compiler called React forget because the reason Svelte and a lot of these other frameworks are so awesome is because you shouldn't have to think about rerenders. You shouldn't have to think about, well, don't put your your context too high because then you'll cause too many rerenders a lower. And Svelte, you just import your state where you want it, and and you put your variables in the divs where you want them. And the Svelte compiler step will figure out where the data needs to go. And it will when the data changes,

it already knows ahead of time where where to update them, where to put the variables. Right? Yeah. And and React is a little bit funkier. So go ahead. I still understand why we need a compiler for that when Zusdan does it and Recoil does it. You know what I mean? So, like, to me, that that feels like something that they could have solved a different way.

Oh, yeah. I don't I don't know how how Zestan works. Yeah. Yeah.

Yeah. Wes don't need to get in Deno into that. I I just wish React Context would would work more that way just given that that I I feel like personally, it resonates with me a little bit more. I'd you know, like the whole having to wrap and worrying about the rerenders biz. But yeah. Oh, yeah. I get Wes. How does how does zoos stand work? You you create a store,

and then You use it as a hook. You use it as a hook. Okay.

Yep. It's a lot more like the Svelte stores, especially the newer ones where Okay. You're creating a complex store. And you want that store

in different components, you just import it in. Yep.

Yeah. Okay. Yeah. So that's that's what I want.

That's what I want. That's cool. Do you see? Actually, we're going to have him on the show. David Key Piano Works is building, like, a Zusdan like

state machine Yeah. State management library. He called out my usage of a status, variable as being a positive the other day on Twitter, and I wanna say thank you, David, because I I really look up to you in terms of, not using Boolean props and status.

Yeah. There you go. State machine light.

Next Node. This one is is very simple. No more forward ref. In React, you use a ref to reference the dom element. So often you need to reference the dom element to get some of its native properties or methods off of it. So you have a video element you want to get current time. Right? Or you have a dialog where you need to call, like, the open method on it. Previously with React, you have to you well, you create a ref for it, and then you can access the dom Node, and you can say ref.current., and then you get the the DOM values off of it.

And if you wanted to create a ref but still make, like, a custom component, like, make a custom video player component or custom data input component, then you have to use this, like, bizarre forward ref API.

And now you can simply just pass the ref in via a prop like you kind of expect it would be. So no more forward ref. Very happy about that. Yeah. That's great. In fact, I use the, the forward ref as a smokescreen for one of the stumping code examples I did to Wes during the React Live because I knew that the the forward ref API is such a pain to look at. I was like, he's never gonna see that I didn't spell class name class name.

Oh, man. Especially Wes people use, like, the arrow function inside of an arrow function, you know, like, they'll use, like, the implicit return. Yeah. Like, it's real Sanity. Component name equals, and then they do, like, the arrow function. But then you put that inside of a forward ref, and it's like And then you toss TypeScript on that bad boy? Oh, yeah. Oh, yeah. Yeah. Default props and TypeScript holy hell. Yeah. Good luck reading that. Yeah.

There's also a ref cleanup callback now, which is kind of cool. So if you need to do something when a component is unmounted, Like, for example, you wanna remove an event listener. You might want to take something out of an intersection observer.

Previously, we've just used a useEffect for that because a use effect has a cleanup function where you can sort of clean up. Right? Now refs have a cleanup. You can from the ref, you can return a function that will be called when the component is unmounted.

It's again, just nice nice clean way to to handle that.

Yeah. The the fact that you can put now document metadata anywhere and have it be you don't have to use what React Helmet is what everybody was using before. Yeah. That's what you always use. Yeah. That's a feature that I I really enjoyed in Svelte. Any component, you can put, you know, metadata in. And I really do think that's a good way of doing it, having it override.

So yeah. Now you can put your metadata, the title link, meta tags anywhere. They're gonna be hoisted up to the top. Style sheets and script tags inside components.

That that is a a a big big win for me. These are things that I really like doing in Svelte, so I'm happy to see them, in React world.

As someone who makes a lot of demos, I was very happy to finally be able to just put a fav Scott in my component and have it hoisted right up. You could put a you could change the title tag from inside of that.

Like, people are asking, like, why would you ever want to do that? The reason you want to put title link and meta tags in your components is because that's where your data is. Yeah. And it often, your data is at a component level that is not the head of your document, and you need to be able to hoist it up from that. And and now React does it both server side rendering and on client side. But the style sheets Node That's wild. Yeah. Freaking love that Yeah. Because you could just pop a style tag. You can use scope styles in in CSS if you want. There's so, like, it doesn't do any processing of your CSS or you'll probably still want some something that that does a lot of your processing and deduping and and whatnot. But you can just pop a style tag inside of a component and it will then render the CSS out for you. It will also it will dedupe them. So if there's the same if you have, like, a link to a a CSS file a 1000000 times, it's not gonna link it up a 1000000 times. That'd be cool. That and then yeah. Puts better than a 1000000 CSS links.

Totally. And script tags. Like, I don't know if I've done that Node before.

I'll tell you when it's good. Here. I'll tell you when it's good. Web components. Let's say you have a web component that needs to load a specific script instead of having that script load for your entire app. You could have that script just load for the component. In fact, when I was in Reactland, I this is way even back, when I used decorators Reactland. I used to have a decorator that loaded scripts before you loaded a component, and then yeah. Oh, you know what?

I do need this. Yeah. Millennia. It's good. So Stripe has like, Stripe's SDK has to be hosted on Stripe. Right? And in order to get that into your page, you either put a script tag in your document or you use, like, the load they have, like, this load Stripe method, and it will inject it in. So, yeah, sometimes you need to load a script tag.

I want I wonder how you know if the script tag has been loaded. There are also a whole bunch of methods in React DOM for adding preload attributes as well, which could be interesting if you need to you have a component. You wanna you wanna add preload attributes to the head of your document for CSS, for fonts, for images, and say, hey.

I don't I'm not using these yet, but either go get these for me now or, like, just do, like, the network overhead so that when I do request it, it is nice and fast for sure. And then the last thing here is just like upgrading in general. So like what what JS the React 19 upgrade look like? I personally looking at all of the breaking changes, they are almost all changes from that they, like, broke in, like, 2018. So they've they've Yarn not broke, but they deprecated in 2018 string refs, prop types, and default props for function components.

So not classes.

Function components are are being removed.

Honestly, not that I, like, went through the list, and I was like, this is not gonna be a big deal. You can upgrade to React 18.3, which they just released as well, and that will just give you any warnings. So just just upgrade to that. It's not gonna break your app, and then you'll get a bunch of warp. Say, hey. In the next version of React, this is going to this is gonna be updating. This is gonna be breaking, and I don't I don't think unless you have, like, a very, very old code base, which you might, but you've probably been seeing warnings for for quite a while about things like prop types and string graphs.

Yeah. Right. Yeah. A lot of the stuff they they tend to put out to pasture long before you have to remove it from your your code base. Alright. So that's React 19. Pretty excited about it. I have no idea when it will be released as, like, stable, but I imagine

in maybe a month or 2, we'll we'll see it. But again, the reason of a beta is so that people can try it. And there may be some big thing Wes some people say, oh, you know Node? You're optimistic. Doesn't make any sense. Like, we're already starting to see that people are saying, ah, this API doesn't make any sense and good. Like, it's it's been there for a while, but no one was really using it,

until recently. So people are starting to use it, integrate it, and we'll see if any issues pop up. Sick. Well, that was really, really interesting. I think the the blog post I mean, I do feel positive about the future of React and where it's going, and I'm glad to see that, you know, it's not stagnating or anything. So, yeah, interesting stuff from the React world, and I I can't wait to see. It it does feel like we're still in a bit of limbo here with some things, and it'll be interesting to see where it all shakes out. Alright. Catch you later. Peace.