Original subtitles

So we've been creating routes and pages,

and I've mentioned that we're using something

called React Server Components,

but actually we have no idea what those are right now.

Now React Server Components are by far the biggest

and hottest topic in React right now

and will probably be for a long time.

And so let's now dive really deep into this new paradigm.

And I've divided this lecture into multiple parts.

So in this first part we'll learn

what React Server Components are,

and then later on we're going to learn

how they actually work behind the scenes

and how React Server Components compare

to server-side rendering.

So this is gonna be a long ride,

similar to the behind-the-scenes section

earlier in the course.

And so let's get started.

And let's actually start by asking the question,

why do we need something like server components

in the first place?

Well, to answer that question,

let's go back to the very beginning of the course

where we discussed that in React applications,

we can imagine the UI as being a function

of state changing over time.

So in a typical 100% client-side rendered React app,

as we keep updating state, the app simply keeps re rendering

and showing different parts of the UI and layout.

So that's what we mean by UI is a function of state.

Now, we do hack this idea a little bit

by also storing fetch data in state,

but more about data in a moment.

But anyway, this approach is great for users

because apps are super interactive

and it's great for us developers too

because it lets us write all this interactivity

inside these small, reusable

and composable packages that we call components.

But of course there are also downsides

to 100% client-side rendered apps,

and we already discussed some of them,

but here I just want to focus on two facts.

First, React apps require a lot of JavaScript

to be downloaded to the user's computer,

which can have huge impacts on performance

and is always a constraint for us developers

that we have to constantly think about

when we're building our apps.

And second, our client-server waterfalls.

And a client-server waterfall is a problem

that happens when multiple components on a page

need to fetch different data one after another.

So when data from one component depends on the data fetched

in another component,

this is a very common problem in large applications,

caused by the fact that we have to fetch data

on the client when we have a 100% client-side app.

Now the alternative it seems

is to have a 100% server-side rendered app

like we used to have in the good old days of PHP.

And maybe you're old enough to remember

that back then we had no interactivity

and no components at all.

What we did have was an easy

and fast way to fetch data directly from the data source,

for example, from a database.

Therefore there was no need to build an API to communicate

between frontend and backend,

because we were always on the backend anyway.

And for displaying all this data,

no JavaScript was needed at all,

meaning faster page load for our users.

So in this case, we could say that the UI

was not at all a function of state, but of data.

So in this approach, it's really the data

that determines the content of the UI.

And this actually also sounds great.

It makes a lot of sense that data is at the center

of generating pages,

but the same is also true for state.

It also makes sense for state to determine the UI

as we just saw earlier.

So both are completely valid approaches.

So what do we do then with all this information?

How do we achieve a UI that's a function both of state

and of data, which is much closer

to what real-world applications actually look like?

Or in other words, what if this whole diagram didn't have

to be so black and white, or in this case actually,

so blue and yellow,

what if there could be more of a gradient,

something in between that's not 100% client

or server-side, something that would give us

all the advantages of both client-side and server-side.

So what we're really asking here is this.

What if we could take the best

of both worlds having React components both on the server

and on the client,

and therefore being able to be either interactive

or to be close to the data source

and ship no JavaScript at all?

Well, the answer to all this

is a completely new React paradigm,

a completely new way of building React apps

that changes everything

and it's called React Server Components.

But what are React Server Components?

Well, let's find out.

Now before we even start this conversation,

let me clarify that we're back to learning

pure React in this lecture.

So for now, please just forget about Next.js

and server-side rendering.

Don't even think about them for now.

We're gonna bring all these concepts back together

in the future, but for now,

let's remember that we're just talking about React itself.

So with that out of the way,

React Server Components is a completely new

full-stack architecture for building React apps.

It introduces the server

as a first class citizen in React apps,

which means that the server is now an integral part

of the React componentries of our applications.

Or in other words, the Reactory now extends all the way

to the server, like a bridge that closes the gap

between client and server.

And the way in which React does that

is by introducing a new kind of component

which are server components.

Now this is already starting to become confusing,

and so let's clear that confusion right away.

The term React Server Components,

which you'll often see abbreviated as RSC,

is the name of this whole new paradigm,

so, this new architecture.

The term server component alone is then the name

of the new type of component that RSC introduces.

And these are components

that are only rendered on the server, never on the client.

They're usually responsible

for fetching data right on the server.

And so to use the idea of the previous slide,

their goal is to make part of the UI a function of the data

that powers the application.

Now, since server components run only on the server,

they have no interactivity, so no state,

which means that they require exactly zero JavaScript

in the downloadable bundle to do their job.

And this is one of the main advantages of this model

as we'll see later.

So if we think about this, with server components,

we can essentially build our application's backend

also with React, which is pretty amazing.

Now, besides server components,

of course we still have our old regular components

that we already know and that run entirely on the client.

Therefore these are called client components

and they are responsible for the interactivity.

So for the part of the app where the UI

is still a function of state, so together,

client and server components allow us

to write frontend code,

right next to backend code

in a way that feels completely natural

because it feels just like the regular React apps

that we've been building so far,

we're still using just components

and can even compose server

and client components together to build full-stack apps

that are really entirely controlled by React.

Now here is one very important thing

to understand about all this.

React Server Components are not active

by default in new React apps.

So for example,

if we just start a new React project in Vite

like we did earlier, we will not get this architecture.

And this makes sense

because there is no server involved

in a Vite application.

So the server needs to be somewhere,

it needs to be integrated into this whole idea.

And so that's where full-stack frameworks like Next.js

or Remix finally come into the picture again.

So basically, React provides this architecture

and frameworks can then choose to adopt

and to implement it if they want.

And that's exactly what Next.js did in the app router.

So any app that we built in the Next.js app folder

will use this new RSC architecture

in which server components

become the default components actually.

So again,

server components are now the new default components

in this new model.

Client components then basically become opt in,

so we need to specifically tell a component

that it should be a client component if that's what we need.

And we do so by using the new use client directive

at the top of the module

that contains the component definition.

Now, okay, so this is probably a lot of new stuff to absorb.

And so let's look at an example

to make this a bit more practical.

So let's divide this UI from the Wild Oasis app into client

and server components so that we understand the difference

between them just a bit better.

So on a high level we have this sidebar, header,

and the main area.

Now none of these are interactive,

so we can't really click on them

or at least they won't do anything if we do so.

I mean we can of course click on some elements

that are inside of them, but the sidebar, header

and main elements themselves are not interactive at all.

This means that they can be rendered on the server

as server components,

so without shipping any JavaScript to the browser.

Okay, so let's build ourselves a componentry out of this,

starting with the generic app on the top

and then our three server components in yellow.

All right, so let's keep going

and look for a few more server components.

So right in the header we have this Avatar,

which has a photo and a name.

And this component is also not interactive

and its data needed to be fetched from somewhere,

which means that this is another great candidate

for a server component because in this new model,

whenever possible,

data should be fetched right on the server

for the first render to be faster

and to avoid client-server waterfalls.

And so again,

that's why this one should probably be a server component.

And the same applies to this table here,

which is also not interactive

and is probably responsible for fetching all the cabin data

and rendering it,

also using this other server component CabinRow.

All right, but here comes the interesting part

where we now look for client components.

And remember that client components are the ones

that need interactivity.

So they need JavaScript in the browser in order to work.

So they are the React components that we already know.

And starting again in the header,

we have this DarkMode toggle that we can click,

and therefore this one cannot be rendered on the server.

It needs to be a client component.

And the same happens with the filter

and the SortBy components.

The user actually needs to interact with these

in order to make them work.

And so once again, they cannot be rendered on the server.

Now we're already starting to see

that our component tree now contains backend code

as well as frontend code, all mixed together

and all controlled by React

with the client components usually appearing

at the end of the tree, so as the last children.

But let's keep going,

because it's about to get even more interesting.

So right inside the CabinRow we have these three dots

as a Menu, which if clicked,

will then reveal the three buttons for different operations.

Now remember how we need to opt into client components

by using the use client directive at the top of the file.

So that's necessary here in Menu,

and also in DarkMode and SortBy,

but notably not in the child components of Menu.

So what this means is that child components of components

that are already client components

don't need to specify use client again,

the reason for that is that these children

are already inside the so-called server-client boundary.

And this boundary is another super important concept

in the RSC architecture.

So React Server Components is all about boundaries

because they are what marks the split points between code

that runs on the server and code that runs on the client.

So basically we use, use client,

in order to create these client-server boundaries,

which in turn will create client sub-trees.

So sub-trees that will only be executed in the browser

and technically SortBy and DarkMode are also sub-trees,

but just very small ones.

All right, so this practical example should give us

a pretty good overview of what client

and server components are and when to use each one of them.

But now let's actually dive even deeper

and compare these two types of components

in a more structured way.

So to start,

server components are the default components

in the RSC model.

While we need to opt into client components

by writing use client at the top of the module.

Now, since client components are the interactive ones,

only they can have state and use other hooks.

Server components cannot be stateful

and in fact they can't use any hooks whatsoever.

It's pretty interesting why that is

and we'll learn all about that in one of the next lectures

where we look behind the scenes of React Server Components.

Another important concept we learned about

is lifting state up,

which is of course not even applicable

in server components since they cannot have state.

Moving on to props now,

we can pass props in server components

just like in regular components

and we can do so between two server components

and also from server to client components,

which is the extremely important way

of passing data across the client-server boundary.

There's just one small thing that we need to keep in mind

in that scenario,

which is the fact that props must be serializable.

So they must be convertible to a format

that can easily be transferred.

Functions and classes are examples of data structures

that are not serializable,

and so we cannot pass those as props from server

to client components.

Now when it comes to data fetching,

as we just learned previously,

the preferred way of doing so is in server components.

They are now the native,

first-class way of fetching data in React.

In fact, we can simply use async await

right in the top-level code of a server component,

which is something that won't work in client components.

If we then need to make that data available to the client,

we can just pass it as props as we saw a moment ago.

Of course, we can also still fetch data in client components

just like before,

and preferably do so with a third party library

like React Query.

So just because we have server components now,

doesn't mean that something like React Query

is now completely obsolete.

Next up, let's talk about what kind of component

can be imported by each type of component.

And here we need to actually distinguish between importing

and rendering.

So with import, we mean that the component module

imports another module using the import syntax.

On the other hand, with render,

what we mean is that one component calls another one,

so it uses another component inside its own JSX body.

So keep that distinction in mind

as it will be pretty important later on.

But anyway,

as we already noticed in the tree from the previous slide,

several components can import both client

and server components.

And by the way, that tree was technically an import tree,

so modules importing each other.

Now, client components however

can only import other client components

but not server components.

Once the client-server boundary has been passed,

there is no way of going back to the server again,

what is possible though is for client components

to render server components,

as long as these have been passed to them as props.

And this is indeed extremely confusing.

So I don't want to go into further detail here

because we'll discuss this a bit better later.

So here I just wanted to summarize everything.

All right, but back to server components,

they can also render everything.

And now finally,

one extremely important question is,

when does this component type re-render?

Well for client components it's very simple.

It's whenever its own state or a parent state changes.

So we've been using that idea

throughout the entire course.

But what about server components? They have no state.

So do they ever get re-rendered?

Well, as it turns out, the answer is yes,

server components are executed again

each time that the URL changes,

so when the user navigates to the URL

that has the server component in question,

that's because usually server components are tied

to specific routes in the framework,

so in our case, Next.js.

So when the URL changes

and the framework moves to another route,

all server components associated with that route re-render,

so they are executed again and might even fetch data again.

All right, so keep this summary handy as you start working

with server components in the future

because I belief it might be quite helpful.

What's also gonna be helpful is to now get a mental model

for how the RSC paradigm is different

from traditional React,

based on everything we learned so far.

And let's start by looking at a simple mental model

of traditional React on a very high level,

which you should already be 100% familiar with

at this point.

So basically it all comes down

to components which together display a view,

so, a user interface.

Now as the user interacts with this interface,

for example by clicking a button,

that interaction will update state,

which in turn will re-render the components

and display a new updated view.

Components can also fetch data

and store that data in state,

which then again updates the view as the data changes.

So this is nothing new, right?

But now let's see how React

with React Server Components enhances this model,

how it gives this model an outer layer

and makes it slightly more complex

but still very manageable.

So the core

of the mental model we just talked about

actually remains completely unchanged.

All this is still valid in the RSC world

with the only difference being

that our regular components are now called

client components.

Now on top of client components,

we now also have server components

that run exclusively on the server

but also participate in displaying their view.

Now just to make sure we're all on the same page,

this diagram is not about how React Server Components works

behind the scenes.

That's for a later lecture.

Here, we're just trying to build up a model in our minds

that will help us make sense of this new paradigm,

so, to understand what it does

and how we use it in practice.

But anyway, back to our server components,

these are now the primary way of fetching data.

This data can then be rendered directly

and displayed in the view,

or it can be passed as props to client components.

So server

and client components are essentially connected by props.

They are like the bridge

across the client-server boundary.

Okay, and now to finish this model, we just need to consider

how server components re-render,

which we already learned about in the previous slide.

So as the user navigates around the page,

the URL will be updated,

which will then re-render the server component.

This usually triggers fetching the data again,

and therefore displaying an updated view with the new data.

So in summary, in this new world,

we have not only client components that re-render

and display updated views,

but also server components that re-render

and display updated views as well.

So we have two types of components that contribute

to the same view,

but by using different mechanisms.

One type of component runs on the client

and one on the server,

and they can even be connected by props.

And it's important to mention that one type

of component is not better than the other one.

They just have different purposes, but are both an important

and integral part of this new model.

Now, right.

And now to finish this long lecture,

which we're almost done with,

let's just quickly look at the pros

and cons of the RSC architecture

as a kind of summary of this video.

So in my opinion,

the biggest selling point of the RSC model

is that we can now write React components on the frontend

and on the backend,

meaning that we can now encapsulate

all server-side concerns right into components as well.

And by doing so,

we can compose entire full-stack applications

by only writing components,

plus actually something called server actions for mutations,

which we'll learn more about by the end of the course.

And this just feels extremely natural

and it also allows us to have just one single code base

for the frontend and backend of our app.

Also, we don't even have to build an API

in order to access our data on the frontend

in many situations,

our server components are already on the backend,

so they have a direct access to the data source.

For example, we can directly grab some data from a database

right in a server component

and then simply send the already rendered page

to the browser,

so instead of sending only the data as JSON.

Plus, if we need to access a third party API,

we no longer need to worry

about securely storing our API keys,

which is always a problem in a pure client-side app.

And staying on the topic of fetching data,

doing so in server components

can eliminate all kinds of client-server waterfalls,

which is again, a huge win for performance.

So instead of fetching one piece of data

after another in different client components in the browser,

we can just fetch all the data

that we need on the server at once,

and then send or stream the final result

to the browser all in one go.

Now server components don't require sending any JavaScript

to the browser because that's not where they are executed,

and we can call this disappearing code,

because this fact allows us to import

and use huge libraries in server components

without increasing the bundle size at all,

so basically for free.

This is great for libraries

that we really only need for rendering data,

like libraries to connect your app to a CMS,

embedding things like tweets, syntax highlighting and so on.

So this is another win for performance,

and therefore for the user experience,

which is definitely a theme in all these RSC props.

But now let's move on to some bad parts

because they always exist in any technology as well.

So first of all, it's undeniable that introducing RSC

makes React a lot more complex.

It's still manageable,

but there are definitely more things to learn

and to understand now.

But luckily for you, you have this course,

where I try to make it all as easy to understand as possible

for you not only in this lecture

but in some future ones as well.

Then once we understand server components,

using them is actually pretty easy

and natural in practice, they have no state or effects,

no stale closures or memorization-like client components,

and therefore they're actually pretty easy to reason about.

At some point we completely forget

that we're even working on the server in some components.

Now, some more practical cons are the fact

that APIs like the context API

don't work on server components just like all other hooks.

And also that we need to make more decisions all the time.

Things like should this be a client or a server component?

Should I fetch this data on the server

or on the client and so on.

This again, comes from the added complexity

of this architecture,

but I believe it's still a good trade-off.

Also, if on top of a web app, you also need a mobile app,

you'll probably still need to build an API,

even if you don't need one for the web application

where you can just get data directly from the data source

in server components.

But if you're at that level,

you're probably working in a larger team anyway,

and then that should be no big deal.

And finally, one thing that many people don't like

about React Server Components

is the fact that they can only be implemented

and used within a framework.

So you cannot just set up a Vite app

and implement RSC yourself.

I mean, you actually could in theory,

but it's just so complex

and would be so much work that no one will do that.

And as a consequence,

you always have to buy into a framework

if you want to use the power of server components.

But in any case, in my own personal opinion,

I think server components are awesome

and definitely worth it no matter how many cons there are.

So the good parts absolutely outweigh the bad parts,

and I'm really happy that React went this way.

And now after all this talk, let's go back to our project

and explore this with actual code.