Data Fetching with React Server Components
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
2020-12-23 05:32
