React use() hook and Async Server Components Proposal

Boss and Scott

Welcome to Syntax.

This is episode number 539.

539 episodes. Wow. We are gonna be talking about React Use. It's a brand new hook from React that is gonna kind of change the way you're writing a lot of your code largely around promises.

We're gonna be talking all about what the heck this thing is and how you might use it and what are our thoughts on it. My name is Scott Dalinski. I'm a developer from Denver, Colorado. And With me, as always, is Wes Bos. Hey, everybody.

I am stoked to talk about this. We this was actually a suggestion, before any of the next JS stuff was

was announced. Yeah. This is a suggestion from a listener said, hey, What do you think about this? It's still a proposal, to be clear, so this might be not it, but it it likely will be. Yeah. And and this stuff had beep you know, When once this, RFC has been floating around, people have been talking about it. There's been a lot of chatter. So we're gonna share some of our our thoughts about you. The chatter around this thing and if we think it's interesting or not. This episode is sponsored by 2 amazing companies, Century and Auth0.

Sentry is the perfect place to see all of your errors and exceptions. Perhaps when you use this new hook and you fall into one of the foot guns that exist with, it. Some React hooks and possibly this one. You might have some bugs and errors in your code, especially when you're just learning something new. Right? So if you want a place to catalog, log, and track all of your errors, perhaps you have a bug that made it all away to the production, You can go ahead and say, this bug actually should be referenced in a GitHub issue. Maybe we should assign it to someone specifically, and maybe we can attach a, it. A release to this that we can fix in a specific release. That way, when we push it live, we know this thing's gonna be out of our lives for good. We can check that button on Sentry that says this thing's been resolved, And we never have to think about it ever again.

So if you want all of that amazing, error tracking features and more, head on over to century.i0.

That's s e n t r y dot I o. Use the coupon code tasty treat, all lowercase and all one word, and you'll get 2 months for free. Thank you so much for Century for sponsoring.

Let's talk about another one of our sponsors, Auth0 or Auth0 as I called them for For a long, long time, they will do all the authentication and permissions for your application.

So I actually ran into using auth o in an 0 in an application the other day where I had signed in. I had created an account, And then I came back to it 3 years later, and I said, I probably use Google to sign in with this. So I clicked on that, and then I ran in. I was in the situation where, I wanted to create a Google account, but I had an existing one, and they needed to be merged and held together. And all All of that was handled by 0, and I thought, wow. Like, the amount of weird edge Casey stuff That off 0 must have to handle for you because, like, you think, oh, yes. Sign in with username and password or Google. But, like, what happens when somebody, does both of those? Or what happens when someone signs in with Google and they change their email address or or they delete it or that they no longer work at a company? And there's all these, like, Really hard edge cases when you are doing authentication in your application, and Auth0 makes that super, super easy. You're going to want to check it out in your next app. Go to a 0.to syntax.

It is awesome. I've used it many times myself. Check it out. Thanks, Auth0, for sponsoring. Awesome. That is actually a really great feature. I didn't know they did that.

That's something that is a giant pain. I was even just like This is we're done the ad read here, but let's talk about all for a second is, I was thinking about whoever does the Microsoft off Must be that must be so complex as I signed in to my Microsoft account to publish my Versus Code theme, And it pulled my avatar from when I used MSN when I was 14.

And, like, see, I have a database that's, like, 20 years old. Oh. And God. I was thinking, like, but I also have a Skype account print, but they are associated with each other. And I have an Xbox account for playing games or something like this and then Azure, and it's All associated with each other and, oh,

that must be tricky. Yeah. That is tricky. I even, like, running a short sys like, I don't Have any third party auth system set up. But even, like, in my short time doing that with, like, a startup, we get so many people being like, hi. Where's my account? I I tried to log in, and it says I don't have an account. And we're like, but you what did you sign in with before? If you signed in before Or with Twitter, you gotta do it the 2nd time. You can't make it a new account. Yeah. And it's like, yeah. Yeah. It's it's tough stuff. Alright. Let's talk about React use.

Yeah.

React use. We have a link to the RFC, which is request for comment. Usually, what our RFC is is where people, they post basically, usually fully formed idea about what a new piece of functionality is and what it should look like, And perhaps maybe talking about how you can try this thing or and the request for comment is really to get the community talking in, Not argue arguing, but, like, really hashing out, the pros and cons or maybe even, like, taking care of some ideas and it. Edge cases that the creators might not have thought about or you know? What about this situation? Or what about this situation? That way, you know, when it. Something does get decided upon being an actual API that gets put in. You know, there's a lot of community involvement in getting this thing to across the finish line. So that's what an RFC is, it. Request for comment, and we've linked to the one. It's called 1st class support for promises and async await.

So if, that That should give you a a couple of hints about what this new usehook is here to do. It's to make asynchronous data calls In your components easier within React, which is something that has been tough in the past. People put them into a useEffect. You gotta call that promise from a useEffect.

You gotta worry about, you know, the dependencies for that use effect, and it's a foot gun for a lot of people. There hasn't always been a Clear way of doing it. And then to make things worse, you get into systems like and I I mean worse but better because you get into a system like Next. Js that has its own way of Data loading for components, and, well, it's it's just fragmenting. You know? So this is kind of like, let's build in a better a way of working with promises inside of React components for essentially client side components as well as maybe

We'll talk about the server side component as well. Yeah. Yeah. So let's let's explain a few things real quick that you need to know. React suspense is a thing in React, which will allow you to suspend sort of pause a component while that component is Doing something like fetching data.

And the idea is that you can suspend that component. You give it a, like, suspend this for 2 seconds. And if If you don't have your data by then, then then throw a loader in there, and and that will show your actual, that will show the loader to the user instead of nothing.

Then you have server components and client components are starting to sort of come on the scene. And the idea client components is the components we've always used, and server components are components that will be rendered on on the server. I don't know if we need to explain what those are. But those are kind of the 3 main pieces that you need to know for this use hook.

And we are saying use hook and it's not Use hook. It's u s e. That's what it's proposed to be at least.

And there are already some examples of using it in, The new Next. Js 13 as well. So what are the basics of this, Scott? The basics. So, basically,

the basics are it. You have essentially your normal component. Right? It's a function. It's a component, and we're used to doing our way of Using a a promise where you'd have a useEffect that then called a promise that lives somewhere else. Right? And that would fetch data from an API or Load from a database or something like that. Yeah. Yeah. Anything that required a promise, and there's always some weirdness with that. You know? For instance, you couldn't do And await directly in the useEffect, so you had to, you know, resolve the promise elsewhere.

So It was always a little bit tricky, and what this thing basically allows you to do is to say const data.

The data is not a keyword here. Const data is equal to the use function, and then inside of that use function is another function that returns a promise. Any function that returns a promise.

There's an exception here regarding defining your function in line. But, basically, if you have a function that returns a promise, You'll just simply say const data equals use and then your function. And then that allows you to essentially resolve that promise into a variable such as data And have that data be available. Now the thing about this is just like normal React hooks, a fun first pass of loading this thing, that data is going to be null. So on 1st pass, that data is null. So you do have to check for nulls in that data. Is this data available yet? Because upon that 1st render that's going to come in dull. So you can't just say data dot name

without checking to make sure that data exists. You probably should. You shouldn't, especially if coming from an API.

What do you think about that? I'm in a different state on that right now, and I'm also assume it's gonna come back fine? No. No. No. No.

So for To get to get a little salty here with the way I'm doing it now is I'm doing all of my data calls on the server side. And, I'm checking to make sure that data is available on the server side or else I'm thrown a 404.

I'm I'm I'm throwing it invalid if they can't access that I'm doing if if that page loading, I know that that data should exist Yeah. And that data does exist. If it doesn't exist, I I'm, handling that correctly on the server. So that way, I'm sending the data to the component as in that data's always going to be there every single time, and it It rules. I gotta say, it rules not having to wrap all of your stuff in an if at this thing. Does this thing really exist? Yeah. We know it exists. That's why we're that's why we're all here. We're here because it exists.

So this is very similar to, Tanner Lindsley's, react query or it's called 10 stack query now because it works with React Solid view, Svelte and Angular coming soon.

Quite honestly, I like his API better, but this is Sort of the kind of the same way as you have something that returns a promise. It doesn't matter how you get it. It could be obviously fetch is probably the most popular one, But it could be anything that returns a promise.

And then from that it will return to loading state and data and any possible errors that happen.

So why why do we want to do this? I think the big one is we don't want to have to make hooks for every single thing. I don't want to have to create a React specific, piece of code for every single simple fetch thing that I do right? Fetch is pretty standardized.

Everybody uses fetch. We're just loading data from a URL.

Why do we need to make a new hook for every single thing that we do? So this is really nice to be able to just wrap a fetch, in this use hook and be able to use it. The use hook only works on client components, because you cannot use hooks on In react server components. However, part of this proposal is the ability to use await Inside of a React server component. And that's really nice because you could literally a React server component runs on the server. And then you could use you could have, like, a database library Like Prisma, where you simply just say const user equals await db. Finduser or whatever the query will be, and it will wait For that thing to resolve before the server component goes ahead, much like we've been doing in PHP for 47 years. Yeah. You know what? It kind of stinks

In a in a little bit, I don't wanna be too down on this because I think this is a great addition to React. But what stinks is that The server component and the client component APIs are so different in that regard, like, that we can just do an async await, it. A way to fetch directly in a server component, but in a client component, we have to use this special hook, and then we can't define our functions in like, it feels like there's a lot of exceptions to how this thing is used. It can only be used in these very specific ways.

And now also, you know, they're saying in the future that one of the things about this hook is that it could Potentially be used conditionally.

So it might be a hook that is the only hook that could be used conditionally.

This hook has special rules, and it can only be on the client side. So me, somebody who is, like, a little bit more skeptical of some of these These things because trust me, I spend a lot of time writing hooks. You know, I feel very comfortable in them. I just know that they're adding a lot of kind of exceptions, to the rules that they've already established in FootBuns,

that I I get concerned about when I see That that's it. You know, I do think it's an improvement not to have to do it the way that we're currently doing it. So there is if you're curious, Go read the proposal. There's a whole section says, why can't client components be async functions? Basically, like, why can't we have both? And there are, I guess, Rules behind around memoization and whatnot. I'll let you go read deeper into that.

One kind of interesting thing I wanted To talk more about is that they are modifying global fetch or they're they're modifying promises, which will basically one of the golden rules of JavaScript is don't modify built ins because many years ago, probably 12 years ago, we had a library called MuTools, and MuTools added dot flat.

And there's a couple other ones. The reason why we have array dot includes but string dot contains And they're not like, why is 1 includes and one's contains? It's because tools took it. And by adding that into the language, it would break Some of the Internet, which sucks.

So in general, they're like, oh, don't modify built in. So React here is adding A couple of things. They're adding a status field to promises pending, fulfilled or rejected, and then they are adding the here. I'll treat it. When a promise is fulfilled, the value field is set to fulfilled value. When a promise is rejected, the reason field is set to the rejected.

So they're kind of extending promises a little bit more to give us some information in there.

And people don't seem to like that because, like, what happens if now what happens if the browser wants to add a reason field or something like that, you know, and then We're kind of pooch now. We had to work around. Some of the web is running on this nonstandard thing. We don't want to break the web. So I I don't know if it's that big of a deal, but we will see. And they also do a bunch of caching as well, which is good because if if a component runs 3 times. You're not going to hit that fetch request 3 times over. It's going to cache that data for however long you set it and all the rules in there. Yeah. Yeah. There's a lot here.

I I did a link to the Smooshgate blog post that explains exactly, You know what happened with Smoosh and Flatten and why it was a big deal, that the prototype was modified. What it was called? I oh, I've never heard of being called Smooshgate before, but, this blog post is called Smooshgate FAQ, what the Smoosh happened, which is very funny. The whole thing is very funny. But it is it's all about MooTools. It's all about the history there and all about proposals and why they can't just use flatten, win, or flat.

Flatten, which flatten is the one they want. Yeah. Yeah. They wanted flatten, and they had to end up using flat. And somebody, I think legitimately proposed Smoosh. Smoosh. Yeah. Which made it pretty far as far as I would have been into it. I'm into Smoosh, honestly.

Yeah. Smoosh is good. Yeah.

I

do you wanna talk about foot guns or Oh, I've I kind of briefly mentioned this. There's an infinite loop possibility here. You know, you gotta love, what goes better together than React Hooks and infinite loops. It. If you define your promise within the use function rather than defining it outside of that function, It, like, takes it as a new function each time they use the use function does, so then it'll infinitely rerender that. So let's say you have a function that calls fetch CS and returns a promise. Right? Well, if you don't define the function elsewhere, like, if you were to it. Find that function within the use function itself, it would cause an infinite loop. So you have to define your function that calls fetch it outside of yeah. Outside of your component, or else you could run into a situation where React is confused about the reference and will

try to essentially rerun that hook infinitely because it's not seeing that as the same promise, essentially. Data. Yeah. The the same thing is with event listeners in vanilla JavaScript If you want to be able to remove an event listener from, like, a button, you have to have that as a function outside. You can't just say like button dot add event listener click and then name the function because you have to be able to reference the function that you want to turn off in JavaScript. So it's often better to stick it in a variable or create a function by name so you can reference it. Totally. All right. I have I added this one little thing is like, why is Svelte API better in this use case? And a lot of the comments were React needs a compiler. So a lot of this stuff is maybe a bit more complex than it needs to be, because React doesn't have a compiler step in it, whereas Svelte does. So Svelte is able to just make stuff up.

And then under the hood, They can transform that at runtime, and that's really nice because then you get some of the really slick APIs that Svelte offers you. So there's There's some rumblings about maybe React will eventually get a compiler, so that you can do some of this nice stuff. But that is kind of why there's always this there's this big API difference between the explicitness of React and the way we have to do things and sort of the magical land of Svelte that we all are starting to look over at.

Just imagine those of you who have never looked at Svelte before and have only been a reactive leopard. Just imagine never having to Think about the word memoization or memo use memo or use callback or any of that garbage. I never have thought about it it for one second, and it's awesome. So, yeah, that that those are some of the wonderful promise Promised Landy type of things you get it. The this fault APIs for these things. But, yeah, the the API that that I'm used to right now, like I said, I'm just doing most of my data loading on the server side in a a server dot CSTS file that passes the data as props directly into my component.

Again, I'm checking the data's validity on the server side and handling it accordingly, Passing that, and I know my component's gonna have it for that server side rendered. It's interesting, and I'm I'm excited to see what React is doing with this. I do wonder A little bit about fragmentation in React land. We now have, just news today at the time of recording this that Remix is now gonna be owned by Just Justin. Shopify.

Yeah. So yeah. I know you're listening to this a couple weeks later, but, you know, we're we're just hearing this now. So it does feel like, man, these APIs are going to, I don't know. Who knows what's gonna happen? We got the Remix version of things, which honestly is very similar to the Svelte way of doing things, the SvelteKit way of doing things. You have the Next. Js We're doing things, and you have the React core way of doing things with server components and suspense if it ever does come out. We will see.

It's it's gonna be a wild ride. Yeah. It's pretty there was a lot of, like, tweets around when Next. Js always announcing all this stuff. You could tell that the Remix folks were sort of just sitting on their hands, been like, just you wait. We have an announcement next week.

Yeah. That's kind of exciting because we have the Shopify Hydrogen folks on, and they talked about their stack, which is their own framework.

So I wonder if if they're hide it probably obviously will be.

The hydrogen will probably move over to, Remix, which is exciting. Yeah. So it's it's all exciting, man. Nonstop excitement in the web dev world. That's what we're here about. We're we'll we'll keep you updated. Alright. Thanks everybody for tuning in. We'll catch you on Wednesday.

Peace. Peace.

Head on over to syntax.fm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player Or drop a review if you like this show.