There are two reasons there. First of all, the <a href="/tags/backend">backend</a> team I'm working with is mostly, what's it, C-sharp developers. C-sharp developers, so they're using the.NET stack, and most of our <a href="/tags/backend">backend</a> is in.NET or Python, not in Node, and they don't really want to use the same <a href="/tags/backend">backend</a>. And they also want to be able to kind of release independently of the <a href="/tags/frontend">frontend</a> releasing. So I'm only using a relatively small set of the <a href="/tags/nextjs">Next.js</a> <a href="/tags/backend">backend</a> functionality. Yeah, so when I'm using <a href="/tags/nextjs">Next.js</a>, it's mainly for like personal projects, but obviously in our company we have say 20 developers. So we're using like Express for our <a href="/tags/backend">backend</a> in a separate repository. And I was just wondering like any use cases of people using it in a bigger company? Well I still use <a href="/tags/nextjs">Next.js</a> then. For the <a href="/tags/frontend">frontend</a>, yeah, yeah, yeah. For the <a href="/tags/frontend">frontend</a>, yeah, but also some <a href="/tags/backend">backend</a> related. Like for <a href="/tags/authentication">authentication</a> I'm using NextAuth, so that uses the Next <a href="/tags/backend">backend</a>, but not in a more general application sense. So we log in using NextAuth, we send an OAuth token to the <a href="/tags/backend">backend</a>, and the <a href="/tags/backend">backend</a> uses its own library, but the actual provider is <a href="/tags/azure">Azure</a> AD, so we both use the same <a href="/tags/backend">backend</a>. Okay, that's interesting. And we use the image <a href="/tags/optimization">optimization</a> things from Next and some more, but the actual business functionality is not in the Next <a href="/tags/backend">backend</a>. Yeah, I think that's the approach that we're looking at taking for our company, migrate our <a href="/tags/frontend">frontend</a> to use <a href="/tags/nextjs">Next.js</a>. Yeah. But just the <a href="/tags/frontend">frontend</a>.I already mentioned and already demoed that <a href="/tags/react-components">React</a> server component uses streaming, so I actually have a screenshot right here of what that looked like. The reason I've got a screenshot here is that usually if I try to look at the response in Chrome, Chrome won't actually show the streaming response. Right now, it did, so this isn't very useful. Let me go back one step, because there was one thing I slightly skipped over. When you get to <a href="/tags/react-components">React</a> server actions, it will contain the same kind of stream back to the clients. And in that case, you can actually use a couple of Next-specific APIs, revalidate path and revalidate tag, to invalidate certain amounts of <a href="/tags/data">data</a> or routes. These can be streamed back in the server action response and be used in the client to update things. So you might update a movie using server action. And as part of updating it, the response would actually rerender part of the <a href="/tags/user-interfaces">UI</a>, which is very convenient. So what's another thing I would want to use as a <a href="/tags/react-server-components">React server components</a>? The site layout. If I look at the site layout now, first let's look, which is basically the top to navigation bar. There isn't actually much more to it, but you typically have footers in there, kind of how this layout. So this bar is kind of client-side functionality, but this list of genres in here is kind of something I would want to get out of the <a href="/tags/database">database</a>. And right now, if I look at this, main nav somewhere in here, I've got a genre selector right there. This again, uses useEffect, fetch to get the APIs, et cetera, in a very traditional way. So I kind of want to move this to the client, but I can't simply because there is a lot of other states there as well. There is a state here for whether the dropdown is open. Somewhere in here, there is a button which triggers the fact that the movies are open. It's this popover trigger, which is one of those ShadCN components. So there is quite a bit of this, which needs to run on the client, but there is also stuff like this, which I really would want to do on the server. And right now, this doesn't have a useClientDirective because its parent components, the, where was it? Layout. This has the useClientDirective. So if I would delete that and see what happens, I would see, first of all, the genre selector complain. So let's make this a client component. But even after I done that, I would still get others, like the shopping carts. Doesn't work. So this is in the main nav, and I just had that open. Where is it? There, main nav. This uses the shopping cart, but it also uses the path name search parameters. So this is also typically something which needs to run on the client, can't on the server. So I need to put a useClient there. And now it should run fine again. But that doesn't really help me with the problem if I wanna turn this into a server component or maybe because it can't be a complete server component, I would like to split it into a client and a server component. So we need to do a bit more. And for that, I'm gonna skip ahead a bit. This, we're gonna run out of time. And it's kind of useful to see. I'm gonna go and use this page for a moment. Marvin, could you please mute your mic? Thank you. So here I've got some components, a server client page, a parent component and a child component. And I'm gonna use those to demonstrate what the effect of useClient and how things render and how things are composed are. Because right now there is no useClient or any server specific thing in here in any of the locations. So if I go back, let me close all other. Close all, we'll go to that page. Where is it? Wait. There it is, server client. So we've got the page here, which says server client page. We've got parents, which says parent components and we've got child components, which just says child component. But there is nothing about any useClient there. They also all have this console.log message where they actually render. Now, if I go back here and open the <a href="/tags/cli">console</a> window, we can see there are no messages here. So let me refresh this page.

So let me refresh this page. Nothing here, no messages whatsoever. And if I search for, let's say, we'll take the child component. Rendering child component. I searched for that, no matches found. So none of this <a href="/tags/code">code</a> exists in the browser.If I switch to the dev server, instead we can see those messages right here. We can see here rendering the server client page, rendering the parent component, rendering the child components. Now what happens if I take the middle one, the parent component, and I add a useClient in here? So I'm kind of saying this parent component should be a client component, but that's the only one I'm gonna change. I'm gonna save that. We still see rendering server or client page, rendering parent and rendering child here. So they all still render on the server. But if I go back to the browser now, right here we also see rendering parent and rendering child. And in fact, we see it twice because <a href="/tags/react-components">React</a> in development mode, in strict mode, will render all the components twice. And if I do this search again, now we do find that this component is available on the client. But I didn't make a change to the child components. I did not put useClient there. So just to show that again, child component completely unchanged. So why did it move to the client, to the browser, and why do we still get those rendering messages here?Well, let's start with the last question. Why do we get these here? That's purely because server-side rendering and next. Next renders everything server-side, whether it's a client component or a server component, and sends that to the browser. So that's why they still render here. But without server-side rendering, I would not have seen parent component, child component here. I would only have seen server or client page here. Now, why do I see both parent and child component here in the browser, well, where I only marked parent components as with useClient? It's kind of called a client-side directive. This makes this a client component. But in reality, it's a little more than that. It makes this a client component, but it starts a client boundary. So this is a client component, but any component rendered from this component is also going to be treated as a client component. So if I remove this for a moment, and I go into child components, and let's make this an async component, and actually do something that I couldn't do on the client. Oh, wait. Prisma.findfirst or something. And we'll render that. We'll render that name. It helps if my syntax is correct. If I go to the browser now, we see it renders adventure here, which is the first genre it happens to find. Now this works because I disabled this useClient in parent components, but I can still render it. In parent component, which makes everything a server component again. But now I'll introduce this again. We go back to the browser. I refresh and it actually works, which surprises me a bit. Why does this work? It shouldn't. That's more like what... Well, it's still not exactly the error I was expecting, but at least I do get an error now. I wasn't expecting an appendChild. I was expecting this. Why is my mouse responding? Because I moved it off the mouse mat. So I get an error here saying that <a href="/tags/prisma">Prisma</a> Client is unable to run in this browser environment. It's something which can only run on the server. So this clearly doesn't work. I've got a client component here and because child component is rendered from a client component, it is treated as a client component, even though it has logic in here, which belongs to a server component. So how can we get this to work? Well, let's grab this one, remove it here for a moment, and let's go to the page, which is also still a parent component. Move this in here, resolve that import, and go back to the browser. So here it renders perfectly fine, except the nesting is no longer what we want it to be. Except the nesting is no longer what we had before, because now the child component isn't nested inside of the parent component, it's below. But remember when I explained that we had two phases, we had the render phase, which is what's happening right here, and we have the composition phase where we determine what is a child of what and how things actually get inserted into the DOM. Now, what I can do is I can say, I want to render it here, but pass this into the parent component as a child. Now I get a compile error here, we'll fix that in a minute. Right now, the child component disappears, but there are no errors other than that compile error. And that compile error is because my parent component doesn't know about children. So let's go and add a prop here. Props with children. So that's a standard <a href="/tags/react-components">React</a> type, which defines what children look like. I'll grab the children and render whatever the children are below the header with the parent component. Compile error here is gone because now parent component allows for children. And if I go back to the browser now, we can see that the server client page renders, parent component renders, child components renders, and is able to load a genre. And in the messages, we can see that just the parent component is being rendered in the browser, the client component is no longer. It's rendered on the server and the resulting virtual DOM is injected into the client component and composed as a child of that client component. But this renders on the server and the composition happens on the client. Well, that's pretty neat.

And that's a nice way how you can compose things together. And that's what we can do with that navigation element. I want the <a href="/tags/data">data</a> for this drop down to be direct query, no longer fetching, etc. Make that simpler. Well, let's go and do that.So we have the genre selector. I want to get rid of this genre state and this useEffect where we do the fetch. But that means we need to pass it in or get it somehow. So we'll do that with props. So this component is happy, but this is rendered from the main nav. So this needs to know about the genres somehow. So something like that, except this can't load them. Sorry, this can't load them directly because this is also a client component. So let's grab the same prop definition and put that in here. So this shows it's actually available. And let's resolve this. So that compiles. Except it still needs to be passed into here. So that's in the site header. But this is something we turned into a server component because we removed the useClient here. So here I can pass in the genres. And now in here, I can do a couple of different things, but I'm just going to do the simple thing now. I'm gonna say, const genres is 08 <a href="/tags/prisma">Prisma</a> genre.select, what is it? FindMany. And this needs to be an async function now, which it can because it's a server function. And now we load these genres via a direct <a href="/tags/database">database</a> query and I didn't order them, but now adding an order by clause here would be pretty simple. Now this works.The only downside is that this site header is an asynchronous function. And if this takes for a long time, then the whole site header is gonna show some fallback <a href="/tags/user-interfaces">UI</a> if you suspend. So this whole top goes away and I kind of want to render everything except this load by movies. So a slightly better way is to create another component, a loader component, genre loader. In here, we'll do that query and this is going to be the async one. This no longer needs to be async. We're not doing a query in there. In here we're gonna return to Genre Selector, passing in those genres. And now instead of passing the <a href="/tags/data">data</a> here, I'm just gonna pass in another component. Just like I was using children, in this case I'm doing it with the specific name, but the effect is the same. The typing is slightly different though, so genres is no longer a list of <a href="/tags/data">data</a>, it's a <a href="/tags/react-components">React</a> node. And in here I just want to display that list of genres. So that all still works, except we're not using suspense yet and let me make that clear by making this slow. Let's put a sleep in here and have to make it really slow, five seconds. So now if I refresh and it's actually gonna be better to open this in a new page. We see we don't see anything, nothing, nothing until that five seconds has passed and then the whole page renders because everything suspends. But now I can actually start using suspense and say, well, I just want this part to suspend by itself. Fallback is loading or something like that. Why is autocomplete not working? Why is autocomplete not working? Because this needs to be closed off. So now if I refresh, you see loading first there and then after five seconds passed just this one component resolves and everything's good. And the <a href="/tags/user-interfaces">UI</a> is not very pretty, but we can actually make that a lot nicer if we grab this button. So take the button which is normally rendered and we'll use that as the fallback <a href="/tags/user-interfaces">UI</a>. Instead of most of the stuff, I'm just gonna render the default and let's get rid of all of this, don't need that. What did I do wrong? Why doesn't, it doesn't like something, but I'm not quite sure why. Oh, because open is undefined. So now it renders and the only thing we wanna do is say, this is disabled as long as it's the fallback. So now in the browser, if I press F5, we see this dropdown within a disabled button state and after five seconds, it's easiest to see by the Chevron which appear. Like if I refresh, there are no Chevrons, it's no dropdown, doesn't do anything until after some time it resolves. So we have a <a href="/tags/react-components">React</a> server component streaming in with <a href="/tags/data">data</a> after five seconds, updating the <a href="/tags/user-interfaces">UI</a>, rendering a <a href="/tags/react-components">React</a> client component, which I think is pretty sweet.Question from Radek, go ahead. Yeah, thanks for this use case. I'm just trying to sort it in my head. So if I compare it with, let's say, traditional lazy loading stuff from the browser and let's say, focus on the <a href="/tags/user-experience">user experience</a> point of view. So in this case, there's no like API call. Everything happens in the server internally. And then once the genres are ready, they're streamed back to the browser. But from the <a href="/tags/user-experience">user experience</a> point of view, there's no difference. User still needs to like await for completeness of the request. Yes, that's correct. So you can show something like a skeleton or loading state, whatever. So from the user point of view, there's no difference, right? So it's just different like way of how to deliver the piece of functionality to browser. Yes, that's correct. Okay, got it, got it. Thanks.

The reason I prefer this way is because, again, I've got rid of the fetch request here. So I'm getting the genres more direct and no serialization, deserialization. I've got better caching, et cetera. Yeah, so, and it actually, well, you actually hide the API calls. So you no longer expose your API calls to browser, right? Yeah. Well, there is still an API call going to the <a href="/tags/database">database</a>, of course, but there is no RESTful API call. There is no way someone from a browser could request this same thing. Yeah, yeah, yeah. I still have this genres requests right here, right, that's not the API, in here, but I could delete this, like it's not used anymore. I can delete this and everything would work perfectly fine. And there was no way from the browser they could actually get to that <a href="/tags/data">data</a> or potentially if there was an update there, do a post, et cetera. Yeah, that's what I meant. Yeah, thanks.Okay, so I actually combined a couple of the different demos here. So that was the navigation, the first part, then I did that. One thing I didn't show is this package server only, which is really useful. If you've got the server component and you accidentally use it from the client, then you will get, or at least you probably will get an error in the clients that you're executing something which you can't do. But there are cases where you might not see that error. And even then it's better to get an error like that at build time, compile time instead of at runtime. So there is a package called server only and you can add that to any components which should only be available on the server. Now, this is not one of those but let me add it here to show you what happens. So if I add server only here, I immediately see an error here. First of all, this is marked, reduce client. So it doesn't like that. And in here, I also get your importing component which needs server only, and you can't do that. Now, the neat thing is I could add this to components which should be server only, like for instance, I had a child component here where I'm doing a fetch. So I could add that here. But because this is just an import, I can actually go a step further and go to say here in the <a href="/tags/prisma">Prisma</a> file, say, well, any <a href="/tags/code">code</a> which imports this file is only capable of executing on the server because this is around the <a href="/tags/prisma">Prisma</a> client server-side functionality. So this will just throw an error. So this is fine now, no problem. But if I would do this in client component, let me put a use client in here. Now, immediately I'll get this error because I'm importing <a href="/tags/prisma">Prisma</a>, using it. And <a href="/tags/prisma">Prisma</a>'s indicated as only being server capable. Indicated as only being server capable. Fix error. So it's a pretty useful package to add as a marker to <a href="/tags/code">code</a> which can't execute on the client and you'll get compiled time, build time error before you get a run time error that something doesn't work. And I've actually seen cases with <a href="/tags/react-server-components">React Server components</a> which were async, which accidentally got rendered on the client where there wasn't an error because something couldn't run like this. But it was still async and client components should at the moment never be asynchronous. There are plans to make client components asynchronous as well, but right now that's not a supported scenario. So with this import, you can prevent that from happening.So, there we just saw the composition I demoed where we could pass a server component in as a child of a client component. It's just a matter of where we run the RITS. This demo, where we rendered a child components inside the parent page and passing into a child browser parent components which is pretty neat. So we did that. And then the important bit, why we actually wanted to do it loading the genres on the server. So I suggest, I'm gonna just gonna skip over the <a href="/tags/code">code</a>. You just saw me do this in the slide. So I just suggest you go and do this. It's the last exercise we're actually gonna do. After that, I'm briefly gonna show server actions because we're running out of time, but that's okay. No problem. Because you've still got all the exercises and you can watch the course where I show all of this and go into more depth about it anyway, if you want to. So let me quickly demo how server actions will come into play because I think there are somewhat less highlighted but also very neat capability we get which is part of the <a href="/tags/react-server-components">React server components</a> spec. So this is not <a href="/tags/nextjs">Next.js</a> specific, which some people think. I originally thought that as well, but this will become available in other <a href="/tags/react-components">React</a> stacks when they support <a href="/tags/react-server-components">React server components</a> as well. But the thing traditionally, if you do say <a href="/tags/data">data</a> entry <a href="/tags/forms">forms</a> on the client, you need to write <a href="/tags/code">code</a> there. You typically handle the onSubmitEventHandler on the form and do things there. That also means that you always have to have <a href="/tags/javascript">JavaScript</a> enabled on the client. Otherwise it wouldn't just work. But with <a href="/tags/react-components">React</a> server actions, we can do that a lot simpler and a lot of the magic goes away. Instead of writing an onSubmitHandler, doing preventDefaults, gathering up the <a href="/tags/data">data</a>, doing some kind of post request to the <a href="/tags/backend">backend</a>, getting the <a href="/tags/data">data</a> there from the request and doing something, we can do all of that much more directly. Where I'm going to do that is with genres. I've got the list of genres here. Assuming this still loads. There it is. We've got an edit form. There is only name there. So not really much to edit. And right now I can click save changes but nothing actually happens. Well, almost nothing.

In fact, if I change this a bit, say action one, I click save changes. We do see there is a message here in the <a href="/tags/cli">console</a> saying that the name is become action one. Let me close all of these and let's go to the genres page. This one. We can see that this is a server page. It imports server only to make that really clear. It fetches the specific genre we're interested in and then render show form. And genre form, we can see is use client components. It has an on submit handler here, which is kind of the default thing except it does actually submit to a <a href="/tags/backend">backend</a>. It just prints a <a href="/tags/cli">console</a> message and is hooked up to that form on submit.

Now, we can't really get rid of use client here because if we do, we'll get an error. We can already see the error here. That's that on submit can't be a function because now this is rendered as a server component because it's rendered from another server components. But I can turn this into action. Now it turns out that the parameters are going to be slightly different. So let's get rid of this type and the parameters are no longer an event but it will get form <a href="/tags/data">data</a>, which is of type form <a href="/tags/data">data</a>. So we can get rid of these two. Compile error goes away, but we still see in the <a href="/tags/cli">console</a> that there is an error here that can't be marked, that the function can't be passed in directly. It has to be marked with use server. So use server only works on server actions, not on server components. But I can specify this function as a use server. So I'm not putting it at the top of the file, which is also possible in other cases. But in this case, I'm specifying this specific function should be executed on the server. I'll save this again. And I should see another error, which is right here, which says server actions should be async functions. So let's make this async. And now error should go away and it should be happy. So we'll call this action two again. I'll click save changes and no more messages here in the <a href="/tags/cli">console</a>. But if I go back to the server, now all of a sudden we see a save message. All of a sudden we see a saving genre message here. Saving genre 28 action. And in here it actually says, okay, the new value you passed in is action two. So why the different values? Up here it says action, not action two. Down here it says action two. Well, that's because of a closure. So for here, I've got the original genre and the one I'm printing below in the table is this is the one from the actual form <a href="/tags/data">data</a>. So actually don't want to do this. Let's just print the <a href="/tags/data">data</a> from there. But now I've got this form <a href="/tags/data">data</a> and I can actually go and call a function to save this. I've got a save genre function. And I can pass in a genre object in there. So let's turn this form <a href="/tags/data">data</a> into the right shape. And see if IntelliSense completes this for me. No, it doesn't. Get the ID. And a string because there can be different types. And this actually needs to be converted to a number. And there needs to be a name there. And we also need to cast that as a string. And this is of type genre. That's not very easy. I was missing a comma there. Now I can pass in genre and actually want to await that because that's an asynchronous action. So save genre, sorry. Save genre is very simple. And it just goes directly and goes and calls updates on genres to updates that specific genre. So now I've kind of embedded the logic to do the update. I could actually have used <a href="/tags/prisma">Prisma</a> directly in here as well. And I've kind of embedded the logic to use insights of a component which is used from the client. Now let's see if I can actually update things. Genre three, save changes. Right here we see that action three, a genre showed up. And if I go back to the list, we immediately see that it is genre three. Go back here. And this didn't update that still needs that dynamic. But another neat thing we can do is in one of these server actions, we can actually redirect somewhere else. So I could call redirects and say, I want to go back to the genre list. Genres it's called. And why doesn't it redirect? That's not where it's supposed to come from. It should come from next navigation. The cool thing now is suppose I changes again to four, I click save changes. It does the updates and it should. It took a bit longer than I was expecting, but when it's finished, it should update. The reason it actually took longer is because it actually decides it needs to re query this <a href="/tags/data">data</a>. And there was still a sleep in there. So let me quickly get rid of that sleep. She was not in here, but I'm sure that you can see it. She was not in here, but in here, this one. That makes it slow.

But now, all of that looks good. If I go back to the browser though, I'll get an error. Although it complains about a very different component now, a shopping cart. If I take a look at that movie cart, you see this uses a new shopping cart. So this uses a hook. And as it's in almost all cases, hooks mean that something has to be client component. But I've also got a button in here with an onClick, and that definitely makes it a client component. So let's turn this into a client component by adding useClient. Now if you add useClient to indicate that this is a client component, it has to be at the top of the file level above your imports. It really has to be the first thing in that file. If I put useClient down here, that my editor actually goes and change it into a different string. If I do it up here and get rid of that, it just leaves it like that. And it's all good.

So now I get a different error. Unhandled runtime error, failed to parse URL from slash API slash movies. So what's this all about? Well, if we go back to that page, we can see that here we're doing a fetch of that URL, and that's where it actually points to. Can we actually see that? No, we can't really see that here. But trust me, this is what it points to because it's actually this query which we're doing. There's no genre being passed in here, so we're getting all the movies. Now why is it complaining right here? This worked perfectly fine before, before this actually happened in the browser, which means that any URL you use, which is a relative URL like this, is basically tagged on to the current domain, the current origin. So it's executed against localhost port 3000. Now this component renders on the server, not in the client, which means that there is no relative URL anymore. So I kind of have to grab that URL and say, well, we want this URL in the context of localhost port 3000. And if I save this, it should work again, and I should be able to go to a different genre and all of that still works. So we can do exactly the same with the details page. Let me quickly do that because that also contains a useClient and the setup is very similar. UseState, side effects, et cetera. So this returns a movie like this, and this should be an async component. Now you might've noticed that in the previous page, I was actually using a traditional export default function movies page. Here, I'm using a <a href="/tags/lambda">Lambda</a> function with typed SFC as a const, and I'm still doing the export default below here. <a href="/tags/react-server-components">React Server Components</a> really don't care. Next doesn't care. This will just work. I will have to make this a little bit more complex, I will have to make this a fully qualified URL though, and now this should also work. Let's actually double check that it does. And it doesn't, because again, we're getting into a create context. So are we using one over here? No, but if I go into this movie form, over here, we're using UseToast and it actually uses a context under the hood. But there is also a lot of client-side interactivity there, a whole input form, et cetera. So this needs to be a client component. So what I'm basically doing is pushing those useClient directives further to the component leaves, and now it actually renders. Now, if I look at the movie card, I just make this whole card a client component. If I look at it, like all of this above here is not interactive. The only interactivity is these two items here. The details is actually a link, an anchor tag. So that standard browser behavior doesn't need to be rendered on the client. The only thing is this button. So that has a click handler. So that's the thing which should really be a client component. So in a real application, I would actually go and turn this into a separate component. It's the only one which actually uses that useShoppingCard hook. So that's the thing I would make a client-side component and this card would actually also be a server-side component. But in the interest of time, I'm not actually gonna do that right now. So this is basically what I just did. Main reason for pushing things to the server is better <a href="/tags/performance">performance</a>. Your server is typically faster. It only runs once. The output can be shared between different browsers. The <a href="/tags/code">code</a> doesn't have to ship to the browser, etc. The <a href="/tags/code">code</a> doesn't have to ship to the browser, etc. What I said, I can just use async await, which is much nicer than having to use a side effect like render of useEffect called update state, render again, etc. Prevents a second fetch by using the second parameter of the useEffect. What changed, etc. So much nicer. So this is the first page I changed, the movie list with all the movie cards. Remember that fetch has to be fully qualified URL. In order for that to work, that movie cards was turned into a client component. And then I did the same with the movie details form, not with the edit form, and the edit form itself was turned into a useClient. Components so that rendered on the client because it really needs to be interactive. So I see a question. Well, then go ahead. Hi, thanks. Can you go back one slide back when you actually. This one? Yeah, I know or I get why you need to put the fully qualified URL because we are not longer in browser. However, I can imagine that the app can run, it run on localhost when you're developing locally, but when you actually deploy somewhere else, it will get a different domain, different hostname. So is there any trick or tip or constant that you actually use in order not to repeat this hostname over and over again in all your components? Yeah, that's an excellent question. And I should've mentioned that. What I typically do is I create an environment variable, and then when I deploy the application, I've got an environment variable with the origin of the application. And I just point that's well, turned development to localhost port 3000. And then when it's deployed, for instance, to the problem solver dots NL. So at runtime, it kind of switches between those different origins. Okay, got it, thanks. Any other questions? And I can actually see there is a message in the chat. Yeah, there was a note in the chat from Valerio, Next supports environment variables in his config.

And indeed, a lot of my applications, <a href="/tags/react-components">React</a> applications are built with Next. And I typically host them on Foresell where I use those environment variables, really convenient. No other questions?In that case, let's actually get Jean-Luc Picard back. Oh, there is another question from Luca. Go ahead, Luca. Hi, yeah, thanks for your session. So my question is a bit more on the motivation side. So on slide 20, you introduced that like bringing the <a href="/tags/code">code</a> back to the server or like integrating back and front end <a href="/tags/code">code</a> would lead to better <a href="/tags/type-safety">type safety</a>. Do you see any upsides? Because I mean, you could also share the types with a library or something. Like, yeah. Is there any upside or just?Well, for one thing, let me go to the movies page. Like here, I'm saying, over here, I'm saying, oh, wait, the JSON for that response. If I look at the typing, the JSON function of a request returns a promise of any and isn't typed. Now, I could share these types of movie but there was no guarantee that that's actually correct. I'm just saying, okay, get some <a href="/tags/data">data</a> and I'm gonna treat it as that type. But whether that type is correct, maybe it's out of date but maybe it's the completely wrong type. There is no check there. So it's easy to make a mistake. Quite often when I use a REST like this, I'll use something like Swagger to generate my types for me but then they could still be out of sync with the server because there is a generation step in between there. The same if you use <a href="/tags/graphql">GraphQL</a> or something like that. And one of the next steps here, we're actually gonna switch this away from using Fetch here but we're just gonna do the <a href="/tags/database">database</a> query directly in the components. And then I've got <a href="/tags/prisma">Prisma</a>, which returns me a specific type exactly the fields I requested, et cetera. I've got a much better <a href="/tags/type-safety">type safety</a>. Yeah. Yeah, I see that point. I guess the <a href="/tags/type-safety">type safety</a> would be like equivalent if you use the Swagger stuff for the type generation but you just get rid of that intermediate step, right? Yeah. More efficient. It's an additional step without getting into too much details. But in a lot of cases I work on the client application and there is a different team working on the <a href="/tags/backend">backend</a> application, which we query. So they might've deployed a new version of an API which is not actually compatible. But I don't get compile errors. I don't see that until I actually update the types or get some weird runtime error saying that some property I expect to be, there is all of a sudden undefined. Yeah, I see. And doing that more directly prevents, well, it doesn't prevent these errors but makes them less likely and makes the feedback cycle shorter. Mm-hmm. If I can add another thing, if you have multiple front ends working with the same API that provides some <a href="/tags/data">data</a> models which are piped, you would have to replicate or would you distribute these server components then to all these front ends? Like if they would be operated by different teams?Well, I might do that. It depends a bit on the server components. More likely I would put the <a href="/tags/data">data</a> access. Like I've got, where is it? I've got a server folder here in the, oh, sorry, in lib. I've got a <a href="/tags/database">DB</a> file which uses <a href="/tags/prisma">Prisma</a> client. Like this is basically tied to a specific schema which is defined. I would put that in a shared library and use that. Yeah, I see. Cool. Which might be out of sync but it helps. Arian has a question. Yes, thank you, Maurice. This is really great so far. Thank you. Maybe you could, I just wanna make sure I understood the part with the client boundary and I think a similar question was also raised in the chat. If you have a client component and there's something marked with use client, can the children be server components? The way I understood it, yes, because then part of it is <a href="/tags/html">HTML</a> coming from the server as part of a client component or am I wrong? That would be really interesting how this waterfalls down. Yeah, it's actually something that I'm gonna come back to later but in a nutshell, yes, a client component can have a server component as a child but what the client component can not do is render a server component. But what you can do is just like you have to children prop in the <a href="/tags/react-components">React components</a>, one server component can render another server component and pass that in as a child to which client components and the client component then can actually compose that together the way it wants. And we'll actually, I actually have a demo of that. So the children, yes, the rendering part, no. Only a server component can render another server components but it can pass it on to a client component for composition. Let's actually go and do this part. Let's make the first of these two pages server components and their children client components. Now I mentioned I was using Next and I mentioned in the beginning that the app router part was important. So why? And for that matter, I mentioned we <a href="/tags/react-components">React</a> now requires a server, which isn't always the case. Like it's only the case where you're using <a href="/tags/react-server-components">React server components</a>. So if you're not doing <a href="/tags/react-server-components">React server components</a> you can still do <a href="/tags/react-components">React</a> traditional way with just complying just client components. That hasn't gone away. So no worries there. Existing applications will just work as is. But if you want to get into <a href="/tags/react-server-components">React server components</a> and start using that capability then you do need a server part. There needs to be a <a href="/tags/react-components">React</a> capable server. Which means that we need functionality there. Now there are several options. Next is in my opinion, the only one which is ready for production applications.

Welcome everyone to this <a href="/tags/workshop">workshop</a>, <a href="/tags/react-server-components">React Server Components</a> Unleashed. We're going to do a <a href="/tags/deep-dive">deep dive</a> into the future of <a href="/tags/react-components">React</a>. We're going to start off relatively easy because I'm assuming that all of you have experience with <a href="/tags/react-components">React</a>. If not, let me know because I might have to explain a few more things which I was kind of expecting everyone to know.But I don't expect people to be really familiar with <a href="/tags/react-server-components">React Server Components</a>. I kind of presume you've heard of them and that's why you signed up for this <a href="/tags/workshop">workshop</a>. That sounds interesting. What is it, etc.So who am I? My name is Maurice de Beyer, aka the problem solver. Amongst other things, Microsoft MVP, which doesn't mean I work for Microsoft, but I just do marketing for them. Lots of presentations, workshops, stuff like that. Freelance Developer Instructor currently working for some day of FinTech startup in the Netherlands. I'm on Twitter. I've got websites like pretty much everyone. Not that there is a lot of interesting content there, but if you want to, you can check it out. I've got an email address, so if you've got questions later about material in this course, feel free to reach out on Twitter or by email to ask me questions.

So what are we going to cover? Well, we're going to start off with what are <a href="/tags/react-server-components">React Server Components</a> and why should you care? We're going to take a look at <a href="/tags/nextjs">Next.js</a> and the <a href="/tags/nextjs">Next.js</a> App Writer because as the name suggests, <a href="/tags/react-server-components">React Server Components</a>. We kind of need a server part here. It's no longer just in the client in the browser. And then we're going to take a look at how we can turn existing client side <a href="/tags/react-components">React Components</a> into server side components. How we can do <a href="/tags/database">database</a> queries, <a href="/tags/database">database</a> updates, things like that, directly inside of your components, which is pretty neat.We'll take a look at how this works with suspense and streaming under the hood. We'll do a bit of a <a href="/tags/deep-dive">deep dive</a> into how certain components are rendered, where they are rendered, how you can compose those components together to get some specific results. And we'll take a look at something which sounds completely different, <a href="/tags/react-components">React</a> Server Actions, but is actually part of the <a href="/tags/react-server-components">React Server Components</a> specification. Especially when you start doing <a href="/tags/forms">forms</a>, <a href="/tags/data">data</a> entry <a href="/tags/forms">forms</a>, <a href="/tags/react-components">React</a> Server Actions are a really neat way of doing it. But they're actually more general purpose than that, they're not just for <a href="/tags/data">data</a> entry <a href="/tags/forms">forms</a>, there is much more you can do that.I've also turned this course into, or this <a href="/tags/workshop">workshop</a> I should say, into a larger course where I go more <a href="/tags/deep-dive">in-depth</a> into the material, cover material, I just don't have time to do in this <a href="/tags/workshop">workshop</a>. So just a general recommendation, this is a very interactive <a href="/tags/workshop">workshop</a>. I'm going to do demos of how to do things with <a href="/tags/react-server-components">React Server Components</a>, and then the basic setup is for you to do the same. You can just watch me do it and that's it. That's fine if you want to. You can copy and paste all the codes from GitHub if you want to, that's fine as well if you want to. But you'll get most of this <a href="/tags/workshop">workshop</a> if you actually type in the <a href="/tags/code">code</a>, make typos, make mistakes, see the error messages, etc. Doing is the best way of learning. Just watching, you'll pick up <a href="/tags/tips">tips</a> and maybe it will be familiar in a month from now. If you copy and paste it will last slightly longer, but not much more. Typing in just is the best way of learning, doing things.

Now we've got some prerequisites which I'm assuming everyone's good with, because I'm assuming everyone is using <a href="/tags/react-components">React</a>. You'll need Node. Node 16 or later is fine. Screen shot here has Node 18. I think I've got Node 20 something on my machine right now, upgraded since I created the screenshot. We'll need Git, but just to clone the repo. So not much Git usage. And of course we'll need <a href="/tags/npm">npm</a> to install the required <a href="/tags/npm">npm</a> packages, which are not included with the repo. If you've got <a href="/tags/yarn">yarn</a> or pnpm, they're perfectly fine package managers. But I would still recommend you use <a href="/tags/npm">npm</a> to install because there is a package.log.json file which <a href="/tags/npm">npm</a> uses. And that way you get exactly the same version of packages I'm using. So I've got a little <a href="/tags/cli">terminal</a> window open. If you want to check, you could do something like node-v or —version. And it will tell you like, I'm on node 20.9.0. So Node 16 or later is going to be fine. The same with <a href="/tags/npm">npm</a>. I've got like, what is it? Dash v. <a href="/tags/npm">Npm</a> 10.2.4, but like <a href="/tags/npm">npm</a> 9 or 8, any of that will be just fine.

There are two important links, which were also shared in the chat window. The first is a link to the repository. GitHub.com, my username is MauriceDB. And then react-berlin-2023-ws. Let me actually zoom in a bit on that. This contains all the <a href="/tags/code">code</a>. We'll clone this in a minute. The other link is right here, bit pointy. And then with the same react-berlin-2023-ws <a href="/tags/workshop">workshop</a>. This contains PDF with all the materials. And depending on your browser, it will either download it or it will, like Chrome does, just show it in line. Now, I highly recommend you keep this PDF handy because like this, you've got the links in here. But most of these images, let me actually scroll a bit further. Where, where, where? Here, you'll see images like this with <a href="/tags/code">code</a> changes we'll make. All of these are links. If you click on the link, it will actually take you to, well, in this case, the components. In most cases, it will take you to the specific commit where that change was done. So you can see exactly what was done. Let me find another one, which takes you to a commit. Opens some random image. Then you see in, for this step, it's basically, we added this component, make these changes here, et cetera. Every step I committed as a separate commit and is linked in GitHub. Convenient. I can also scan the QR <a href="/tags/code">code</a>. I'll leave these up for a minute.Now, the starter repo is basically a <a href="/tags/nextjs">Next.js</a> application, which we're going to use. And the main branch contains all the completed <a href="/tags/code">code</a>. So you've got all of the <a href="/tags/code">code</a> on your machine as well. There is a 00start branch, which is actually the start place where we'll start from and we'll convert that application, which is a very traditional, purely client-side Next application. And we'll turn that into using <a href="/tags/react-server-components">React Server Components</a>. The basic setup is there, but it's not <a href="/tags/react-components">React</a> Server Component yet. So we don't need to do this, but just to show you what I did to create this application, I created the Next application with the Create Next app. I selected <a href="/tags/typescript-libraries">TypeScript</a> because I'm a <a href="/tags/typescript-libraries">TypeScript</a> fanboy. There is nothing with <a href="/tags/react-server-components">React Server Components</a> which requires <a href="/tags/typescript-libraries">TypeScript</a>, but I like using it. I enabled ESLint, although I didn't really do much with that. It's just a default choice. I use Tailwind <a href="/tags/css">CSS</a>, which I pretty much like as well. Again, not required, but it's the way it's set up here. We're using the SRC folder, also optional, but useful. And one important thing is this one. You get a question if you would set it up. Do you want to use the app router? Yes, no, it's recommended. But for using <a href="/tags/react-server-components">React Server Components</a>, it's not just recommended. It's actually required. If you say no to this, you'll get the traditional pages folder in <a href="/tags/nextjs">Next.js</a> and the pages folder does not support <a href="/tags/react-server-components">React Server Components</a>. So make sure this is set to yes. There is an alias for imports, which helps a bit, but not that important. So that's what I did to create the basic application. Then I installed Shad.CM to get some nice components. Nothing's difficult there. I added a whole bunch of the Shad.CM components themselves, which are used. Again, nothing really needed, just to make the <a href="/tags/user-interfaces">UI</a> a bit nicer and easier. Like I mentioned, all the different steps are different commits in the GitHub repo. So this will take you to that list of commands if you want to see them. And then you'll see this gentleman combine quite often, Jean-Luc Picard, which is famous from Engage. In this case, you don't have to do something, but in other cases, when he shows up, it's basically your cue to do something. I'll have just demoed how to do something like create a <a href="/tags/react-server-components">React Server Components</a> or do some async query in there or something like that. And it's basically your turn to do that. Make sure that the technique and everything that's important there is clear. I'll be using a feature from Zoom, which are breakout rooms, where I basically split the group up into lots of small little rooms. You can work together in one of those rooms. Ask questions about stuff to the others, it's a bit easier when you're just with three or four people, but you can also invite me if you get stuck somewhere. So you can invite me into that breakout room and I'll join to explain something, which is a bit easier in a breakout room with three or four people than in the whole group with more than 30 people. Now, the first thing we need to do, which I am actually going to do, is clone this GitHub repo. So let's actually go to the repo. Where is it? Codes here. Copy that URL, go to the <a href="/tags/cli">terminal</a>. It's clone, pass in that URL. And I'm using HTTPS here, but you can use the Git version as well. So we've cloned the repo.

I'll <a href="/tags/ci-cd">cd</a> into that and I'll do an <a href="/tags/npm">npm</a> install. So that's gonna install the <a href="/tags/npm">npm</a> packages. Remember, it's suggested to use <a href="/tags/npm">npm</a>, not <a href="/tags/yarn">yarn</a> or pnpm. I've got nothing against those, but there are no log files for those. So in the case, you might get new versions of components of Next and things might just work slightly different.Now you should see messages like this. I'm using <a href="/tags/prisma">Prisma</a> here for the actual <a href="/tags/data">data</a> we're gonna use. There is a <a href="/tags/prisma">Prisma</a> migration, which creates the <a href="/tags/database">database</a> from scratch and populates it with <a href="/tags/data">data</a>. So that's this tsnode sheet command, which puts the <a href="/tags/data">data</a> in there. If you don't see this, or there's an error, you'll end up without any <a href="/tags/data">data</a>, which will make it a bit harder to do things.Now, I can open this up in VS <a href="/tags/code">Code</a>. If you're familiar with the Next application, you'll probably have seen this, like we've got to standard Next config in here, et cetera. I mostly didn't change those, like there was one little change here for images. I'm using the movie <a href="/tags/database">database</a> <a href="/tags/data">data</a> from there and the images from there, which I frequently use with workshops. There's a <a href="/tags/prisma">Prisma</a> folder here with the <a href="/tags/database">database</a> stuff. We won't actually be touching that, but it's there if you want to. And no, I don't want to update Visual Studio <a href="/tags/code">Code</a> now. I think it just had an update, but.More importantly, there is an src folder. There is an app folder because we're using the app router. And in here, you'll find things like this page, which is basically a route. So this page in the root app folder is the home page, like if you go to the website, and then there is one for movies page here, and there is one for a specific movie, like that. Before I actually start, I'm going to switch to a different branch, the 00-start branch. And then I'm going to do an <a href="/tags/npm">npm</a> run dev, or I'll typically do it via Visual Studio <a href="/tags/code">Code</a> like this. So I've got the <a href="/tags/cli">console</a> window here where it's running. And then if I go over here, localhost port 3000, I should see the application show up. And there it is.So the home screen just has an update, and there it is. So the home screen just has a nice picture. There's a list of top-rated movies here, at least a short list, just some <a href="/tags/data">data</a> to work with. You can see all of them like this, or you can watch them, filter them by category, like the adventure ones, or thriller, or like, what is it? Family. I guess there are not that many top-rated family movies. There is a list of genres here. Each of these has a little edit form. Currently, these are not working. Like you can edit there. You can click Save Changes, but nothing will be saved. We'll come back to that later. There is a server or clients page here, which we'll use to explore how components can be composed together. And inside the movies, there's a bit of functionality. You can add movies to the shopping cart, and then this button lights up. You can do a checkout. Need to pass in some name, and then the account number, which has to be four characters long. And then you can click OK, and then we get this message here, Checkout Completed. And in the <a href="/tags/cli">console</a>, I actually had a message here about the movies I checked out. There's also a details screen, which is, again, an edit form, so I can make changes. And here I can actually make changes like I do like Godfather Part 1. Submit this, and if I go back to the list of movies, we indeed see The Godfather 1. We actually change that back, or actually let me do that in a slightly different way. Go back here. Because another useful thing to realize is I've got this, where is it, over there, <a href="/tags/prisma">Prisma</a> Seed command. So that's this command right here. And if you run that, either from the command, or like I'm doing now, I just typically run it from here, it will run the <a href="/tags/prisma">Prisma</a> Seed action again. So it will basically... Well, it doesn't recreate the <a href="/tags/database">database</a>, but it will reset the <a href="/tags/data">data</a> in the <a href="/tags/database">database</a>. So if I go back here and refresh this, I've got The Godfather without any changes. So this is basically the application we're going to work with. The <a href="/tags/code">code</a> currently is pretty traditional. Just to give you a little preview there. No need to do this. Like the list of movies, basically has a very traditional way. It uses the use states to track state. It uses the user factory with a fetch in here to load the <a href="/tags/data">data</a>, the movie <a href="/tags/data">data</a>. There is an endpoint here to query those movies. So very traditional <a href="/tags/react-components">React</a> style application. It doesn't even use the <a href="/tags/nextjs">Next.js</a> capabilities of GetServerSideProps or GetServerSideProps. Or GetStaticProps or any of those things. So back to the slides. So the <a href="/tags/npm">npm</a> packages are just installed. And then don't forget this to check out the 00start branch.

Because if you don't, you'll be on the main branch, which already contains all the <a href="/tags/code">code</a> you need. Which makes it a little hard to do things. So <a href="/tags/npm">npm</a> run dev runs <a href="/tags/nextjs">Next.js</a> in development environments. So it will recompile and build all the changes and serve those. And then when you go to the browser on local host for 3000, you should see this image and be able to click through the application, as I just did.So with that, it's time to actually do this. For the first exercise, just make sure that you can clone the repo, check out the 00start branch, make sure the application runs and is functional, just like it is for me.Before we actually get busy with <a href="/tags/react-server-components">React Server Components</a>, let's take a step back. And what are <a href="/tags/react-server-components">React Server Components</a>, and talk about that. Because <a href="/tags/react-server-components">React Server Components</a> kind of suggests with the name that there is a server involved. And turns out that's not just a wrongful suggestion, that's really the case. But traditionally, <a href="/tags/react-components">React</a> was this client-side <a href="/tags/frameworks">framework</a>. You would potentially just have a very simple static file server, load up <a href="/tags/javascript">JavaScript</a>, and the browser would actually render those components and they would do something. There wasn't really a server involved. Now with Next or <a href="/tags/remix">Remix</a>, you could have a server involved and do server-side rendering. But server-side rendering is basically rendering the components on the server, then shipping that as <a href="/tags/html">HTML</a> to the browser, and also sending all the components to the browser and executing them there again. And with <a href="/tags/react-server-components">React Server Components</a>, that's not the case. <a href="/tags/react-server-components">React Server Components</a> only execute on the server. They never execute in the browser. So that's quite a difference.Now, if you look at it, I've got a really simple schematic of an application here. We've got an application which renders a bunch of components like a navigation bar, a movie list, or a movie detail, depending on your route, and with the movie list are a number of movie cards, and you might be able to rate a movie in there with a button. And traditionally, it would be <a href="/tags/react-components">React Components</a>, and that would all render in the browser. The server basically didn't really do anything there. Now, traditionally, we also had server-side rendering. And if you use something like Next or <a href="/tags/remix">Remix</a>, or you had your own server-side rendering setup, you might have something like this where all of that would render on the server, and then ship all of that as <a href="/tags/html">HTML</a> to the client. So the client would actually see the well-finished page sooner. But all the component <a href="/tags/code">code</a> would also be shipped to the client, and the client would basically re-render the whole application and make, well, things like event click handlers active, start using use events which would not execute on the server with server-side rendering and things like that. So it's basically everything just happens twice, or most everything happens twice. The server would skip a few parts, and the client would always do everything. With <a href="/tags/react-server-components">React server components</a>, that's kind of different.Now the application, the movie list, the movie cards, the navigation, movie details, et cetera, they're server components. They render on the server, but not in the browser. In the browser, you kind of get the result of what renders there, and that turns into the browser's document object model. So the things you see in the browser window, the divs, the spans, buttons, et cetera. Some components which require interactivity, like a movie editor, but maybe a rate movie button, something like that, which is a click handler. They would be marked as client components. And even when you're using <a href="/tags/react-server-components">React server components</a>, those are not rendered on the server. They are always rendered on the server. They are always rendered on the client only. That kind of means that <a href="/tags/react-components">React</a> has to do a lot more. First of all, it has to start doing things on the server, which it never did, but it also means it kind of has to start splitting things. Well, some of the components render on the server, and the <a href="/tags/code">code</a> never gets shipped to the browser at all. They never re-render in the browser. So in the browser, they're kind of static. Other components render on the client. They need like maybe a button click handler or some other <a href="/tags/browser-api">browser API</a>, or maybe a <a href="/tags/react-hooks">use effect</a> or <a href="/tags/react-hooks">use state</a>. They will be able to re-render or do more stuff there. And they can't run on the server. They will always render on the client. <a href="/tags/react-components">React</a> has to split those up, treat them differently, and on the client in the browser, actually combine the results of the server action with the client action in order to give you the <a href="/tags/user-interfaces">UI</a> you want. That means <a href="/tags/react-components">React</a> has to be smarter.Now, if we just have the same API as we had before, there wouldn't be a lot of point to it, because I just mentioned that one of the things you can't do in the <a href="/tags/react-components">React</a> server component is <a href="/tags/react-hooks">use state</a> and <a href="/tags/react-hooks">use effect</a>. You can't change state to re-render something because those component only render once. Having a <a href="/tags/react-hooks">use effect</a>, if you can't change state in there, doesn't do a lot. So there needs to be something which makes all of this worthwhile. And the fact is that client components are just simple functions. Well, maybe they're not simple, but they're relatively straightforward functions. They're called, they return a virtual DOM object with what the DOM should look like, and that's it. If they need to do something asynchronous, they have to hook in to <a href="/tags/react-hooks">use effect</a>, etc., to do that kind of stuff. Well, with server components, you can just make that <a href="/tags/react-components">React</a> component itself an asynchronous function, and you can just start using await in there. So in a <a href="/tags/react-components">React</a> server component, I can do await some kind of fetch, go and do some RESTful query. But because it runs on the server, I could also do a <a href="/tags/database">database</a> query. I could do a prisma.movies.findMany and find all the movies in the <a href="/tags/database">database</a> and sort of filter and all those kind of things which you previously couldn't do inside of <a href="/tags/react-components">React components</a>. Previously, the way to do that was create a RESTful endpoint or maybe a <a href="/tags/graphql">GraphQL</a> endpoint, and then have to client query into that using <a href="/tags/react-hooks">use effect</a> and fetch, and then basically on the server, query the <a href="/tags/data">data</a>, serialize that to JSON, send that back to the browser. The browser would then decide, okay, now I've got some state, I'll rerender all the components, and I'll update. All of that becomes much more direct now. And nice side effects. Those components are much more secure. Their <a href="/tags/code">code</a> is not sent to the browser, so anything you put in there is never leaked, as I can say, to the clients, like you can put username passwords in there.

Like, I wouldn't, but you can. You can put API keys to access resources in there. That's all perfectly fine. It doesn't go to the browser. It also means that the actual bundle which does go to the browser becomes a lot smaller, because if half your components never ship to the browser, then that's a lot less <a href="/tags/code">code</a>. And presumably it's not just the <a href="/tags/code">code</a> you write, it's also libraries they use. Well, if you use all of those libraries only on the server, well, that means that the client has to do far less loading, far less parsing, far less rendering, and is a lot faster.If you want to use <a href="/tags/typescript-libraries">TypeScript</a> with <a href="/tags/react-server-components">React Server components</a>, that's no problem, but just make sure you've got at least <a href="/tags/typescript-libraries">TypeScript</a> 5.1. We're at 5.3 something at the moment. Not exactly sure of the current version, but it is relatively, or it's already past 5.3. So if you create a new project, that's not going to be an issue at all. But if you've got an existing application, you're going to convert to a <a href="/tags/react-components">React</a> Server component-based application. Then make sure that you're not using a very old version of <a href="/tags/typescript-libraries">TypeScript</a>, because <a href="/tags/typescript-libraries">TypeScript</a> back then did not consider a <a href="/tags/react-components">React</a> component to be asynchronous, and if it's something which is async and uses await, <a href="/tags/typescript-libraries">TypeScript</a> won't compile it. It will actually run, but it just won't compile.Now, what does a <a href="/tags/react-components">React</a> Server component look like? Maybe something like this. In reality, you can't really tell in many cases. In this case, I can tell that this is a Server component, because for one, it's an asynchronous component here, and the other is, over here, I'm doing a <a href="/tags/prisma">Prisma</a> call. So I'm going using the <a href="/tags/prisma">Prisma</a> ORM to go into a <a href="/tags/database">database</a> and finding, in this case, a list of genres. Well, <a href="/tags/prisma">Prisma</a> is database-oriented. It's a <a href="/tags/database">database</a> ORM, so that's not going to work in the browser. So that kind of tells me that this is a <a href="/tags/react-components">React</a> Server component. Client components can't be async, so that's a dead giveaway, but even if this was not async, and not doing the <a href="/tags/prisma">Prisma</a> query, this could be a Server component. There are many cases where it's really hard to tell, and it's more of a side effect of other things, but there is nothing here that says this must be a Server component. So how does <a href="/tags/react-components">React</a> know the difference between a Client and a Server component? Well, with Client components, we use this directive, use Client. This basically tells <a href="/tags/react-components">React</a> that this component should render on the Client. It turns out to be a bit more nuanced than that, but it will make sure that this specific client is always rendered on the Client. Now, I found this a bit strange initially. We're talking about <a href="/tags/react-server-components">React Server components</a>, which is the new standard, but we're not marking Server components as Server components. Instead, we're marking Client components as Client components. And as I'll show later, the reason for this is that use Client doesn't actually say this is a Client component, but this is a Client component boundary. You might have another component which is rendered from this component, which does not have use Client, but because it's rendered from another Client component, it's also a Client component. And that same component could be rendered from a Server component, and because that's a Server component, it would also be rendered as a Server component. So it's more like, how are things being rendered by who? And the use Client really is the boundary from, okay, here we switch from Server rendering to Client rendering.Now, what kind of components need to be Client components? I mentioned a number of examples already. It's basically everything which uses State, which uses Side effects. The simple rule is every component which uses a hook, which isn't 100% true, but for a general rule, that's perfectly fine because you'll have very few hooks, which don't use Side effects, don't use States, or Client-side APIs. Like anywhere where you use browser APIs, it needs to be a Client component, use Client. If you use context, it needs to be a Client component. So lots of those cases need to be Client components. So all of those will need to have a Use Client directive.So what does it take to actually turn a <a href="/tags/react-components">React</a> Client component into a Server component? Well, in many cases, not a lot. Let me go to the source <a href="/tags/code">code</a> of the application for the moment. And right now, if I look at the list of movies, it's this component. So that's this page basically, or for that matter, any of these pages. I'm just going to stick here. It uses a very traditional component, which is RenderTestedPage. It has a UseState in there, UseEffect. So like I said, that should be a Client component. And the fact if I scroll to the top here, it says here, Use Client. So that makes this a Client component. And all of this is only executed in the browser. And I say only executed in the browser because of Server-side rendering, that's not quite true. But if you ignore Server-side rendering for a moment, which Next does do, it would be completely true. Now I can make this a Client component. Sorry, a Server component by removing that Use Client. But I've still got UseState in here, I've got UseEffect in here. So if what I just said was true, this should fail. And indeed, if I go to the browser now, it says, okay, there is stuff here like UseState, so we should add that Use Client there. So if I put that Use Client back in, my error goes away and the page renders again. But if I look at the functionality here, look at the source <a href="/tags/code">code</a>, it basically gets a bunch of movies, maps over them, creates movie cards for those movies. So there is no interactivity here, there is just this fetching of <a href="/tags/data">data</a>. And I should actually be able to do that equally well on the server itself. So let's turn this into the Server component. Get rid of the state. Get rid of the UseEffect, we don't want any of this. We're using await here, so this function should be async. This needs to be typed. Otherwise it doesn't know what the movie is. Which is one of the downsides of doing a fetch call, like JSON just returns a promise of any. Doesn't know anything about the typing.

There are other options like there is <a href="/tags/waku">Waku</a> which is from Daishikato which is kind of a minimal <a href="/tags/react-components">React</a> <a href="/tags/frameworks">framework</a> which is pretty interesting. I can recommend taking a look at it especially if you want to understand what's going on under the hood. It's really nice, but it's still very much a thing being built and in no means complete. Like a while ago, I wanted to give a demo with <a href="/tags/waku">Waku</a> and all of a sudden they published new version which didn't work on Windows anymore. So very much experimental still although it will probably be quite this interesting. There's also <a href="/tags/react-server-components">React server components</a> demo from the <a href="/tags/react-components">React</a> team, but it's like the name says it's just a demo, it's not going to be updated. So next is really great. If you build a traditional way using say create <a href="/tags/react-components">React</a> app or feed that's still perfectly valid but you do not have the server parts there. Something I would have expected somewhat was <a href="/tags/remix">Remix</a> but for <a href="/tags/remix">Remix</a> 2 which shipped relatively recently there is no support for <a href="/tags/react-server-components">React server components</a> yet. They have announced they'll include that with <a href="/tags/remix">Remix</a> 3. So I've got no clue when that will be but they'll definitely do it. And my understanding is that <a href="/tags/shopify">Shopify</a> <a href="/tags/hydrogen">Hydrogen</a> and <a href="/tags/remix">Remix</a> by the way, is also from <a href="/tags/shopify">Shopify</a> these days but <a href="/tags/shopify">Shopify</a> <a href="/tags/hydrogen">Hydrogen</a> is supposed to be <a href="/tags/react-server-components">React server components</a> compatible. Now I've never used <a href="/tags/hydrogen">Hydrogen</a> so I can't say how well that works and whether that's actually true, it's just my understanding. As far as I'm concerned, Next is by far the best option to do a production app. If only because quite a few people from the <a href="/tags/react-components">React</a> team actually joined for sell and are working on Next these days.

Now, why do we need a server? And what does it actually do? Because it's a <a href="/tags/react-components">React</a> server component, it renders on the server. But with server-side rendering we were also rendering components on the server. The difference though with <a href="/tags/react-server-components">React server components</a> is we're rendering on the server and we're shipping the results to the client. And the result of calling a render function is not <a href="/tags/html">HTML</a>, it's basically a virtual DOM representation. So you'll get an object back which is a type property which could be diff or it could point to another <a href="/tags/react-components">React</a> component. It has an object with all the props being passed into that component and it has all the children in there which are also props but treated slightly different. So that's basically a <a href="/tags/javascript">JavaScript</a> object or series of objects more likely. And those can be serialized as JSON and sent to the browser and used there.With server-side rendering it's the traditional way of using <a href="/tags/react-components">React</a> on the server. It's very much server-side rendering which turns everything into a large <a href="/tags/html">HTML</a> stream that sent this <a href="/tags/html">HTML</a> to the browser. The browser can render that directly which does not happen with <a href="/tags/react-server-components">React server components</a>. But with server-side rendering the whole <a href="/tags/react-components">React components</a> are also sent to the browser and they rerender there. Now with <a href="/tags/react-server-components">React server components</a> you kind of have to keep in mind that <a href="/tags/react-components">React</a> works in two steps. There is first a rendering phase where you turn a component or a series of components into a virtual DOM. And the virtual DOM is that object structure I mentioned with the type and the props, et cetera. And then there is a <a href="/tags/react-components">React</a> itself which diffs that virtual DOM with the real DOM, sees what the difference is and applies those changes to the actual DOM. With <a href="/tags/react-server-components">React server components</a> that still happens on the browser. So if you do pure <a href="/tags/react-server-components">React server components</a> without server-side rendering which is not what Next does but assume for a moment you're doing that you will not get any <a href="/tags/user-interfaces">UI</a> in the browser if <a href="/tags/javascript">JavaScript</a> is disabled. You really still need <a href="/tags/react-components">React</a> in the browser even if all your components are server components. You will ship adjacent objects to the browser and in the browser that will still be diffed against the DOM and then applied. So that still happens. You still need to <a href="/tags/react-components">React</a> on the client. It's not like <a href="/tags/react-components">React</a> will go away. In almost every case you will also have client components because there are very few <a href="/tags/react-components">React</a> applications which are not interactive. So you'll have additional components being rendered in the client. But even if you don't have any, it's still client-side logic. Now, that step was always there. It's nothing new but traditionally all of that just happened on the client where the components rendered would produce that virtual DOM and that virtual DOM would then be applied to the browser's DOM. It's just like that second step was sort of invisible but it was always there. Now they're split out a bit more so it's a bit more apparent. Now <a href="/tags/react-server-components">React server components</a> can be asynchronous and that has some implications for the server because it means that your <a href="/tags/react-components">React</a> application can render on the server and some components will be done immediately because they don't need to await anything but others will need to await things and that could potentially take a long time, maybe seconds, maybe even longer than seconds. So in order to accommodate that and render things in the browser as fast as possible, a <a href="/tags/react-components">React</a> server will actually use a streaming API to send all of that to the client. I'll have some screenshot later about what the payload actually looks like but you can actually see that in the browser. If I go here and open up the network tab and I refresh this, we should be able to see it over here. Why am I not seeing it yet? Let me try again. You'll see requests like this which have a question mark, underscore, error C is and then some kind of identifier after that. These are requests where the <a href="/tags/react-components">React</a> server actually streams asynchronous things back to the client or doesn't necessarily need to be asynchronous. If you look in the response, you can see, well, in this case, there was one line. Here you can see there was actually more <a href="/tags/data">data</a> being rendered. So you see we're in development mode. Now basically each line here is streamed separately. It looks a bit like JSON. It isn't really because each line is a separate thing. And you can see multiple lines being streamed as a block and then sometime later, a few more lines, et cetera. That's the way how things go to the browser. Typically, you don't need to worry about how that happens but it's just that you're aware.Another thing why you need a specific <a href="/tags/react-components">React</a> server with additional capabilities and a special build process is the <a href="/tags/code">code</a> bundling. If a server component is not used on the client, then there is no reason to ship that <a href="/tags/code">code</a> or any of its dependencies to the browser. And those dependencies might be large <a href="/tags/npm">NPM</a> <a href="/tags/modules">modules</a> you're using, which means that your bundle becomes a lot smaller. But that also means you've got one <a href="/tags/code">code</a> base. And if I go back to my application, over here, I'm importing a movie card which does run on the client but this doesn't run on the client. And so it's not a matter of web pack coming in saying, okay, we've got this components, we need to bundle this up. We need to bundle up all the dependencies. It kind of has to figure out, okay, we've got stuff we need for the server, we've got stuff we need for the client. And at this point, we're still doing it on the file level but when we get to server access, we'll actually start embedding functions inside of components where part of it runs on the client and part of it runs on the server, which makes it even more interesting. So the whole bundling process there is quite a bit more involved in serving up the right codes and all of that. So that's why you need something like Next or Voxel or in the future, <a href="/tags/remix">Remix</a> capable server like that which has a lot of functionality. And you can't just use something like Create <a href="/tags/react-components">React</a> App or Feet, for that matter, you shouldn't use Create <a href="/tags/react-components">React</a> App anymore because it's been deprecated. But even Feet is just the traditional way where everything happens on the client and you end up with just a bundle being shipped to the browser. So that's why we use Next.Now, a bit about how things are updated in Cache because we changed our application but without realizing it, we actually broke our application. And let me show you something. We've got the Godfather here just for the sake of it. Godfather here, just like we had before. I can go to details. I can make a change here. I will call it the Godfather one because that was part one. I can hit submit. We see the movie updated message just like before. I go back to the list and there is no one here.

It's still the Godfather. I can take this, open up in a new browser. Still no one there. So it's not something in a local browser cache. I could open up this page in Firefox, different browser. It would still not say the Godfather one. So did the update fail or something? Well, let's take a look in the <a href="/tags/database">database</a>. I've got <a href="/tags/prisma">Prisma</a> here, <a href="/tags/prisma">Prisma</a> Studio, which will let us query the <a href="/tags/database">database</a> directly. And let's open up the movies. So where's Godfather here? It's says Godfather one. So the <a href="/tags/database">database</a> was actually updated, but for some reason the <a href="/tags/user-interfaces">UI</a> isn't. Like I can click away and it still doesn't update. Now, if I do a hard refresh, I'm doing control F5, Now it actually updates and becomes the Godfather one. So it looks like it eventually will pick things up, but not immediately. This eventually is only because I'm using the development version of Next. If I built this application into a production build and was running Next production, so Next start, then this would not have happened and I would have still seen the Godfather. It would never have picked up. So what's going on here? Next does a lot of caching and I've got a link here to the Next <a href="/tags/documentation">documentation</a>. And if you go into caching right here, you can see how it's going. It says, right here. You can see there are four different cache layers involved. There's request memorization, which means that in a given render cycle, if you request the same <a href="/tags/data">data</a> using fetch multiple times, it's just gonna do that fetch once and serve up the result multiple times, which is actually pretty good. You can see here, it's per request. There's a <a href="/tags/data">data</a> cache. Which is used by the memorization cache amongst other things. There is a full route cache, which is the one we've got problem with at the moment. And there is a router cache, but this one is a client cache. The first three are server caches. The last one is client cache. It turns out at the moment we've got a problem with that full route cache on the server and with a route cache on the client. So let's solve those problems. Let's first go to that full route cache. And somewhere down here, let me actually, this full route cache here. There is an option about how can we invalidate this cache. And there are a couple of different ways, but for now what we can do is use either of these two. Tell Next that this is a dynamic page because now it thinks it's not. And the best way to do that is by exporting a constant dynamic, which is set to the string force dynamic. Let's go and add that export here. And we need to do exactly the same in this page. This page, that's the Movie Edit page. And let's see if things are better now. So I just hit F5 to refresh to make sure we've got nothing still in our cache. We've got Godfather 1. I go to Details. I change this to 2. Submit, you see the Movie Updated message again. I go to Movies and it still says 1. Doesn't seem very good. So let's open this in a new tab. In this tab, it actually says Godfather 2. Remember before, when I opened up a different browser, we still just saw the Godfather. It did not pick up the change. Now it has picked up the change in a different tab or in a different browser. Here we still see 1. Let's see if it still says...

Okay, now it's picked up the 2 as well. So Next or <a href="/tags/react-components">React</a>, however you want to look at it. Next, in this case to be exact, is picking up the changes but only after some time. So the second part of the problem I mentioned was this router cache. This router cache works on the client and it caches pages on the client to prevent loss of requests to the server. Without this router cache, anytime you navigate on the client, there would be a request going to the server. Is this page still up to date? And if not, give me a newer version. This router cache prevents all of those requests.The problem though, with this router request, if full router cache, router cache opting out here, opting out, it says it's not possible to opt out. You can't disable this, you can't tell it's not to do anything. There is something about here when you're using the client to do the opt out, about here when you're using a link, you can set prefetch to false, but that does not opt out to the router cache. It just means that there is no prefetch done, which is already used to populate the router cache in <a href="/tags/deep-dive">advanced</a>. It's still used, but there is an API we can actually use to control this.So if I go back to the movie form, the client-side form, right here, after we've submitted the movie to the server and that's done, we can actually tell the Next that the client-side router cache should be invalidated. So let's import UseRouter. And anytime you import UseRouter, you kind of see there are two versions. There is a Next router, let me zoom this in a bit. So here you see there is Next slash router and there is Next slash navigation. That's a bit confusing. The rule is Next slash router is the traditional router, which is meant for the Pages library. Next slash navigation is the new router, which is meant for the app directory. So if you're using the app router, use Next slash navigation. Slightly different naming would have helped here, but you kind of have to remember Next slash router means Pages, Next slash navigation means App. And you can use both of those together if you want. So let's import that one. We'll reference router and here, I'll say router. And I can navigate with it, but that's not what we want to do. I just want to call refresh. So refresh basically means go refresh your caches. They could be stale, clean them out and load <a href="/tags/data">data</a> again as needed. And with that, if I go back to your application and make another change, actually let's go back and refresh to make sure we don't have any stale caches. So take the Godfather 2, I'll change this to the Godfather 3, I'll submit. And you might've noticed there was a brief flash because this page actually reloaded as parts of that router.refresh. And I didn't point this out before, but before the title here, didn't change. Now it immediately updated to the Godfather 3. And if I go back to the movies list, this is also immediately updated. So this is next specific, these caches are next specific, but given that most people who will use <a href="/tags/react-server-components">React Server Components</a>, at least for the foreseeable future, will use <a href="/tags/nextjs">Next.js</a> will run into this. And you really have to make sure you understand all the implications here of the caching and how things work. And it turns out later, we'll get into <a href="/tags/react-components">React</a> Server actions, those will actually make this even more complex. But, or more complex, well different is a better way to describe it. In many cases, it's actually gonna be simpler. So the first change I made setting the <a href="/tags/code">code</a> to pages I'm using to use force dynamic to make sure they're dynamically rendered. That still has to be done even if you do that browser refresh, sorry that router refresh. And I'm calling router refresh after we've updated the movie. In case you were wondering what happens in a multi-user scenario, the user who did the updates will execute browser refresh. So his local router will be refreshed and he will see changes immediately. The second user will not. If he's already visited that page in he visits it again, he will get the <a href="/tags/data">data</a> from his local router cache and with the dynamic page that router cache last for 30 seconds. So the first 30 seconds, he'll still look at stale <a href="/tags/data">data</a>. If it's non-dynamic, a static page, then the cache, I think it was five minutes. Let me check. It's just somewhere in here. Yeah, dynamically rendered page is 30 seconds. A statically rendered page is cached for five minutes. So the other user will get a notification or will get the updates, but only after some time. So the other export dynamic I added. So let's go and do that. Make sure these edits work again in your version by adding the force dynamic and the router. And after that, we'll actually take a look at updating the components, getting rid of the fetch and making that whole <a href="/tags/database">database</a> query much more direct, which is pretty nice. But we'll do that after this step. Any questions before I open up the breakout room? Yes, Vanessa. Can you please show me one more time what that force dynamic variable and where that's being used? This force dynamic variable? Yeah. So I added that to the two pages, the movie page and the movie details page. So it's basically this, the exports, consts, the value in here force dynamic basically means that this page should be considered by Next as a dynamic page, not as a static page. Because by default, Next concludes this is a static page. It does not need to rerender it when you request it again, because it thinks it's just gonna end up with the same result, which obviously isn't the case if the <a href="/tags/database">database</a> has changed. Okay. And that variable isn't used anywhere, we just declare it there and export it. Yeah. You export it, it has to have this name, but it's kind of one of those marker exports for Next, which you've got a page, because this has to be on the page itself, not on some components, but the actual page.

There are a whole bunch of things you can export there, which kind of tweak the behavior of how Next works. Okay. Thank you. It is a little magic, I realized that, especially if you've never seen this and what kind of values there are, they're not typed or anything. It's just this magic string. I'm exporting with the magic name. And it's a little hard to work with, but I'm sure they've seriously considered if there is an easier way. And I don't think there is.Then let me open up the breakout room again. Let's do this exercise. Okay. I mentioned before, we were still doing a fetch from our two pages, which we made asynchronous, but we actually could do things a little more direct now and just query the <a href="/tags/database">database</a> there. And that's going to be helpful. There is less <a href="/tags/code">code</a>, but it's also going to be faster, because now the browser sends a request to the server. Can you render a page for me? There's a <a href="/tags/react-components">React</a> server component. The <a href="/tags/react-server-components">React server components</a> says, okay, I can render this. I'm going to do a fetch, going back into the same server. Some other <a href="/tags/code">code</a> there executes, gets the result from the <a href="/tags/database">database</a>, serializes that as JSON, sends it over the wire back to the same server, the same process even. Deserializes that JSON into an object and starts working with it. That's a lot of network traffic and serialization, deserialization, which we can get rid of.The other thing I mentioned is, well, fetch returns a promise of any. So it's not typed. And me being a <a href="/tags/typescript-libraries">TypeScript</a> fan boy, I like things being typed. I like fast feedback, if something is wrong and my queries and props, etc, don't match up. So we can actually do things directly on the server and ignore this whole fetch part here. Because if we look at this fetch, which we're doing over here, we're going to localhost port 3000 and then either to API movies with a specific genre or without that genre. And there is this API movies, this one route, which is executed. So basically it gets the genre from the search prams and then calls this getMovie. And this getMovie actually goes into the <a href="/tags/database">database</a> and does whatever it needs to do. So let's just grab this whole function. Move it to the page share. We need to resolve a few things, resolve the missing imports. So <a href="/tags/prisma">Prisma</a> and the <a href="/tags/prisma">Prisma</a> types were resolved. And now instead of doing this, these two, we can just call getMovies, passing in the requested genre. The requested genre. Now there is a little type mismatch here because it says the genre is string or undefined and the function requests a string or null because slight difference in how things work. But if I fix that now, did I fix the wrong? No, I fixed the right one. I just scrolled wrong. And let's get rid of this. That should be almost okay. I do need to add an await there because it returns a promise it's asynchronous. So now in my component I'm directly querying the <a href="/tags/database">database</a>. No more fetch requests, no more types and things are gonna be faster and better typed because I see exactly what I'm getting back from the <a href="/tags/database">database</a> here. So suppose I use something else, I got an ID two here, I get immediately a compile error that's ID two doesn't match. And I can do exactly the same on the details page. We've got the fetch request. It goes to, where is it? This route handler that uses this getMovie just up here. Move that over here. And again, we resolve the import for <a href="/tags/prisma">Prisma</a>. We get rid of this. getMovie with the ID as a parameter. So simpler and faster. Let's make sure it actually works. So this page renders fine. I go to the details and it doesn't render fine. So something broke here. Interesting, let's see what I broke. I did a getMovie and I should have noticed already the compile error here. Title doesn't exist on promise of, I forgot to await. So compile error is gone. And this re-renders with <a href="/tags/data">data</a> now. So if I grab another movie, we see the <a href="/tags/data">data</a> directly. And now it's also relatively easy to fix another problem because suppose I get some ID of a movie which doesn't exist. Right now I'm left with loading movie dot, dot, dot. So the component thinks we're still loading a movie. But in reality, I'm just asking for non-existing movies. So this isn't exactly correct. And I could wait forever. This is never going to resolve to a movie, which basically says, well, if this doesn't return a movie, that's what we're rendering. So what we could do instead is findFirst, we could do a findFirst or a throw.

So if we find a movie, we resolve it. If we don't find a movie, we actually throw an error. And now I don't have an error page set up, so but it shows up a bit ugly, but now we get that error, no movie found. And it also means that this <a href="/tags/code">code</a> can go away because if we get below this awaitGetMovie, we have a movie object. There is no matter of a loading state there. Of course, it could be slow. This will still fill, of course. But now for an existing movie, it works fine again. Let's get back to the Shawshank Redemption. And that loads fine. Now, as I mentioned, things can be slow. So we might still need some loading <a href="/tags/user-interfaces">UI</a>, as I just deleted, but with <a href="/tags/react-server-components">React Server components</a>, there is a much better way to do that. And that's using suspense. And I'll come back to that in a minute to actually show how suspense works.

So simpler director, I get more immediate feedback of things being incorrect. I didn't actually show this yet, but what I typically have in my project is a compile step like this, which I'll run with a watch option. So this kind of stays running in the background. And if anywhere in my <a href="/tags/code">code</a>, there is a compile error, like if I remove that weight again, I immediately see here, okay, something is wrong. There is a compile error. Let's go and fix it. And it even suggests here from, well, that sounds like there should be a weight. I add that back in, save, and no errors anymore. Of course, this works on this project because it's relatively small. In a somewhat larger project, I wouldn't have this constantly running because it would get slow. But I would regularly just call a compile script to do the same, especially before I commit or push changes up to a pull request branch or something like that. So a small change, but with a lot of benefits, makes the <a href="/tags/code">code</a> faster, easier. I can actually get rid of those API end points. I don't need them anymore. I just left them for now. But in reality, deleting them would be better. They're not used. So here's where I deleted the get requests and the other could have been deleted altogether. So please go and make the same change unless there are any questions you'd like to ask first. Then let me quickly show one of the benefits of doing a <a href="/tags/database">database</a> query like this directly on the component. Or what I would do in a real application is I wouldn't do it in the component itself. I would abstract this away in an API layer, but it would be functions called from the components and not go over a RESTful query. But one thing I can do is if I go to that movies page, I'm querying movies here. Let's take this example. I'm just saying find all the movies, order them by a specific order, which is by the average vote descending. And then I'm returning that and passing those movies here into the movie cart. But if I look at the movie cart, that movie prop, what does it actually want? Well, it doesn't want to complete movie. It only needs a handful of props there. If I look at the whole movie, there is like a release date in there, but that's not used. There's a backdoor path and a poster path, two different images. Well, we're only using the backdoor path, not the poster path. There is a popularity there which we're not using. Now, in this case, the number of movies isn't huge. The number of <a href="/tags/data">data</a> items I'm querying and not using isn't huge, so it's not terrible. But I'm basically querying too much. So one thing I can do now is I can go in here and you can add a select clause there saying, I only want specific fields. And it comes up with a whole bunch. But I want to do this slightly different because I've got two different queries going on. So let's select over here. And include the same selects when we're querying by genre. Now, AutoComplete added a bunch of fields there, but now I immediately get a compile error here saying, well, I am missing a number of them. Now, let's actually get the correct ones. Those are the ones I want. Get rid of this list for a moment, and turn these into... Why is that not working? And a bit better? So now I should just select the correct fields. And if I say, if I forget one, I'll get an immediate compile error down here saying the movies I select don't match up with the movies I want. And by typing this a bit better, I can actually even make it so if I want to, that if I select one field too many, I would get a compile error as well. Not actually going to do that. We're not actually going to do this exercise in the interest of time, but it is a nice <a href="/tags/optimization">optimization</a> because I've got a query now from the <a href="/tags/database">database</a> for this specific use case. Because also the general use case is that so in the general, in the REST servers, sorting things by vote average would probably not be the best default sorting order for some kind of REST service. Sorting by ID or title would have been more appropriate. So using Satisfies actually is a good way to type this, and using the type from the movie card would actually make this even better so we can specify it very exact. But like I said, we're going to skip this exercise in the interest of time. Otherwise, we'll never get around to this part. Time for a coffee break.

So next part I want to take a look at using Suspense with <a href="/tags/react-server-components">React Server components</a>. But the first part I'm specifically going to look at pages. So this is somewhat Next specific. After that, I'm going to take a look at how we can do it in a more general way with Suspense components. But in both cases, it is actually going to use Suspense. So you can always wrap <a href="/tags/react-server-components">React Server components</a> around suspense boundary and put a full back <a href="/tags/user-interfaces">UI</a> in there. While they're still suspended, not completed yet, they will show that full back <a href="/tags/user-interfaces">UI</a>. It's really neat and we'll use that in a minute.But for pages, <a href="/tags/nextjs">Next.js</a> adds Next specific API and that's that you can have a loading.tsx. So a loading page there, which is rendered while that page is actually still loading. Which is pretty convenient and makes it pretty easy to have some custom <a href="/tags/user-interfaces">UI</a> there. So let's take a quick look at when that would be necessary. So let's make this page load slow, or at least let's make the GetMovies function run slow. And I've got a little helper function, sleep. And I can pass in some timeout, 200 milliseconds and we'll await that. Which makes getting the list of movies, pretty small, or pretty slow. We'll go here, make sure that nothing is in the local cache by refreshing and I'll click on movies. And now we see pretty much nothing happened. Like, if I go again, it's fast. Like, we see the movies list appear pretty much immediately. But if I'm on the homepage, I refresh again to clear the caches. I click on movies, so I just clicked. It takes a while and there was no feedback.Now, how are things rendered? There is this layout file and in here, there are these children and this is basically the child that we want to show. This is basically where the pages are actually rendered. Now you could put a suspense boundary around this, but that doesn't actually work very well. So that's not the recommended way of doing it. The recommended way is alongside this page.tsx, which denotes basically an endpoint, some kind of page, we'll create a loading.tsx. And in here we'll create a little component, exports default. We'll just make it return loading and home is not really a good name for this. Although at runtime, Next doesn't care. Next doesn't care, it's just the default export. So now if I do the same, I go to homepage, make sure that there's nothing in the cache. I go to movies, we see loading there, which is convenient. And next time I go there, it's already in the cache. So no need to do the same again. Let's actually put a slightly nicer <a href="/tags/user-interfaces">UI</a> in here. Let's go back to the slides and let me actually just copy this component. So that shows a nice spinner and is a bit nicer, but the end result is exactly the same. Go to home, click on movies, we see a nice spinner and once the movies have loaded it shows up. If I go to details, we briefly see that spinner. It is an asynchronous component. I didn't put asleep in there, but it's still asynchronous. It takes a brief moment to actually load movie <a href="/tags/data">data</a>. If I go to another like details, we briefly see that spinner again. The reason you see it here as well is that Next basically looks at the current folder. So over here, it looks at for this page is reloading. It uses that for this page. It looks if we're loading in this folder, no, that case it will go for up and see if it's there. So there is, it loads it. If there was one locally here, it would just use that. Which is pretty convenient. Let's actually get rid of the sleep, so it's nice and fast again. I did not want to open that up again. So here, to sleep in the get movies function. And in this case, I also added to sleep in the movie details page so that also loads a bit slower. But even without that, you can already briefly see that spinner appear. And in fact, I should be able to see that in the, this page as well, like it's there, it's noticeable. It doesn't take long, but it does show up even without sleep. So please go and add this. Remember, this is a Next specific API. This is not standard <a href="/tags/react-server-components">React server components</a>. But <a href="/tags/react-server-components">React server components</a> are suspense aware. And I'll show you in a second. <a href="/tags/react-server-components">React server components</a> are suspense aware. And I'll show you another example where we're actually going to use suspense to show a fallback <a href="/tags/user-interfaces">UI</a> itself. I've got a question, Miros. Yes, go ahead. Obviously, with <a href="/tags/nextjs">Next.js</a>, being a full stack application, what do you think is like viability is like if you had to make an enterprise-level apps like a bigger company using it for full-stack? It really depends a bit on your company. Like I mentioned, I'm using <a href="/tags/nextjs">Next.js</a> a lot, but in most production apps, I don't actually use the <a href="/tags/backend">backend</a> part of Next that much.

So let's do this again. Now it should be faster. Action five, save changes were redirected back. This is action five. And it shows up correctly here as well. Now, the cool thing is, suppose I disable <a href="/tags/javascript">JavaScript</a>, this will still work. Let's go to the homepage with <a href="/tags/javascript">JavaScript</a> disabled, refresh, make sure that you're not running any stale things. I go to genres, action five. I changed this to action six, save changes. And it's still updated. All of that still works with <a href="/tags/javascript">JavaScript</a> disabled. If I look behind the scenes, if we down here somewhere is a form here. Then here you can see that the form actually has a couple of additional property set, action, encoding type, and the method. So the action is set, but empty, which means it actually posts back to the current URL, encoding that it's form <a href="/tags/data">data</a> and that it should use a post instead of the default get. So if I look at the network, let's click preserve log, I do save changes. We should see that request here. Here we can see that the <a href="/tags/data">data</a> actually being sent and there is redirect being sent. What was it? It turns a 303 redirecting back to the list of genres, which I think is really cool. Something which wasn't possible before. So here's that example, we're going to skip over the exercise because I'm already over time.

React Day Berlin

React Day Berlin 2023

React Server Components Unleashed: A Deep Dive into Next-Gen Web Development

Desatando los Componentes del Servidor React: Una Inmersión Profunda en el Desarrollo Web de la Próxima Generación

React Server Components allow for server-side rendering and improve performance by reducing the code sent to the browser. They enable asynchronous operations on the server, such as database queries, without separate endpoints. Next.js is a suitable server for React Server Components and provides better type safety by directly querying the database. Next.js also offers a router cache that can be controlled to ensure updated data is immediately reflected in the application. React Server Components can be used with Next-specific APIs to update the UI and simplify form handling by eliminating the need for JavaScript on the client.

Get ready to supercharge your web development skills with React Server Components! In this immersive, 3-hour workshop, we'll unlock the full potential of this revolutionary technology and explore how it's transforming the way developers build lightning-fast, efficient web applications. Join us as we delve into the exciting world of React Server Components, which seamlessly blend server-side rendering with client-side interactivity for unparalleled performance and user experience. You'll gain hands-on experience through practical exercises, real-world examples, and expert guidance on how to harness the power of Server Components in your own projects. Throughout the workshop, we'll cover essential topics, including:- Understanding the differences between Server and Client Components- Implementing Server Components to optimize data fetching and reduce JavaScript bundle size- Integrating Server and Client Components for a seamless user experience- Strategies for effectively passing data between components and managing state- Tips and best practices for maximizing the performance benefits of React Server Components

Maurice de Beijer

JS Nation

I’m attending JSNation – the main JavaScript conference of the year. You may join me there for free with 10k other JS engineers and 40+ great speakers. Just follow this badge. 

#javascript

JSNation 2024

C3 Dev Festival

Join me at C3 Dev Fest, a contemporary software engineering festival!

Register to win an all-paid trip to Amsterdam. Elevate your career with industry experts and workshops & rock 3 dance stages at the after-party!

C3 Dev Festival 2024

React Summit

I am attending the biggest #Reactjs conference remotely. You may get a limited free ticket (50% of talks, no workshops) and join me by clicking this badge.

#react #reactjs

React Summit 2024

TechLead Conference

I'm attending TechLead Conference 2024 – get your free remote ticket and join me there

TechLead Conference 2024

React Advanced

React Advanced Conference 2024

Productivity Conference

Productivity Conference 2024

JSNation US

I’m attending JSNation US. Join me there for free with 10k other JS engineers and 50+ great speakers. Just follow this badge.