Transcript >> DAN: hi my name is Dan Abramov and I'm
a software engineer on the React Core team at Facebook and later today I will be joined by
Lauren Tan who's my colleague on the React Data team and together we will present an update on
our teams' research into data fetching in React when I just got into software development I
heard about this principle that you can make something good you can make something cheap or
you can make something fast but you can only pick two so which two do you pick do you pick something
good and something fast but it's not cheap to make or do you pick something that is cheap to make
and fast but you know that it's not very good or would you rather go for something
that's really good and that's cheap but takes a very long time to make and so
this principle is about project management but I want to stretch it a little
bit and apply it to UI development so what I want in UI development is I
want to have a good user experience so I want to create products that are pleasant
to use and I want them to be cheap to maintain and of course I want them to be fast and
these three things are at odds with each other so let's see an example so for an example of a
good user experience I'm going to use my favorite app this is Spotify I love the way it's made
it's it has so many small design touches that are very nice um and I'm going to imagine that I'm
re-implementing Spotify which is not realistic but if I were to try to make a mockup I would
maybe structure my components like this so there's the artist page component
and there is some kind of a wrapper for the entire page that maybe like it shows
the cover and some details and then it has a content area and in the content area I put
two components top tracks and the discography and it's interesting if you look at the way
Spotify actually works if you try to click around you'll notice that if you click on an artist you
never see discography appearing on its own and then getting pushed down by top tracks and then
finally gets wrapped into this like artist details page um all of those things appear at the same
time and this is not a universal so rule of course there are cases in user interfaces where you want
things to appear step by step but you still want it to be intentionally designed and not something
that just happens in random order according to how the network responds so that's if if
we want a data fetching solution that satisfies these constraints that's the part
that we care about in the user experience but you also want the code to be easy to maintain
and cheap to maintain and in case of data fetching and the way I would look at this is before I have
data fetching if I'm just mocking up my app with some static data from json I might start like
this but then I have to add that data fetching and I end up with something like this and it
doesn't matter what library I use — it could be just fetch and useEffect, it could be redux, it
could be something else — but essentially I need to get some data in some place and I need to pass
it down and clearly there is nothing wrong about it — this is the way React works and it works
just fine — but for data fetching I kind of see a problem here where the API response becomes
very coupled to my components so for example if I later remove top tracks from the screen entirely I
might forget to remove it from the API response so I will be transferring all this unnecessary
data there or if I maybe add a field and use it in in one of the components but then I forget
to update another API endpoint under which that component also appears and so i'll have a crash
there so there are all these subtle things about tying your API with the components that use it and
really conceptually I want to write code like this I want to go back to this so I
want to have separate components and somehow each of those components determines
what data it needs and gets it from somewhere — and I don't mean that every component needs to
read its own data — but I do want to have a way to specify for some large blocks of the screen
where where do they get the data from without tying it back to the very root and passing
it through context and and all that jazz so I want my code to look like this and finally I want my code to be fast and it turns
out that this is not fast and the reason it's not fast is because let's just see the order in which
this code executes so we have these ArtistDetails does a fetch a fetch takes a while then the fetch
comes back and we go into TopTracks which also does a fetch because we we made each component
responsible for its own data fetching so TopTracks doesn't even start fetching top tracks until after
ArtistDetails has rendered it instead of like a spinner so this is called the network waterfall
because it goes like this like it goes in stages and to illustrate the problem more clearly i'll
just use a graphic so here's a server and client we have a parent and the child component
on the client because that's where React is make a request for the server it might take a
long time request comes back make another request and it comes back and the problem is all
this time we've wasted that we could have simply fired both requests at the same time
but because of how we structured the code that was not possible and so with this
approach we don't have fast performance we can compromise on something else so we can
compromise on the maintenance and go back to fetching all the stuff at the top which solves the
performance problem now we don't have a waterfall but now the components are not responsible
for their own data requirements we could also compromise on user experience
so we could decide that we're going back to each component fetching its own data and then
when we go to the artist page we might see discography first and then the artist details
wraps it and then top tracks pushes us down but it's just not a good user experience
so we've really compromised it and so maybe we can't have all three but
no this this doesn't make sense it's it's not a mathematical principle it's not a rule
it's just a way to think about constraints and of course it doesn't reflect all the all the
complexity and all the hidden variables and in fact we know that the problem does have a solution
because we've already solved it before and at Facebook we use to solve this problem
we use the combination of Relay and GraphQL so the way we do that is each component that
wants some data specifies which data it needs through a GraphQL fragment and then Relay is
this thing that composes those fragments together so that when we talk to the server to
navigate to a new screen we only get we get all of them in one go instead of going
back and forth like we have with a waterfall and so now we have a question if we want
to improve the performance of React apps across the ecosystem do we just
use GraphQL and Relay everywhere and I think it's clear that no this doesn't
make sense and it's not because they're bad we love using them they make a
lot of sense for Facebook products but they don't make sense in all cases there's
so many different cases and for example if you just starting and you write in your small hobby
apps unless you're specifically interested in GraphQL it probably doesn't make sense to have to
have a GraphQL back-end for your app to be fast um and similarly even in large companies
you um not everyone wants to adopt GraphQL you might have a lot of legacy backends it
might be a huge project to expose a GraphQL endpoint and maybe you just don't like GraphQL
and that's also okay, it's a technology, it's not necessarily for every use case and so we
had to go back to the drawing board and think can we come up with a solution that would address
the majority of needs in the React ecosystem let's take another look at this graphic so the
problem is that we have a waterfall but the reason the problem is so bad is because there is high
latency between the client and the server so one way to solve the problem is to fix the waterfall
as GraphQL does but there is also another solution which is to move our components to the server
so what happens in this case is that the client makes a request our parent component is on the
server so you can talk to the backend real fast render the child component which also talks
to the backend real fast and send the response wait did I say move React components to the server how do you even do that well
that's what we've been researching and these are regular React components still
but we're going to call them Server Components because they execute on the server and on the
server only they're never shipped to the client and we originally thought of Server Components as
a way to solve the waterfall problem however we found that they also solve many other problems
that we've been wanting to solve for a while and I want to be clear that Server Components are
not something that we're adding to React today but it's something that we want to introduce to React
and we want to share our research with the React community so that the development is transparent
and so to give you an idea of what it actually feels like to build an app with Server Components
I would like to invite Lauren Tan. Lauren? >> LAUREN: thanks Dan my name is Lauren Tan
and I'm an engineer on the React Data team over the past week we've been building a demo
application to showcase what Server Components are so let's get started the demo application we're
building is called React Notes it's a full stack application that's backed by a database and as
you can see i've already populated our database with some notes right now our application
doesn't do a whole lot but I did want to show you two components before we started adding
functionality the first component is App.server.js I've given this component the .server.js extension
to tell React that this is a Server Component Server Components are a new type of
component that we're introducing to React and this tells React that we only want
this component to ever render on the server at the moment our Server Component doesn't do much but it does import the NotesList component
which is a Client Component Client Components are not a new type of component these are
regular components that we've just given the .client.js extension to tell React that we
want this component to only render on the client in our Client Component we're
importing the fetch function from the react-fetch library react-fetch
is a thin wrapper around the fetch API and we're using this to fetch our
list of notes from our backend what's really interesting about this
fetch API is that it works as if it was synchronous so you don't have to wrap
it in an effect or anything like that now let's take a look at the rest of our
component at the moment it doesn't really do much it's just mapping over our our list of
notes and then rendering that into our sidebar so this component doesn't have any interactivity
and it does have a data requirement so this could be a really great candidate
to be a Server Component so let's do that all right so i've converted this to a Server
Component so now I'm telling React that I only want this component to render on the server but
I'm still using the fetch API and it's really neat because the fetch API works on both the server and
the client so I don't have to change any code here but you might also be wondering if we're
already rendering this component on the server why am I fetching the notes from the server again
well this fetch is happening on the server so in practice this is going to be really fast and
it's going to be much faster than fetching our data from the client so let's take a look at
our UI now and refresh the page and you can see that I've converted the sidebar to a Server
Component and it's still working as I expect all right so we've converted the sidebar to be a
Server Component but one thing that I don't like is this timestamp we're rendering it as
a raw string and it looks really ugly in our NoteList Server Component
I've extracted each list item into a new component called the SidebarNote component in the SidebarNote component I'm importing two
functions from the date functions library which is a utility library for formatting dates and then
I'm using those two functions to format the date if it's today then I want to show the time that it
was last updated at and if it wasn't edited today then I want to show the date as a month date and
year string and for those of you who are not in America I apologize for this abomination
the rest of the world uses date month and year so I apologize for this travesty but
at the moment this component really isn't very exciting but I did want to draw your attention
to the date functions library that i've imported as you can see this library is about 21.2
kilobytes uncompressed and it's about 5.9 kilobytes when it's gzipped so it's actually
a pretty heavy dependency just for formatting a date but let's look at an interesting property
of Server Components we've refreshed the page and now we can see our formatted date I'm going to
pop into the Sources tab in the Chrome DevTools and I wanted to show you what webpack
has built to render this application so when we pop open the src folder in the
webpack source I can see that none of the Server Components that I've defined so far
have been included in the client bundle and what's even more exciting is that the date
functions library that I used which was about 21 kilobytes and about 6 kilobytes when it
was gzipped is nowhere to be seen in our client bundle and that's really powerful because
I no longer have to make my user pay the cost of downloading dependencies that are really only ever
going to be used once and then never used again okay our sidebar looks a lot better but I also
want to add some interactivity each of our notes has a content so I want to be able to click on
one of these items and then see a preview of the contents of the note so let's go ahead and
do that as a quick reminder the SidebarNote component here is a the component that we're
using to render the list item within the sidebar as you can see I brought in a lot more external
dependencies now which are pretty large but fortunately this component renders on the server
so that's great now I want to talk about one constraint of Server Components and that is that
Server Components cannot have any interactivity so that means that we can't do things like use
state or event listeners and because we're going to toggle whether or not the list item is
expanded we need to do that on the client so that it can be interactive fortunately
Server Components can import Client Components which can have interactivity so I just need to
make sure that I put all of my interactive logic into the Client Component I'm not actually
going to show you the Client Component right now because it's fairly straightforward I'm
using state and if the Client Component is expanded then I'm going to show a prop and
if it's not expanded I'm going to hide it so let's go look at our Server Component again I've used the Client Component here but I'm
also passing props to that Client Component from the Server Component and this is really neat
because Client Components can receive more or less any of the kind of props that you might
expect that you can pass to a component with a few exceptions and the key thing to
note here is that we can only pass props to a Client Component from a Server Component
if that prop is serializable over the network so for example if we were serializing to JSON
that means that we can only use values that can be encoded into JSON so as an example if I pass
in a function here and I call it like fun I guess in this case React would throw an error because
this is a function and it cannot serialize that function over the network and the Client Component
would actually not be able to use this function at all but props that are serializable
are totally fine and JSX is serializable one interesting thing about using
JSX within a Server Component as a prop to a Client Component is that the JSX
will be rendered by the Server Component before it gets to the client so
what exactly do I mean by that so as you can see here I've highlighted what I'm
passing to the Client Component as children and at the moment this is just JSX but what happens if I
extracted this into a new component what would get sent as a prop instead so let's create a new file
and I'm going to call this the SidebarNoteHeader I'm going to export the function and this function is going to take a
prop which is the note and I'm going to return the JSX that I used here I'm also going to need the logic that I use for
formatting the date so let's grab that as well let's grab the oops the imports as well so
I'm going to need the date functions to import and this looks good I have the formatted
date and I have my date functions and so this should be totally good now
so let's clean up our sidebar component and I'm going to import that
component that I just created and instead of passing the JSX this
time I'm going to pass the component with the note as a prop so we can look up the date so what I meant by that that Server Components
pass rendered props to Client Components is that the thing that gets passed over the
network isn't going to be this Server Component like that looks like this instead we're going
to pass the JSX that's fully rendered already so that means that the this instead of having
lastUpdatedAt this would already have the value in the JSX when we send it to the client so
now if I refresh the page you can see that our sidebar is interactive and if I pop
open the sources tab really quickly we can also see that we did not download the
sidebar note header component we only download the SidebarNote.client component which we
needed for the is expanded interactivity all right now that we have the ability
to expand a note so that we can get a sneak preview of its content I also want
the ability to click on a note so that I can see the entire note's contents being
rendered into the preview on the right as a quick reminder the sidebar note Client
Component is the component that's responsible for the interactivity in our sidebar so when
we click on that button we want the ability to somehow tell our server to re-render the
component tree the Server Component tree with but this time with the selected note
rendered into the preview so how do we do that in our demo application we do that through
setting something known as a location now a location is not a new React concept this
is just something custom that we've set up so that our infrastructure can refresh the Server
Component tree in our demo what happens when we set a location is we set this in context and our
routing infrastructure is watching that context and if that context value changes we refetch the
Server Component tree with those properties being passed to the server when the server receives
those props we will re-render the Server Component tree starting from the root and in this case it's
in our case it's the application Server Component but this time when we re-render this component
we're going to get a selected id now we're going to pass that selected id to our Note component
which is also being rendered on the server in our Note Server Component if we receive a
selected id we're going to fetch that from our API and then render that in the preview pane all
right so let me click on a note really quickly and show you that it is really performing a server
request to re-render the Server Component tree as you can see we're refreshing
the Server Component tree now I want to pause here really quickly and
talk about server side rendering for a moment if you're familiar with server-side rendering
or also known as SSR SSR is where you take your client-side application javascript and then you
run that on the server and render that into HTML the benefit of doing this is that you can serve
that HTML to your client really quickly and your client can see something happening while
the javascript is still downloading but Server Components are different so let's
see what we mean by that if you recall when we we have the ability to expand a note
and we can get a sneak preview of its contents and we're storing this all in a Client
Component so this is client-side state but Server Components are different from
SSR so that means when I click on a note the client side state is never blown
away it's always preserved and this is a really great property of Server Components that
is quite different from server-side rendering and the reason why we can do this
with Server Components is because Server Components don't render to HTML they render
into a special format now I did say I did compare Server Components with SSR but I don't mean that
they are they can't be used together in fact server side rendering and Server Components
are actually complementary and you can use both technologies together but again Server
Components are really interesting because we are able to preserve the client-side state
even when we re-fetch the Server Component tree okay we can view a note but I wanted to show
you an additional property of Server Components before we continue adding more functionality so in
the Note Server Component which is the component that's responsible for rendering the contents
of the note in the preview I've swapped out the implementation so now we're going to read the body
from a file instead of reading it from our API and in order to do that i've imported a
function from the react-fs library and just like react-fetch the react-fs library is
a thin wrapper around the Node.js fs module so now let's edit a note I'm going to hit save and then click on the note
and you can see that we're now rendering the contents of the note from our markdown file that's
local to my file system so this might really come in useful if for example I was building a blog
or something else that requires a lot of static content okay so we can edit a note in our
editor but it's not really a great experience and I want to have that edit functionality
exposed in our UI instead so i've already added the ability to edit a note so let's take a
quick look at the UI before I show you the code so this is our NoteEditor component and
as you can see it has two major pieces the first of which is a form where we can type in
our title for the note as well as the body for the note and then on the right we have a preview of
the note after it's been rendered into markdown now I want to talk about something that I've
shown you but I haven't really talked about before so in the Note Server Component and let me go
back to the UI really quickly just to show you so in the in the preview for a note when we click
on it the component that's rendering this markdown is the NotePreview component and we're importing
it in this component but you'll notice something interesting about this component and that is
that it does not have a .client.js or .server.js extension it only has a .js extension so what this
means is that we're telling React that this is a Shared Component. Shared Components can render on
the server or on the client and whether or not it renders on the server or client is determined by
what kind of component is importing the component so in this case this is a Server Component
so we're going to render this on the server and the note preview component will
not be downloaded on the client bundle but we're also going to use the same
exact component in our Client Component the NoteEditor Client Component and as I mentioned
because this is a Client Component we're going to render this on the client so what exactly does
this mean now here's a really interesting property of Shared Components and I'm going to refresh the
page so watch what happens when I click on a note you'll see that we downloaded the
EditButton which is a Client Component but the NotePreview component is nowhere
to be found because it was being rendered on the server but when we click on edit we're
now in the NoteEditor component and we do have a requirement for the or dependency of the
NotePreview component on the client so we have downloaded this component on demand and that's
a really great property of Shared Components and as you might expect if I
paste in some markdown here the NotePreview component is fully interactive
because this is not being rendered on the server this is going to be rendered on the client so let's add our last piece of functionality
to our application and that's going to be the ability to search for a note by title so what I
want to happen is whenever I type a title in the input in the search bar I want this list of notes
to update accordingly just to refresh your memory we are implementing this sidebar with this
NoteList Server Component and at the moment we are fetching our notes through this API call
but my good friend and colleague Dan has just told me that he forgot to add the ability to search
in our API so I'm going to need to improvise fortunately for me I know SQL so I'm going
to copy paste the SQL query that I pasted that I prepared earlier and use this to implement
my search I do want to say that if this was a real application I wouldn't recommend writing
raw SQL in your Server Component there are far safer ways of providing data abstraction
layers so that you have a secure and privacy safe way of accessing data but I wanted to show
you this query because I think it illustrates that you know Server Components you have the full
the full power of the server at your disposal so because it's a demo let's just use that power but
there's also another interesting thing I wanted to highlight and that is that this is only the only
shockingly this is the only thing I need to do to enable search so that probably sounds kind
of ridiculous so let me actually show you all right so I've refreshed the page so watch
what happens when I search I didn't keep track of any state I don't have um local state
management or client state happening this is all just being server rendered but you know this is
actually not even the most interesting part here here's another really interesting thing
that I want to show you so if you remember we implemented the ability to expand a note by
clicking on it so we can see a sneak preview and this is all stored in client-side state
now watch what happens when I create a new note components and I'm going to call it 2 and this
is a brand new note and I'm going to save it you'll see that we re-rendered the sidebar
component the whole sidebar component on the server but the client-side state as I mentioned
from a little bit ago is still expanded and that's really great and in fact
if I go ahead and delete this note this note is going to stay expanded as
well okay we're done adding functionality to this application so let's add a final
bit of polish before we wrap up the demo now we've used a lot of Server Components in this
application so you might be wondering what happens to the user experience if the server is really far
away or if my user has a not really great internet so let's see what we can do I've added a
Suspense boundary around our Note component and just to refresh your memory our Note component
is responsible for rendering the contents of the note onto the preview pane on the right our Note
component I've added an artificial delay through this fetch call and this fetch call doesn't do
anything but as I mentioned it adds about three seconds delay just to show you what happens if
the response takes a while to get to the client so I'm going to open the network tab really
quickly and then I'm going to click on note you can see that Suspense and Server
Components work really well together to show your user some kind of feedback while
they're waiting for the rest of the server tree to be rendered and the reason why
we can do this is because Server Components don't render to HTML they render into a special
format that we can stream down to clients so you can think of it this way as we get the first part
of the server tree in our response we can send it down immediately to the client so the client
can start doing something with that response and when it we can also tell the client
that we should suspend and that is what allows the client to you know show that
loading state while it's continuing to wait for the other pieces of the server tree
to be sent down another way that we can respond immediately to user input is through
transitions so I'm going to add an artificial network condition so this is now going to be
slow 3G and keep in mind that this is going to be slow 3G plus an additional 3 seconds that i've
introduced artificially so I want you to see what happens when I click on one of these note items I
want you to watch what happens to the color of the highlight so if you didn't see what happened when
I clicked on a note it immediately turned a dark gray because that's what I did when I defined
that component in a transition and the transition is what allows us to respond immediately even
before the response has started streaming down to the client and with that we're done with the
demo I really enjoyed building this application and I also really enjoyed the fact that Server
Components gave me this new ability to choose whether or not I render my components on the
server or on the client I hope you enjoyed watching all of the code is on GitHub and is
open source so don't worry if you missed anything now I'd like to hand you back to Dan who's
going to wrap up the rest of the talk >> DAN: thank you Lauren wow that demo was
a lot I'm totally going to rewatch it when we put the video out in the second half of this
talk I would like to recap the key points from Lauren's demo and talk about the path then the
next steps for productionizing Server Components the first thing I want to recap from
the demo is that Server Components have zero effect on the bundle size and I
mean zero so you can have a Server Component that imports a bunch of libraries that do some
kind of pre-processing on the data and you can be confident that you're not shipping this to the
user because we don't use any automated compiler you have to make decisions about
which components to put on the client and which components to put on the server but
we think that this ability to have control is good because you have a guarantee about what gets
sent to the client and what stays on the server the other key point is that Server Components
let you access the back end resources directly it doesn't mean that you have to but you have
that option so it's easier to get started for example if you're building something like a React
blog it's nice to just be able to read it from the file system and not have to create any kind of API
layer and maybe later you want to scale up and you read it from the database instead and maybe later
you actually create some kind of an API layer and then you can access that layer and so we want
it so that you're able to switch between these different ways of reading data without changing
the paradigm and this particular example is interesting because this is a Server Component
but the only feature it uses is react-fetch and react-fetch actually works on the client
so technically this is a Shared Component that works both on the server and on the client
and I guess for a blog this is not super useful but as Lauren showed there are use cases like
markdown preview where it's nice to have the ability to render something either on the server
or on the client depending on the circumstances you might have noticed that in the demo there
were a few libraries mentioned that you might not have seen before so it's react-fs
(file system), react-pg for Postgres and react-fetch and um collectively we're
calling this these kinds of libraries React IO which stands for input-output and this is not
something that we'll have to create this is something that the community will be able to
maintain because you can create your own React IO and if you're concerned why do I have to -- why
do we need these wrappers why can't I just access the back end directly um the design philosophy
behind React IO is that these are very thin wrappers I think currently they're about 100 lines
each very thin wrappers over the underlying APIs and so for example react-fs exposes the exact
same APIs with a subset of the node fs API and so the only thing that is being added there is just
teaching React how to correctly cache the result and you might be wondering what does that mean for
GraphQL are Server Components replacing GraphQL and not really at Facebook we use
both Server Components and GraphQL so in fact our Server Components
read GraphQL queries on the server and this is because GraphQL works great for
us and we already have a GraphQL backend and it's it's just very convenient but if you
don't and if you don't want to or if you want to adopt GraphQL later Server Components give
you that option we think they're complementary to GraphQL but for people who don't want
to use GraphQL they do offer an alternative the next key point is that Server Components let
you only download the code that you actually need and I don't just mean the fact that the Server
Components are not being downloaded to the client but also even the Client Components — we don't
have to download the ones that aren't being used — so this is interesting consider this
Comment component which is a Server Component and we only want to show the
toolbar that lets you edit the post if this is your if this is your comment or
if you're an admin which is something that we happen to know on the server because that's
where the data is and so there is no point to downloading if you're visiting a comment
thread where you haven't posted and you're not an admin there is no point to downloading the
EditToolbar code and so what happens here is that even though the code looks like idiomatic React
code there seems to be nothing special about it the way Server Components are compiled
we're actually going to make it so that the server will only send the instruction to the
client to download EditToolbar if it is present in the server output so if you're visiting a
thread that doesn't have any of your comments you're not going to download that
chunk the bundle of javascript at all so this might remind you of dynamic imports but
it happens automatically behind the scenes without you having to do anything about it and so this is
possible because we integrate with the bundler so we've written an alpha version of a
webpack plugin for Server Components and this is still something it's not production ready
it's a proof of concept but we will be developing it together with our collaborators on the Next.js
team and the goal is to get the plug-in to a state where everybody can use it both Next.js users
and people who don't use Next.js and we're also talking to the Parcel maintainers who've also
expressed interest in developing a similar plugin the next key point is that Server Components
let you decide the trade-off for every concrete use case and so if you have some code that does
some data fetching and just some pre-processing it makes sense to put those components on
the server and then if you have some code that needs fast interactions to respond to input
immediately it makes sense to put it on the client but because there is no technological wall and
you're within the single technology a lot of the code can actually be shared and we expect
that the majority of components would be Shared Components that can run both on the server and on
the client and for example if you're developing something like a content management system where
you have some kind of articles it makes sense to render those articles on the server but then in
the admin panel where you're able to edit them it makes sense to render them on the client
so that they can preview changes immediately and so this is what being in a single paradigm
and unifying client and server gives us the last thing I want to recap from Lauren's
demo is that Server Components let me create user interfaces that feel modern and app-like
but the way I write them kind of reminds me of building an old-school web page so what I mean by
this is here's a search results Server Component that accepts search text as a prop and I
don't really need to think about how exactly the client server interaction happens instead I
can focus on describing the UI that I want to see and in this case I want to see the search input
and the list of results and that's it and so the search input here is a Client Component that
has its own state but it also triggers a refetch of the server tree with the new search text
and so we're back in the search results Server Component but this time the search text
is different and so we're going to get the new results and we're going to emit a a list but in
the client React is smart enough to figure out to only do the parts to only update the parts
that changed so in this example it's the list itself that might have changed right so we might
have had we might insert some new DOM nodes for new search results and remove some of
them or maybe update them but it's smart enough to understand that the search input has
not changed because it's in the same place so it doesn't destroy its state and it's really curious
what kind of features you can build on top of it like for example you could have a CSS transition
on some property and then whenever a server responds with a different value for that property
the animation will fire on the client because the DOM has not been destroyed and I personally
find that use case fascinating um and so in the way Server Components kind of sure like you can
think of client and server but they also offer you a different way to look at it which is to
think of your React app as a single tree that contains both client and the Server Components
and in this mental model you don't think as much of the client's fetching data but it's more
like the Server Components passing data to Client Components as props so it's for some problems this
way of looking at it makes things a bit simpler so to recap Server Components have no effect
on the bundle size, they let you access the backend resources directly, they enable
automatic code splitting for client code with support of a bundler plugin, you can use as
much Server Components or as little as you like, and you can choose where to place them
according to what makes sense for your product but they let you have a modern app-like user
experience even though writing them kind of feels like writing old-school web pages Server
Components are completely opt-in we're not going to force anyone to use Server Components if
you like your existing client apps that's fine um in fact we can think of existing React
apps as just apps that happen to be entirely composed of Client Components but we want to
give you the tools to make the right trade-off for your app and Server Components are still in
research and development so we're sharing them in the spirit of transparency to explain what we're
working on and how we envision the future of React but it's not something you can plug
into your production app tomorrow and we expect that the initial adoption will
happen through frameworks such as Next.js who we are collaborating with but we're not going to
create any framework specific pieces so we will be collaborating on a webpack plugin together with
the Next.js team but the goal is for anyone to be able to use it and the reason initial adoption
happens to frameworks is just because you need the control over the server and the bundler and
the router and how those pieces are tied together but after we figure this out if you have a custom
setup you will be able to copy what the frameworks do we've had a few milestones that we needed to
hit with this work so we needed to design the architecture make sure that you can actually build
something with this component model implement the streaming protocol check that all the pieces can
work together and run a real production test to verify that this approach doesn't have any glaring
holes in it and we've hit all of these milestones which is why we felt confident doing this talk and
in particular so I want to share some numbers so that you get a sense that is like not completely
hypothetical but I want to preface that by saying that they don't really mean much but in our first
production experiment where we automatically we run conversion scripts that automatically
convert components that are compatible to be Server Components and as we test it on
a single page in a single place in the product and on a limited number of users but two weeks
ago we saw 18% bundle reduction just from those automatic conversions and as we fixed a bunch
of places where the things that we were passing were not serializable and fixed our infra to
handle it better 10 days ago it was 21% reduction and by the time I'm recording this talk it was
29% reduction so of course we can't expect that this will extrapolate so that in a few months we
won't have any anything in the bundle but it is an interesting dynamic and it is an encouraging
dynamic considering we're not even using product code that was written with Server Components
in mind so this this really encouraged us although we're starting to experiment with Server
Components in production it is still an ongoing research project for example we're still missing
some of the APIs that would be necessary for example to build a Server Component router so this
is one of the things that we're currently doing the other thing that we're busy with is we're
working to finalize Concurrent Mode because it is an important optimization for Server Components
um Concurrent Mode is what allows streaming so it lets us stream the output from the server
and as this output arrives we can already start rendering Client Components with their props in
memory and then we can put them to the screen as soon as we have a decent loading state that we
can show to the user and so we don't we don't want to wait for the whole response to come back
then render all the Client Components and then show them to the screen so Concurrent Mode is an
important optimization there and we're currently adding some tweaks to it to make it easier
to adopt but this will take some more time um the the other future area of work that I want to
specifically specifically call out is we need to build an HTML renderer so Server Components render
to a intermediate format that is necessary to transfer the tree to the client without
removing or blowing away the state but we still want the fast first render and use
as much of browser capabilities as we can so it makes sense to have an HTML renderer and
so the way we imagine it is that there would be a renderer that takes in the Server Component
output stream and emits an HTML stream and so this is something that we would need to
integrate into frameworks first as well so if you're wondering if now is a good time to
play with the demo absolutely we loved building it we hope that you have fun playing with it it
has some rough edges in the way the bundling is set up so it's it's not super polished in that
sense but the parts that are in the src folder are pretty representative of how we think Server
Components would actually be used in practice so we hope that you'll enjoy playing
with it and let us know what you think and we'd love to hear from React community
so do you love the idea do you hate the idea let us know spill it all out so we're we're
excited to have a conversation about this topic and to hear your feedback on the RFC so there
are some other things that many of us might be tempted to do and I totally understand this but we
would be we would appreciate if you didn't do this but of course we can't stop you but it
makes it more difficult for us to share our research in the open in early stages so if you
don't do that thank you we really appreciate that and so the link to the demo you can find it in
our blog post and you can also find there a link to the RFC so if you have thoughts on the RFC has
some technical details so if you have any thoughts on those parts we'd love to hear them it is
not completely exhaustive but expect that we will post more talks and more RFCs covering more
specific technical aspects in the coming months Lauren and I would like to thank all of our
colleagues on the React Core and React Data teams who helped make this project happen
including Sebastian Markbåge who came up with the idea of Server Components and
all the contributors including Luna Ruan Joe Savona Juan Tejada Andrew Clark and Andrey
Lunyov and we'd also like to thank our external partners and collaborators including the
Google Chrome Web SDK team and the Next.js team in conclusion today all React apps are collections
of Client Components and if that's your use case if you're developing something that is
completely interactive like a graphic editor for example that is still
a use case we want to support well but we also want to give you the tools to tweak
it and to to make the trade-off better so maybe if you want to do some data fetching and you
currently do it in different Client Components and you have waterfalls we want to help you remove
those waterfalls by moving that work to the server or maybe you're working on an e-commerce website
where most of the content is mostly static but then maybe you have a separate flow
like a checkout flow that is very dynamic and so that kind of flow would be using mostly
Client Components or maybe you're working on something like a blog where the majority of
components are Server Components but you still need little bits of interaction here and there
and they don't want to completely reload the page every time you navigate so this is something
that we we want to support better as well and ultimately every app is different and we
don't want to tell you what kind of apps to build we don't want to be prescriptive about it but we
want to give you the tools to adjust the trade-off so that you don't have to
choose between maintainability and performance and so that
you don't have to choose between the client and the server because
we believe that you can have both thank you
