React Roundtable: Server Components, Suspense, and Actions

hi there I'm delba developer advocate for next year yes and I'm here today to talk about react with uh hi I'm Andrew I work on react I've been on the react team for about six years now uh and I've worked on things like suspense and concurrent rendering and hooks alongside Sebastian here and I'm Sebastian I worked on react for the last decade or so providing a lot of the technical Direction simple question which is how do you think about react to me it's all about components and composability how do we how do we take things all the things that it takes to build really great user experiences really great uis really great websites and applications and provide a way to author those experiences in a way that feels the most natural and direct while also allowing for really great performance out of the box and I don't think it's really that important ultimately if you call it a framework or a library or whatever you can use whatever term kind of helps you think about it the best the way I think about it personally is that it's not about any particular npm package it's not any particular implementation or even like it's not about even use state or use effect or any API like that it's all about uh providing a way to author uis user experiences applications in a way that feels natural and in a way that is composable I think that's really maybe the Crux of what makes something feel reacty is can you compose it um and the classic example of this is components but of course you also have hooks which provide composable units of functionality for your app so you know on the react team we have a sense a very strong cultural sense of some feels things that feel reacty and composability is maybe the most important one how do you think about that so yeah I think it's uh in a way it's kind of like where figuring out what all the details are that goes into building a UI and what goes into building a good ux and then we kind of distill that into Concepts that are repeatable when we kind of figure out like okay here's data fetching yes but a boundary for a component here's suspense or or Concepts like that or animations or [Music] and then we take that and we we create bounds for others to iterate on so we create a little component we create a boundary we creates Concepts that others can build UI using those Concepts yeah and then we create this ability to compose them together so there's a lot of focus for us on how do we enable others to build these building blocks without necessarily even coordinating with each other yeah in a sense like maybe react is all about the component just as an idea and all of the parts of react are how can we make things componenty like how can we take things like data fetching or animations yeah or you know all of these different things that you need to build a UI and add them to the component model yeah but we're not obsessed with anyone in particular technology aspect of it like the component itself is not um like we're not trying to force that into any possible abstraction um it's more the concept of componentization of being able to work with many different colleagues across different companies through open source or between teams internally and componentization is a way to achieve that and so we just find where that breaks down and what we can do to fix that to still build good user experiences yeah yeah are are core to raise the building blocks the Lego blocks but I feel when I I think I'm speaking for the community here as well is that in I would say probably the past two years it's been more than just components for example with your DRC that you posted on a sink and await and promises and suspense can you talk more a little bit about that and how that kind of like fits in into your um like image of react a lot of the features that we're building are finding ways to like hooks or like server components um to take things that used to force you to break outside of the component model and integrate them directly into react itself or directly into the component model so data fetching for example yeah classic example of something that until quite recently for most people it forced you to break outside of the nice just act the nice model of reactor you can just access things directly inside of your UI functions and you would have to subscribe to a store you'd have to set up this external thing State Management is another example of this like oh I have an external store that manages my state and I've got to Tunnel into that in order to in order to use it um so a lot of the stuff we've been working on the last year five years a decade um has been how do we solve this problem of making the data layer feel like it's just another part of your component yes um that's as easy to compose as state or as anything else anything else that you deal with yeah so it's like taking all these other things that you need to consider when you're building UI and then making sure that they feel cohesive with the rest of of your components now talking about components um recently we've been playing a lot with server components so for those who are watching and who might not be too familiar with it um what exactly are server components and I guess how would you like come up with the idea of server components well a server component is just a component that runs on the server but there's been things like SSR that also runs on Instagram it's a different concept but I think stepping back the way I think about it is like ignore SSR for now and think about just client navigations what is the best way we can make a seamless experience throughout your application not just arriving to it but throughout your application and we realized that there's some limitations to what we could do to achieve this like component model in a data fetching model with just doing that on the client kind of figured out what what the API we wanted it to look like and we how to compose them and how to describe your experience with things like suspense boundaries but we didn't really have the right performance and we didn't feel like you still had to do a lot of extra work to get there and we took a lot of inspiration from graphql relay that has solved a lot of those issues but there was still something missing to get to that development experience we really wanted to achieve which is like you had to create this extra abstraction layer maybe you didn't so maybe someone else did but it became this split this artificial split where you have to introduce the boundary and we wanted to be able to and we realized that it was also not often not sufficient um because in those environments you still had to break out on in under certain conditions you sometimes I have to create a new artificial denormalized field we have to conditionally request one query and another sometimes conditions and now that that wasn't the same as as we would like and so I tried to figure out what could we do to make that more fit with just the react model and and just the same component model and it turned out I had already had a similar idea for a different use case years before which was to run separate trees in separate processes but on the clients and we try to do this for parallelism purposes turned out to not be a great idea because the overhead running two processes on the client was just not worth it for that use case but I realized that the same thing could just work on the server we could just move some of the tree to the server and then that has the full power of the server which includes things like low latency access to data which avoids the waterfall problems you can access things that have different security models like databases directly you can ad hoc request data from a fetch if you need to or from a database you can combine these two things you can create an orm layer you can create a security model layer all within that model because now you're in the kind of a secure sandbox so there was just a lot of things that fell into place once we had This Server component model and then it took a long time to iterate on what exactly that would look like when into various designs co-location having multiple different part and client server in the same file we iterated element file extensions various annotations special syntax and it took a while to come up with this model but we think what we came up with is a it's a good balance of constraints and it there's some parts that are a little bit annoying to learn but we think it's worth it because once you learn that one thing you just unlock it completely new ecosystem what I really liked about that recap that Sev gave of kind of the evolution of where these ideas came from is that you notice there are a lot of different inputs into what suppose a lot of inputs into the the final design that became server components and it's not just performance it's not just like the DX angle it's not just like how do we make these things composable it was a little bit of all of them and then you go through all these iterations and you come out with a result that we think in the end doesn't really feel like a compromise on any of those axes like if you actually look at the process for how we got there that that felt a little bit messy but in the end you get a result that seems inevitable can you talk a little bit more about that like how should developers go about thinking about server components versus client components I'm not going to say this it won't be a little bit of a learning curve for folks there is some um there is some knowledge that you have to acquire for like okay how do I declare that this particular component is going to run the client now you add a huge client directive in that file and then it works on the client um in a way it's just really just as simple as that like you might want to know a little bit more for what's going on behind the scenes but when you actually use it I don't think it will be confusing I think it 'll be a little adjustment but it's just it feels very natural yeah yeah developer working with SP you kind of just tended to ignore the server like you didn't really think much about it unless you had to do some back-end stuff whereas I think this is going to like help a lot of front-end developers to really start thinking about the server because it's it's a very crucial part of your application well yeah that's um that's a good way to put it I I think it also illustrates a point though which is that this is what I was trying to touch on with the constraints we don't realize our constraints I think if you're a front-end developer I'm going to put that in quotes for a second yeah um and you especially if you're on a team or on a in an organization that has very strict separation between front end and back-end rules you might take for granted today that oh I have an API someone built an API for me and you just call it and I'm just going to call it and I didn't have to think about like the performance of that um or like I didn't have to design the you know the API endpoints I'm just magically gonna have access to it and so from that person's perspective I can see how Maybe you just said like oh now the other person can think about the server maybe they don't want to think about the server so I can see how maybe from that perspective you're like you're giving me more to do but if you think about it from like the global perspective of what does it take to build an app it's actually way more convenient to do it this way because if you look at the uh oh it used to be two different people had to build a feature you'd have to build the API and then you'd have to hand it off to another person to build the front end of it now one person or two people working together can build the entire feature likely in a single component without that artificial air in between and if you look at the aggregate complexity yeah it's actually way simpler and way less confusing than this previous world where you had to pass it off like a baton without the like the additional tooling or languages that you need to go to the server that's really cool so touching on on an aspect of that you're gonna come at this from different angles depending on how you used to work and depending on on how you used to work you can use this more or less like we talk a lot about cervical models now because it's kind of new but it doesn't mean that for everyone it permeates everything if you're building an app that is or even maybe you don't even call an app it's like a site it's like a marketing page maybe you want to think about this being more of a server first it's just providing a structure of your page but it doesn't mean that it has to be all Server Like There's it's perfectly fine to have client components in this model as well that is they're not Escape patches they're part of the the whole model and on the flip side it might be that you actually need a lot of client components because you have a particularly interactive low and latency app with everything going on on the client but you might still use a little bit of a server maybe it's a settings page in the background maybe it's an about page in background maybe it's this the server provides the scaffolding for which a B test group this user is in um and it doesn't have to permeate everything like you just use it a little bit or use it a lot it kind of depends on your situation and and where you're coming from but it's really just another tool in your toolbox if you want to think about it that way like you don't you don't have to move stuff it's just there and it happens to be really convenient and you're going to want to use it but it's not an extra like concern it's an extra tool yeah exactly it's a non-breaking change you can choose to move things when you're able to yeah so um when it comes to I guess moving things to the server in doing more things on the server as you said mentions um server first how should we think about the interaction between the server and the client I guess what I'm asking is how exactly do server components in client components work I know earlier said you mentioned about the trees can you talk to us a little bit more about that so that we can have a better understanding of like how things flow from the server to the client yeah the model is anytime you kind of need data you're doing a request to the server and I'm going to start assuming that we're already on the client and wait with SSR for now because a lot of this is about optimizing that cross-page experience where you're already on a page and and you're consuming that page and you're interacting with that page and if I'm navigating to somewhere it could be that this fetch is a pre-load or prefetch or pre-render for the next page um then we're going to do a fetch to server the server isn't going to load the data that we need which you can do using your components and that will execute this server components down once that hits a client component we have to serialize that to sent to the server we need to create instructions which is basically just Json instructions and as we're doing that we might discover that one of the properties of that client component which would typically be named children but it could be anything it could be a title or header property that you pass to a client component if that also takes the server component we have to optimistically renovate on the server because that might now be needed on a client it might not be because the client component can conditionally render this like maybe it's a show more and that's content but we really want to avoid those extra round trips when that happens we want the when you click that show more to be active so therefore we also render the server components on the server even though it's a child of a client component so just to make sure we understand you have your server components and your client components in their interleaved uh in the tree so you resolve all the server components on the server first and the client components and the client components get a placeholder in the instruction so it's basically turning into a new tree of client components you're going to resolved all the serving components out of the tree and now you're left with a tree of client components and that's what we send to the client then the clients takes that and just renders it with react and that lets you have both of these interleaved treats all of this happens extremely though which is a term coined by Andrew which means that every piece of these happen gets sent to the client as they happen which means that these are not two separate steps this is not a waterfall do all the server stuff and then do all the client stuff they're actually executing interleaved as well but it just happened on two different worlds that's interesting can you talk more about that well one thing I'll say is that like the nice thing about all this is you don't have to think about it for the most part it's just how it happens to work um and I think that was that's been a really exciting thing about all of these various kind of insights and innovations that have led up to this streaming server components architecture but the question that you can ask yourself is seems a little silly that every single time I want to access a piece of data I have to design a loading state uh and this is this is still kind of how it is if you use like a hook face API today is every time I want to access some piece of data from a server again this is like with existing like hooked based solutions for data fetching I have to design a loading State because what do I do if the data is not there so the API usually is like use you know fetch from server whatever it's called Uh and then you get like a little Tuple back which is is loading and then the actual data if it's there yeah and then it doesn't matter like if I don't want a spinner or a loading State there I've got to do something I can't just I gotta show something there so what ends up happening is every single time you want to access data you design a loading State um but it turns out like you're doing that all over the place like everywhere is accessing data right so you get this um I think people have referred to it as like a spin again or uh you know too many Spinners yeah all over the place um by accident not because you thought a spinner should go there but because you had to render something so yeah I think the original idea and sub can correct me the original like Insight that kind of made suspense click even before we had a name for it um was you should be able to Define where the placeholders go in your app the loading screens go on your app separately from where the data is accessed um so that idea kind of came first then we had a whole Saga of okay well that's how you that's how like the the user experience part of it can be designed but what does the actual data come from and so on and so forth that led to server components um but that that was like a really key Milestone and it led to things like the streaming server renderer because suspenses are very powerful component to like how that works um it led to things like uh uh you know once we had this declarative way to define loading States it raised some interesting opportunities for us for like well now react can decide when to show a loading State versus when not to how should it do that should it always show loading state if the data isn't there can it throttle the appearance sometimes um is it sometimes preferable preferable preferable for it to block the transition as opposed to immediately showing a loading State we had a lot of iterations on that a lot of uh feedback that we got from folks working on relay and Folks at Facebook at the time many different iterations similar to the Sago with server components um but I think what we ended up with was once again like like the best apis that we try to come up with is that when you use suspense it's just gonna work when you use this fence you're going to get loading States at the moment that you want them and react is going to know how to intelligently uh avoid certain like avoid certain loading states that lead to a bad user experience um and you're not going to have to think about it as the application developer you're just going to tell you're just going to design where the living states go and react will figure everything else out for you yeah yeah so the I guess the thing about suspense as well it's that it's just it it's not just about the loading state or telling me act okay this relies on data um you also have an aspect of streaming as well right right which I think in our industry people don't really Implement streaming that much because it's very hard to do so so can you tell me a bit more about how does it relate back to streaming from the server so what direct lets you do for example is you can start rendering that when you have the Js and produce the results wait for that results to be displayed until we have the CSS and then to display them all both at once so you're cutting down the total lifetime of the application by parallelizing as much as possible so that's one aspect to it even if your user experience is nowhere different streaming just lets you do more things in parallel you can paralyze all the work you're doing the clients you can paralyze through data streams you can start sending it earlier you can paralyze a similar example is you fetch all your data on the server and then you wait to send it until you have all the data and then you have to wait on each of those bytes kind of going across the internet through the internet tubes one by one and then when you get them on the client you're now going to do the next step instead of doing all of those things as steps we just interleaved them we do everything as early as we can and that just shortens the total span of the experience so that's like one with the first thing is streaming then what we can do is that we can change the user experience to not show everything at once but show things in piecemeal and but that's the secondary with suspense yeah and so you add the suspense battery to say actually I'm okay with showing this in two stages or three stages or however you want to design that loading sequence and then we get shortened the the time to display for that first stage even more if you're hearing all these details some of you are thinking oh that's that's really cool some of you might be going oh my goodness why is it so complicated why why are you doing all this stuff we should go back to a simpler time um but it is simpler for for you who is using it for the person enjoying the magic trick yeah and then we have fun too because we like building that stuff but ultimately you're not supposed to think about how it works that's the goal you shouldn't have to think about how it works yeah amazing the other thing as well to do with suspense is we often heard or hear the term suspense for data fetching what exactly do we mean by that and I'm going to be really careful how I describe this because I don't want it to come off um flippantly but like in a lot of ways server components is suspense for data fetching that's what that is we're not calling it that anymore um but that is like our first Clash like this is the solution we think for the best way to to compose data requirements into your app I think nowadays some people will say that and they mean they might have a different idea of what it means they might think oh we want like a built-in um so so I'll use an example there's a really popular react library today called react query and some people think that oh suspense for data fetching will just be like a built-in react query um I think if we ever call something suspense for data fetching it won't be exactly like that it'll be something more inspired by by server components but to give like a a high level answer at least this is the way I think about it like suspense for data fetching or server components that's what it is so I think the server components is the main way we think about it for the data fetching um I think we will explore other types of building data fetching for example offline first support synchronized data as well but there's an something in between there if if you don't want to run a server or you have some particular constraint that you cannot run your server into this environment and you want to do it you can still use server component for static parts of the page but you might still have some data and that data you can use a jam stack model where some of the data is fetched on the client some of it is just statically provided and we want to make that fit into the same API as cervical components we're not really sure we're calling it like maybe data components it's like a morphing data component is like a server component but on the client um and but it's the same programming model so we want to extend that we think of it but we think of that more as a de-opt of what you would have done if you did a server component rather than a a primary thing that you would strive to use okay so we we've talked about features of read how they work but there is something that was announced quite recently as well which is actions can you tell me more about actions in react and also how does it tie in with the rest of the architecture yes Excellence is a very exciting feature and it it actually starts you can start by thinking it as a as a client only feature it doesn't necessarily have to do with server components because it's just a more convenient way to utilize forms that already exist in the browser in a pattern that was already very common and we're just making it easier to have it built in but also building on this notion of compostability we also expect the ecosystem to build their own sources of actions you can build a custom button that takes an action you can build a date picker that causes an action when you select the date picker it's not only for forms and you can use produce an action that does something on the client or even more excitingly you can move the action to the server and it fits seamlessly into the server components model and once we do that we can do a lot of different things with that action because an action will often be a mutation it will cause the change to the UI and by by having that on the server we can actually invalidate the caches that we have on the server and that means you can actually cache more right because the problem with casuals is you have to make up a time based and you have to figure out when it's going to invalidate it but am I making it very easy to just invalidate those caches server side and that's something that you can't do the client side we already know like we can invalidate caches we can refresh things on the client but that doesn't refresh it from another user so now because we're on the server we can also refresh our caches we can read compute our ISR but because of server components and more importantly react reconciliation we can send you the new risk updated result of the page given that new data and that is something that is kind of a new shift because I think what we used to do a lot is a normalized data storage we remember in my dad is like you have a usernetes ID and a name and it can only be one name on the client and then you have to update that on the client when that changes you have to then figure out where that's used everywhere and you you have to figure out if that's the derived field the model just becomes so much simpler with the server action plus the server components because you just refresh the data and because reacts reconciliation it doesn't matter how that refreshed it will just preserve the state and this this system of the page but just as if it was a new data so it doesn't throw away anything it doesn't cause the screen to go blank and come back it doesn't um close their chat Windows it doesn't stop your video from playing while you're doing this and it kind of just works with the the client-side experience but together with the server and so we think that that's going to be a really powerful primitive to build on what's great about that is too is like the way if you listen to the description it sounds a lot at least the first part does the first part sounds a lot like a multi-page app or like what people like about a multi-page episode you just click a thing you do a full page navigation imagine a new thing but that the points that made about you know it is that but it's way better because when you do that navigation you're not going to lose the state of the things that were on the previous screen as well there's a really great demo that did you build this demo there's there's a next demo that that illustrates this really well whoever did great job um that illustrates this I think really clearly that um you're having your cake and you're eating it too you're getting the things that people like about multi-page apps yeah without sacrificing all of the the really great things we've come to love about single page apps client driven apps over the last decade wow so there's a lot in react that I think we all will have to learn and get used to is it exciting though or is it overwhelming um it is exciting when you see the potential and what you can do with it as you mentioned earlier it's not just a performance thing there's a lot of other benefits which kind of leads me to my next question is do you have any recommendations for people learning these new features and it could be for example patterns of how they can think about building applications we react yeah I mean I think my basic biggest advice and the reason I ask you if you're overwhelmed is because I think some people are feeling a little overwhelmed like especially maybe with this conversation we've gotten we always find it difficult to modulate like how technical we should go because again at the end of the day you're not supposed to think about any of this not you in particular I mean in general people using react or next are not are not really supposed to think about this if they have to think about it too much it means we probably didn't do our job well enough right I mean it's really interesting to talk about like we could sit here and talk about it for 10 hours and be really great but we don't want to be overwhelming we want it to be exciting and we want it to be uh we want you to be excited by the potential of what you can build on top when you don't have to think about all this stuff anymore it's like oh great I don't have to worry about hydration costs because react does all those magic tricks to make it just work so uh what was your question again I forgot now I got all excited on my soapbox oh advice yeah yes my advice would be first of all don't get overwhelmed and then secondly if you especially if you've been doing this for a while if you've been building on the web for a while if you build them with react for a while try to forget what you know try to forget what you know and approach things with like a fresh perspective like do you know dev's perspective yes exactly or someone maybe someone who I mean I I think we often think not just of Junior does but like maybe people who aren't even programmers like they're designed I've met a lot of these types of folks they they are designers they have a smattering of CSS knowledge and then they look over uh you know to their colleague and see the code that they're writing they're like oh I could do that I know HTML pretty well that doesn't look that different from that person's perspective I think it might be even easier for that person to learn server components than it might be for someone you know like me who's who's got like uh you know a decade of uh you know web and UI baggage rattling around in my head yeah technical debt uh and all these preconceived notions about like what is a constraint versus what isn't you know we brought up the hydration examples a lot of people think of that as like oh that's never going to work you can never make hydration work because it blocks the main floor for too long and it delays interactions well we made it work so you just need to abandon and some of these these preconceived notions if you approach it from that mindset I think it'll be a lot less overwhelming and a lot more dare I say liberating in the sense of all this stuff that I used to have to used to get in my way is now actually supporting me and making my life easier as I focus on the things I actually want to focus on to make my app or my website as good as it can possibly be yeah that's that's really great advice and I I definitely agree it's it's easier to think about it when you actually come with with like fresh eyes it really does help what about yourself do you have any advice well I'm excited to see what new stuff people come up with because like with hooks the the the core principle of hoax is the compost ability it's not like the easiest way to use daily use effect whatever it's the custom use custom whatever hook that's what opens up a new industry a new ecosystem and a new wave of inspiration a new way of Creative Solutions and I think that's what I'm most excited about with service components is just explore things you built before try to build a new framework like necessarily Port what you've done before can I rethink how much needs to be clients how would you design a form in this world where now they have new building blocks some of the assumptions you might have done in the past no longer apply because now you can compose server actions you can rely on this selected radiation you can do your data fetching and you can publish that from uh from the npm and share it with your friends and colleagues and there's just the way you build these things are going to be different and there's some hurdles and the upgrade path and and the the early adopters but that's going to be the really exciting thing for me is like seeing how that ecosystem grows in the next couple of months yeah yeah I think that will be very exciting and on that note how do you see react uh evolving the next couple of years so there's nothing really in particular I mean I could list off like I really want us to get uh better like built-in animations and things like that um I think that would be really cool to move animations into the component model the way we've we're doing now with um with data fetching but um yeah it's not really any particular thing I'm just uh excited about that general idea of making things more composable yeah yeah I think the we're only kind of halfway there with the the data loading like we can make data loading even easier like we have the building blocks now to be able to pull in different libraries and I'm not sure if we are the ones to build it or is there's a third party that builds it or or how we compose these things but I think there's just so much more to make data management even easier to to bring into this model and I think one Focus that to bring this is is going to be the the mobile aspect and and more offline first aspect more of a client first um we can do make that even easier but still sticking to this model and taking advantage of it where it makes sense yeah awesome well thank you both so much it really helped I think and I hoped it has helped clarify all these new features uh for a lot of people so yeah thank you for taking the time to talk to us yeah thanks for talking to us it was really nice

Channel: Vercel

Views: 23,538

Keywords: nextjs 13, react server components, react js, next.js 13, next js, next js 13, react, server components, web development 2023, web development, react query, next js project, react server components nextjs, react js for beginners

Id: g5BGoLyGjY0

Length: 38min 56sec (2336 seconds)

Published: Mon May 29 2023

Reddit Comments

[u/AkisFatHusband]

Those high chairs man. And there's not even a table

[u/CleanMarsupial]

"React roundtable" this shit is getting more and more elitist since vercel took charge.

Ps I like the tech tho

[u/otw]

Eh I am getting really bad smells from all this still. This did not really imbue any confidence in me.

[u/drink_with_me_to_day]

uhuh, yeah x500

[u/_AndyJessop]

Is React merging with NextJs, and is that a bad thing? Yes, and yes.

[u/watsonwtsn]

weird vibes

[u/editor_of_the_beast]

What are Actions

[u/AlexanderSwed]

Andrew, blink right in the camera next time if they make you do it.

I hope Vercel doesn't make it a default for tech companies to spend this much money on production.