Introduction to Next.js 13+, v2 Rendering Server Components

Transcript from the "Rendering Server Components" Lesson

[00:00:00]
>> Cuz I just pushed the changes to the code that I was working on up to GitHub, but I'll read it out here. It's just my GitHub, which is Hendricks sir, which is Hendricks with the ER/intro-njs-app. And then I'll just keep pushing my code up to that main branch there as we move along.

[00:00:18] I kinda talked about it before, which was like server components versus server side render. Let's do like a little deeper dive on like, server components themselves. So server components is basically if I have a link here for the RFC, which RFC stands for Request for Comments, they have like a whole video on it and stuff but the actual RFC is like here, which I highly recommend, really because it's It's really good.

[00:00:45] Like if you just go through and scroll through here, what the React team is talking about, for server components, it's quite amazing. I've learned a lot, just from going through there, and experimenting, and seeing what people are talking about. So check that out. But basically server components are components that never leave the server.

[00:01:01] They just don't. So that means there is no JavaScript that gets shipped to the client. This also means I talked about server components not be able to use things like browser API's, but that also means they can't use anything what state so hooks like use state and effects can't use them.

[00:01:18] The server component just won't work because I don't know if anyone has experienced with a What's a synonymous architecture I think Phoenix live view does something like this that's such a nice framework but they do something like this where they stream stuff from the server to the front end To like not having to have so much JavaScript.

[00:01:40] But what they do is they actually keep all the state on the server. So they have like the ability to do like checking and state and stuff on the server and they send it over through a web socket. It's kinda like that here, except for they don't keep state on the server.

[00:01:54] So there is no hooks, there is no ability to do a use effect because those components are re-rendering. All right, if you think about how a hook works, a hook is kind of, it's exactly what it sounds like. It's a hook into the lifecycle of a React component.

[00:02:06] But our server React component doesn't have a lifecycle. It just renders the data and sends the HTML back to streaming. So it doesn't really have an ability to like, this data changed. I need to refresh myself or re-render. There is no re-rendering on the server. That's a client side Approach for react on the server it just happens once and then based on your caching and your revalidating and the segments that you go to it might happen again but it's definitely not keeping track of state and things like that because.

[00:02:38] Yeah, that's just not what it does. So you can't use hooks and things like that. So you basically have to kinda just think about those components a little different. But they do bring benefits, as you'll see in a minute. Some benefits are really cool. They make the component stuff just so much easy to think about, in my opinion cuz it's explicit.

[00:02:59] But yeah, server components versus server side rendering, I talked about a little bit, but Traditional server side rendering is when a component is rendered on the server, and the HTML is basically serial like. So you get the HTML that's rendered from the component. And then all the data that's associated with that component is serialized basically, it's turned into JSON, it's sent along with the components And then it's hydrated on the front end.

[00:03:23] You might have heard that before. These components need to be hydrated. That just means the HTML got put on the screen, and here's all the data for it. So take this data, feed it to the client-side versions of those components so it can be rehydrated back with all that serialized data.

[00:03:39] So if you've ever tried to send something that's not sterilizable, like a date object or a function, you can't serialize a function, you can't serialize a date object. You might get an error in next.js. If you ever tried to pass back a date function inside of a get static props or a get server site props and next.js v12, you would've got an error Because to cross the network threshold, the barrier, it has to be serialized, and date objects can't be serialized.

[00:04:05] So that's how server side rendering works is we're gonna render this thing on the server. We're gonna get back some HTML. The whole request has to finish. Once we're done with all that, we're gonna send it back. And then the frontend is gonna just take over and rerender itself, and now we're in client mode.

[00:04:20] Okay, server components is not that. Server components is We're going to go to the server. We're going to fetch any data that this component needs, whether it's in parallel, whether it's one after each other. And then as the results start to come in, we're going to stream it to the client, that way, the client isn't waiting for the result of this request to come back.

[00:04:41] So therefore the client can proceed to do whatever it wants to do, show other components that have already popped in in different parts like that. So you're gonna start seeing more apps Have this effect where you can think of a dashboard that's got panels and stuff everywhere. Some panels still loading in, others are already here, right?

[00:05:00] Each individual thing has its own loading animation, its own error state that's completely isolated from the rest of that page because they're server components and they're individual. So I think you're gonna start seeing stuff like that, and that's the difference between A server component and server side rendering.

[00:05:16] So when do you use server components? You should just always use them until you need to do some client side stuff. So if you're like making an interactive chart using D three, server component or client component? Probably client component because there's no interactions on the server that Allow you to manipulate the Dom.

[00:05:34] So you still have to use that a form where you have to submit things. Probably a client component because you have to respond to a submit event on a form and do something. A navigation bar probably a server component. It's just a read only navigation bar with links on it.

[00:05:49] Why do you need to render that on the client? That should just load in immediately and everything else should fall in place I think that's why next.js was just like, let's just make everything server appointed by default, to force you to think about it. Like basically, what I found out is I really liked this as a forcing function because you will write the code as a server component.

[00:06:09] And then maybe you're not thinking about or maybe you don't know how it works, or maybe you just don't care. You'll try to do something like a hook or something and you're like it broke and because it broke you can't move on so then that forces you to make it a client component but only that thing right and then you go to the next component and then that's a server component and you just repeat the cycle so you're only forced to fix the thing that broke.

[00:06:31] Because it needed to be a client component only put use client on the things that you need to do, and everything else is a server component. So I kinda like it as a forcing function because it kinda teaches you eventually you'll build this list of like if it's got this, if it's got this, if it's got this This but use client and then that would be your thing but by default it's always a server component any questions on that yes

[00:06:53]
>> it's kind of like what you're mentioning one thing I was I noticed was. Yet when we first were using the link component itself, we didn't have the use client.
>> Right.
>> So there's a link component then that's a client component that has that like the use client, presumably at the top of that.

[00:07:07]
>> Yes, exactly. And that brings me to another point that I think I haven't heard somewhere. I have here. Yeah, so like, using third party libraries, like a lot of every third party library ever and react does not adopt this strategy yet. So unless they just made it in the last, I don't know.

[00:07:24] These are just very proactive mo maintainers and they're looking at all the React RFCs. They probably haven't added used client to the top of their, component lip. Like for instance, one component lip that I love to use is chaker ui, right? I love this one and I was gonna use it for one of the courses.

[00:07:38] Then I went on here and I was like, I want to use this for next year. Yes. And it immediately says, you can't, you can't use it for next year I start saying unless you put us client because it doesn't work outside of the client. So you're gonna see a lot of this, you're gonna see a lot of lives and libraries not working out of the box because they haven't gone in and made them Work for React 18 and beyond, so you have to wrap them in your own useClientComponent first as a proxy so you can import them in your server components.

[00:08:09] Yeah. I'm trying to formulate this question, right? Like, having been through the various state management stages of React, from props drilling to Redux, to Redux with hooks, to abusing context, Still using use context and on, like anecdotally. How many of you seen, I guess first kind of islands architecture that they're discussing as implemented in Next?

[00:08:36] And then maybe they use client directed, how have you seen those changing? Kind of the unidirectional tree model Ways of hosting and sharing state.
>> Yeah, I think that's still gonna remain but only for the client side land I think they've zoomed out a little more and I, And they were before we even get there, we need to figure out so there's the React team, the next JS team and the the Google Chrome team are working very closely together to figure out how to create an optimum framework for the browser.

[00:09:10]
>> And I think they've landed on the fact that, like, how do we send less JavaScript to the browser, right? And I think React's like, well, we'll make it a framework-level support. Next.js is like, we'll make it easier for people to do. And Chrome's like, we'll probably make it easier for them to debug or something, right?

[00:09:25] So, I think them zooming out is like, okay, on the client level, we still have this whole state thing and figuring out when state changes and how to keep track of that state. But now it's more of on a network layer, a data layer. It's like, well, how do we even know what components to even send to the browser in the first place?

[00:09:42] And that comes down to. Keep in track of the things that you're trying to get whether it's from an APR, whether it's from a database, whether it's from a file system. And what is your intention on that data? Should it be re validated, should it be dynamic? Always and never cashed, what is the cashing strategy and I think that's gonna determine,

[00:10:03]
>> How things get rendered. They're basically making it a data first rendering approach before it even gets to the client. And then when it gets to the client, you're back to wherever you were before. So I think that's just them zooming out on that layer. How things get rendered.

[00:10:15] They're basically making it a data first rendering approach before it even gets to the client. And then when it gets to the client, you're back to wherever you were before. So I think that's just them zooming out on that layer. So This is their approach, so yeah. It's just a refocus, I think, on the data in the network and not so much on the state itself.