What RSCs Can Do in Next.js Today

My name's Aurora. I work on the Next.js team at Brazil. And React Server Components landed a few years ago. It's been quite a journey. Some of you have shipped app router apps with them. Some of you maybe you tried them, you bounced, you went back to the patterns that already worked for you, and some of you maybe have just been watching from the sidelines. So waiting to see where this goes. But wherever you are with them, the model has come a long way. And I want to show you what React Server Components can do in Next.js today and why I think it's the most interesting time to be building on the web.

But before we talk about Next.js, let's talk about React. The story starts with a thing we already love about React. Why do we love React? You might not have really thought about or articulated why, but you feel it every time you write a component. React is composable. You can build a row, a playlist, a page, snap them together, and they just work. So here's a page with a handful of feature components composed together. React components can be self-contained. A different page can reuse some of the same pieces mixed with new ones for what the page needs. React gives us clear boundaries. Somewhere else, same components reappear, re-stacked in another order. We didn't have to know what was inside each one. So that composability is the thing we want to keep. Everything else in the stack has to earn its place around that.

Now, components have clear boundaries, clear inputs, clear outputs. That's the same property that makes a component easy to reason about for us, also makes it manageable for an agent. So an agent can pick up one piece, change it, and not have to understand the whole app to do that safely. The bigger the code base gets, the more that matters for the agent, for you, and for your teammates. And this is not just true at the component level. People are noticing this in the shape of the whole code base. So this is Antonio. You might have watched his YouTube code with Antonio. It was great. It was like my way when I was learning AppRouter back in the day. But he's been building real apps with agents, and what he also keeps landing on is this small blast radius and clear boundaries. So this is the same property, just scaled up to the code base level. Maybe that would mean feature folder instead of only thinking about single components. But what does all of this look like in practice when you start building? The moment we add data, composability comes under pressure. Some approaches keep it and pay for it somewhere else, and some just lose the composability entirely. So let's walk through what we've tried. We started with useEffect, our favorite. The component can fetch on render, own its loading flag, owns the error flag and runs the request inside the useEffect with the right dependency array. Do you forget a dependency and you get stale data or you add one too many and you start fetching in a loop? So on its own, it looks fine. We have a component here, top boundary grid, it's owning its data. But then the moment another component then needs the same data, we can't just drop this in twice because now we'd be making the same fetch twice. So we hoist it up to a parent component, pass it down through props, and suddenly this component no longer owns its data. Start adding mutations, you have to hoist it higher to execute those state changes, and suddenly your self-contained component is plumbed through three levels of props for reasons that have nothing to do with the UI structure. A whole category of libraries emerged to clean this up. We had React Query, SWIR, Apollo, Relay. So here the data would instead be keyed and cached centrally so that any component can ask for it without prop drilling, and mutations can invalidate from anywhere. And this was a genuine step forward. And these libraries are still a great choice for a lot of apps today.

But the trade-off here is that this is all client-first. The user still has to download the JavaScript and the data layer before any fetch starts, and the cache leaves outside of the component tree, so that means we typically maintain two structures, the components and then the query keys. And that mental overhead is the price of client-side flexibility. In response, some frameworks and libraries hoist the data fetching up to the routes. So in the pages router we had getServers.props, React has loaders, so we all converged into this same pattern. A single function that fetches everything the page needs up front, and then the result can be passed down.

Now getServers.props improved the overall time to load content by fetching on the server, but it hurt the time to first frame, because the page would be waiting on the slowest query before anything would be painted. And the data binding moved to the route, so here, if we have a component that's reading the data from the loader, you can no longer just drop this anywhere, because it's tied to the loader, you have to move the loader, you have to clean it up if you move it somewhere else, so basically the component would be welded to the route. And it would be harder to share the same data across different layouts or routes. So each of this solved a real problem, but each one also added a concept, and every time the component became a little more tied to the layer that fetches its data.

Now with React server components, the fetching stays on the server, right next to the database, the API, the file system, wherever the data actually lives, so the same component here one more time, it's now an async function, it awaits its query directly where it renders and returns the UI. And look at what came back here, composition. So the component can now own its data again. You can drop this anywhere and it will just work. And React's model has always been declarative, describe what should happen and let React coordinate when. Now suspense extends that to async where loading becomes a part of that model, so we can wrap the parts that depend on the data, give them a fallback and have the content stream in when ready. We can also use error boundaries to compose in the same declarative way.

Now with this pattern, what reveals when or what errors where is our choice. So suspense works for code splitting or any client data library that supports it, for promises, reading with use or, yeah, a lot of different ways to use suspense. But with the server rendered, with server rendered apps you can also stream in UI with suspense, so this is what RSC's changed. You can change where the coordination lives and the data fetch and this boundary can sit next to the component. So each part of the tree can show up with its own data, ready, without moving the whole sequence up the route.

So taking a step back, what do we actually want in our apps? Well, we want components that are self-contained, you can drop it on any page, without lifting state up like in use effect, without rolling into a route like with a loader, without keeping a separate set of cache keys, move it freely, hand it to an agent, refactor it in place. We also want a fast first pane, data should be fetched on the server next to where it lives so the browser doesn't have to download our JavaScript and our data layer before anything starts. We also want coordinated UI, loading, transition, optimistic updates that stay in sync and the page should decide what happens, not the network. And we want strong core web vitals, a good SEO, good lighthouse, and performance that holds up as our product scales.

We obviously also want fresh data and when something changes, both the server cache and the browser cache should update together. And maybe most importantly, we want navigations that feel instant. Clicking a link should show the page, ideally, instead of just showing a skeleton and it should show instantly, right away as you click the button. And none of these pieces are hard on their own, it's just that when you have data that lives in different parts of the system with different rules, it can get complicated. So we typically spend more time coordinating where our data lives than actually building features.

Now, the NextGIS app router landed with server components built in and that got us most of the way there. Self-contained components, coordinated UI, core web vitals that hold up because we ship less JavaScript and start streaming earlier. Take first paint, for example. So these numbers come from a benchmark that Nadia Makarevich shared online. So this was the same app in three implementations and throttled with some realistic throttling. It's a really good post if you want to read about more of that.

But the results here show that time to content visible with client-side fetching typically takes in this example 5.1 seconds. So you have the JavaScript, then you fetch, then you render. With page-to-server, get-server-side-props, which is the loader, it would take 2.15 seconds. So the data is on the server, but the page waits for the slowest part of the query before anything paints. Now, app router with RSEs and suspense takes 1.28 seconds so you would have the shell paint first and then the slow parts stream in. And that's about three times faster than client-side fetching. And additionally, you don't even ship the JavaScript to the client. So the numbers are there.

But fast-first paint isn't the whole story. There are still things that people have been rightfully frustrated about with the app router. So the fresh data part here. For a while, a lot of things in Next.js were cached by default. We had the fetch cache, the route cache, the data cache. I don't even know how many there are. So you'd ship something, and then the content would be stale, and then the fix was to opt out of caching somewhere in the right place. And also instant navigations. Even with all of that, navigation could still fall back to a skeleton on the page you'd been to a second ago. And we'll get to this one in a minute.

But we solved the fresh data side version in the first data side in version 16. It's called cache components. So this is the foundation that everything else builds on. The data is simple. It's a caching that fits the component tree. The same function you already write, opted into caching per component with a validation that flows through both the server cache and the client's cache with one call. And the API is small enough to keep in your head.

Cache components extends React's declarative model to the cache layer. So the same functions you already write with one directive, and a directive here was necessary to bring the infrastructure layer into the component model in this declarative way. So you have used cache, which opts a page component or function into caching. You don't need to write cache keys. It just comes from the function arguments enclosure. Cache tag is to tag a specific part of your data so that you can revalidate it later. And then the cache life to say how long it's going to stay fresh. And in 16, we also flipped the default.

So from 16 on, nothing is cached until you mark it that way. And that might sound backward until you remember this implicit caching we had before where it was just really confusing. So now you cache what you mean to cache. Now cache components handle a fresh data site and that brings us to what we're shipping now which is instant navigations. So what makes an app feel instant is not just that the server is fast, it's that the click produces something useful immediately. And there's a threshold here where based on research around 100 milliseconds, the UI stops feeling instantaneous. And that's actually faster than most CDNs can respond with a warm cache.

And that's actually faster than most CDNs can respond with a warm cache. So even if the server rendered page is objectively fast, if the click takes more than that, it's going to feel slow regardless. So this is like the awkward gap between server rendered apps or for server rendered apps. You can have a great first pane SEO streaming, cache data, all of that and still lose the spa feeling on the second click. So as long as the network is in front of it, it will not feel that fast. And that's why we often prefer spas even though they do benchmark worse.

In Next 16.3, we're making that click feel instant without giving up server rendering. We're working on stabilizing this release over the coming weeks. For the user, it's the difference between clicking a link and having a brief delay and getting an instant response. We have something called app shells. Instead of treating every page as its own thing, Next.js can prepare a generic shared part of the route ahead of time and then reuse that shell for every URL on that route. So the client only sees it once and reuses it for the rest of the session.

Then we paired with what we call partial prefetching. So we used to prefetch very aggressively for every link in the viewport. You could like watch it flood the network tab and then the click would still feel slow if you hadn't gotten that prefetch in time. So now we're flipping that. So since you have this app shell, you can always prefetch that in the background and reuse it every time you go to a route. So you can prefetch this safely. It's basically free. And then you can add on additional features, which we're going to show you later, to prepare what additional content you want to prefetch per route. We also have stuff on the devtool side. We have something called instant insights. It's going to tell you where your app is not instant and where you might be having a performance So that you can... It's like TypeScript for your performance.

And then it will help you make the right choice. And then we also have some other things, like the navigation inspector to freeze your prefetched UI and debug it. And a playwright utility to lock that in in CI. So there's a lot more things in 16.3, but this is what is important for the instant story.

Now we're also building Next.js with agents in mind across everything we ship in 16.3. So we have the foundation, which is bundle documentation that is in your Node modules, version match to your installed version. So there's no stale training data and your agent will use the right APIs. Pair that with the dev MCP server to give the agent live app context.

And also we have official Next.js skills coming. So this is first-party integration that can drive the agent through real workflows and verify changes. And we also focus a lot on agent-ready errors. So that means that we ship specific fixes that the agent can read and use autonomously or with your help. So to bring all this together we're gonna build a music player. Let me show you how it looks in code. Alright. Yes. So. Interesting. There we go. So I'm here in this preview 16.3 version and there's not a lot here right now.

We're gonna get back to that. So let's just start with the basics. I have all the new stuff enabled. So right now there's not much here. Let's just start by dropping in a component. Let's do a quick play grid. And see what happens.

Sorry, I just reloaded this a while ago. There we go. So I have an issue. And I'm gonna deal with that later for now. Just notice that I have a new component here which is a server component which is entirely composable and on its own here just fetching its data from the database here with some delay. We can do some more here.

Maybe we want some more features. Maybe we want a most played. And maybe we also want some playlists. Yeah, that's in the wrong spot maybe. Oh, yeah, because I only have four songs. That's fine. It's over here. Let's add in some more. Maybe some playlists. Browse. I think it's called playlist browse. Yep. And let's also add in this top genres component that I was using in the slides. Top genres grid. Now this is great. They're all like entirely composable here but I have some issues.

And if I try to reload this, you'll see I have a pretty slow load here. So this is the insights firing. So here we'll actually see the exact problem where we're causing a delay. Imagine it's a loader. Your loader is like slow. But here it's gonna tell you it's slow. You can fix this by either caching it, streaming it or saying you explicitly want this to be a slow page. And this also has an agent prompt that you can just paste in, pick whichever one you want and then give it to your agent and he will execute that. So that's pretty cool. I'm gonna do it... I know how to do this so I can just do it myself. But that's part of what we're shipping. This is the instant insights. Sorry. Anyway, we want to stream this so that we can unblock this page.

So let's go ahead and do that with suspense. And here we're gonna do the fallback. Let's do the quick play grid skeleton. So I obviously made these perfect. Oh, fallback. There we go. And let's do the same... I mean, I don't really care about my... Sorry, I have a click copy thing in the background. That's the sound. But anyway, we're gonna add another suspense here. And let's just do this most played thing. Sorry for that sound. I should have turned off that app. And then let's see. So now I have my suspense here, I have my suspense here. And what did I miss right now? Did I miss something? Okay, most played. Oh, thank you! Thank you very much. You guys are good at this. There we go.

So I have this, I have my most played, and it's like streaming, right? And I was able to design my loading sequence. This is below the fold. I really don't care what's here. Let me just put that individually. So that's the incident site telling me what I have to fix. And you can see they disappeared just now. Now let's move on. Because we're already using React's new stuff here, we can also animate. This is not something I would maybe recommend to your own apps, because it's kind of still canary. But it's pretty cool. So let me just make this a bit nicer and add a crossfade to this. This is using the view transitions. I always use this because it makes my demos look nice. But that will give me a nice crossfade when I stream this in like that. And everything which is...

Everything outside of suspense here is now part of the static shell. So we can optimize this in XJS. We can put it on a CDN so that you always get this fast first load and then stream in whatever is later. All right.

Let's try this out. I have... So sorry for this stupid AI music. I'm so sorry. But it works. I mean... Yeah. Let's see why it's playing. This is using this track play row. It's using our React. We have use client here. Use player. This is a huge hook. But it works really well. Yeah. It's nice. We're gonna play more later. Don't worry. But we're gonna code first.

So, yeah. This is using context. So I can wrap context around my server components. That's fine. Anyway, let's actually get to a playlist. Because I don't think this page exists yet. We're gonna do this one next. We have a bit of work to do. So I'm here on the next page. Now it's also a stub. Let's just start filling in some components here. Let's do a playlist detail. And I'm gonna need some sort of ID here. Let's get that from the props. So I can do... Let's do params. So we have this await in Next.js. So we're gonna solve this later. But I'm gonna get this from my props. And we should be able to pass that down and make this page async. And maybe we want also some other playlists.

So where am I? There we go. That's my playlist detail. Maybe you also want a playlist browse here. And let's use the same component as before. Let's just pass in an exclude ID for this one. Yes. Now, again, I have this problem. You can see it there in the issues, which is a part of Cache Components, which we've optimized. But I still have a slow load here. It's gonna take, like... It's like I'm using a loader, basically. So again, we need to stream this. So let's start by doing a suspense around this playlist detail. Let's do... Well, you might have guessed it, but I'm gonna do playlist skeleton. And let's just wrap this here. And we have to do the same for the browse. So let's do the same thing there. Is this even a real component? I don't even know. I think it's playlist list or something. Yes. Let's try this one. Count three. Oops. This is my first time doing a demo with sound. So... All right.

So now it's streaming. You have this. And then... Right? But let's actually pick a different playlist and try what will happen. So let's say I pick this one. Do you see how this layout shift here? Right? This part is, like, jumping. So why is that? Well, I don't actually know how many songs I have in this playlist, so I can't stream it like this. It's gonna always make a layout shift. So what's cool with suspense is we can move this around however we like and design the loading sequence. So this is one way. Another way is to just have one big suspense entirely. It's, like... Let's wrap it here. And that should be... But now it's really slow. It's like waiting for both of those. So what we could do instead is we can actually keep this one... Let's do a nested suspense here. I think it would be there. Now we can make sure we don't reveal this until it's ready. There we go. So now we don't have any layout shift, and we get the first part quickly. Pretty nice.

I still have one issue here. This is because you might have noticed if you've used Next, we have async parameters, because that means we can optimize the shell when we don't await them. So I'm just gonna do a quick fix here. Let's get rid of this, get rid of the async, and we're gonna do something cool, which is to do params then. I just learned this, and I was like, hey, this is really good, actually. So we get the ID, and then let's see if we can return this inside of here. I might not be able to... Hold on.

What am I doing wrong here? It's so hard to code, right? Nowadays. Wait. How does JavaScript... I think it's one more of this. Oh, wait. Okay, like that. Okay, this one should be fine. And then let's wrap this here. And please help me. Oh, God. And then what am I missing? Right? Why is it doing that? Oh, oh my gosh, look at my code. Okay, we're almost there. Can you just like... Oh, JSX fragment. Oh, just, please, just fix it. Just please... No, but this is... Oh, it did this. That one, right? Oh, thank God. I almost had to, like, panic and ask the AI there. Anyway, so, yeah. There we go. So this is a pretty cool pattern. It's just JavaScript. Let's just easily destructure that. Okay.

So that's fine. So we have this immediate load now. I have more playlists down here. Let's see what else we can build in this. We can also animate this for fun. Like crossfade. Let's do a crossfade and just see what's gonna happen. Should be pretty nice. Why what happened to my internet? That's fine. That's pretty good, right? Okay. Let's try the playlist. I think I like this one. I've been using this app a lot while preparing, and I think I know all the songs at this point. And then notice in the playlist here, what am I even keeping in here? Detail. I have some different components. I have my client components, play button, that's this big one over here.

Using the player. Same as before, huh? In the context. Pretty nice. We can also add like error boundaries and whatever, but I think this is fine for now. So actually, let's pause this. I have like a whole app here. So I have been building with these same components all over the app and using these same primitives. And you'll notice it feels quite slow right now. So first of all, let's look at what's here. We have like a like page, which is all using the same patterns that I have been showing you. So it's like really composable, beautiful components, right? Page structure. And we're using feature slicing. So all of this is like agent friendly and easy to change without messing up your codebase.

I don't think I'm going to have time to show everything, but basically what you can do with cache components is you can start adding playlist queries. You can start adding use cache wherever you want to now opt in to caching because it's still showing this like delay on everything, right? So you can add use cache wherever you want to cache. You can add cache life like that if it wants to import. And you can add cache tag to go ahead and revalidate this. And then for prefetching, we can go ahead and add to our pages. I'm not going to say this because I'm going to show you some cool later. You can add a new thing that we're adding, which is export const. Prefetch for allow runtime. So this means that you're okay with prefetching user dependent data.

And with all of this, let me just show you how it will look when I do this because it's way cooler than what I've been showing you. So notice I am like prefetching a bunch of things here. And after this has been prefetched already, my app is already instant. So it's just reusing those same, whenever I scroll into something, it's just going to reuse them. And your app feels like a spa. And that's the whole goal of this. And if I go ahead and like, you know, make a new playlist, say new, oh, that's my card. Great. You'll see, now prefetched everything that has to be revalidated for that. And I can go to new, and it's already there. So this is what we can do with use cache on top of RSCs right now.

What else can we do? Well, we can also, let's say we, so we're prefetched all of this, and now we can go ahead and go offline, and we can access everything that was already prefetched. Sorry. I guess you want to hear one. Right? Wait, what is this? So this is already prefetched. I can access this while I'm offline. And then go ahead and go back online. And it will, well, it didn't recover quite as perfect as in my demo earlier, but not bad.

Alright. I think I have to get back to my slides so I don't take up all the time here. But I hope that showed you that you can really build instant apps. So let's just quickly get back. Let me see. I don't, I hope I don't press the wrong button. Okay. And I'm going to wrap up here really quick. So it's been quite a journey. The app ownership, we adjusted defaults, we made mistakes, and we fixed them. And now with this model, I think we really have the best of both worlds where we have these self-contained components, fast first paint, and instant navigation.

The structure the agents can work with, too. So one mental model and the same composition across the whole stack. Whatever you're building, if it's a marketing site, a blog, a dashboard, an internal tool, these patterns can scale to each of them and help you make every app as good as it possibly can be. And that is what you can do with RCS in XJS today. So if you want to check out the demo, it's here. I'll be updating it with up until the release with all the newest patterns. Check it out. And reach out to you if you have questions. And stay tuned for a very upcoming release. So thank you for listening. My name is Aura Sharf on Blue Sky Next. And enjoy the conference. Thank you.

Thank you. First of all, great talk. Thank you. The, was it instant insights? Yes. Is that new in 16.3? It's new in 16.3. I actually built most of that. Nice. It's really cool to see. Yeah, thank you. I have some questions about it too. So this first one is debugging RSCs, especially tracking hydration errors or understanding why a component unexpectedly re-renders on the server can be challenging. What improvements is the Next.js team making to simplify debugging? So do the instant insights help? Yeah. So basically we know that it's been hard to debug, especially RSCs and where they await and how to get good performance. So that is the whole point of the instant insights, to have that. When you enable caching components, you get it. And then whatever you're doing inside your app, even it's already been loaded, you will be getting these warnings for everywhere that your app is not instant. Amazing. So this next question has to do with, I guess, how errors propagate. Let's see. They're swapping around on me here. We'll just jump into this one though. So splitting data fetching and display enabled us to have simpler mental models. Think about it less time. RSC feels more complex again, coupling data and rendering. How do you think we can manage this going forward? The fact that RSC feels more complex coupling data? I think so. I think the key is there to spend some time to see what other people are doing in this app and copy those patterns to make sure you don't mess up your code base. But the goal is, at least for us, that you don't end up with these unmaintainable structures because we're forcing you to do it the right way. But yeah. Right. I mean, it was cool to see the hierarchy of what you were building. Because I mean, I typically wouldn't see an app like this built with Next.js. You'd expect to see like use query or something like that. So it seems like there's going to be maybe some patterns that come out of this in terms of how do you structure your components? How do you make sure that like lower level components do the data fetching so they can be reused? Can you talk a bit about how you got that?

So I've been working with Next.js for years and been experimenting with this. And it's just maybe recently that I've been landing on this model that I have here, which I shared on my blog and I made like a skill for it so that people could try it. But yeah, just keeping your components as independent as possible and only getting what they actually need and having them fetch their own data. It's just, that's already what you need to do. That's what already what you do with React query, right? You just give them what they need and then they fetch their own data. So basically it's the same mental model. Nice. So this next one says, would you recommend transitioning everything to server components? Would this provide a significant benefit compared to client components in an existing client-side website? Yeah. I mean, it depends on what you mean by converting everything. But if you're using Next, I would highly recommend to when we release this, try it out, try cache components and follow the release and see what you're supposed to turn on and how it works. And try converting higher-up parts of your app using this Instant Insights. And of course it's totally fine to do client-side fetching too, if you have something interact, if you have like a website or you have something that's like fetching live data. You can do that too. Most of your apps should be perfectly fine with server components with this pattern. Nice. All right, this next one is from an Angular dev. Why are you at a React conference? But just was wondering, would it be less boilerplate to add the suspense to the child component itself? So I'm guessing in your demos, you're writing suspense, you put the component inside. Would it work to put suspense in those child components? So the point with suspense, I know this is like a confusion because we're used to putting it inside the components because that's where our effects are.

We didn't really have a choice. But it's better to not... What would typically happen is you have every component doing its own loading state and it would pop up suddenly in random sequences. And that's not a good UX. So that's why when you wrap the suspense around the components, you can design the way it's supposed to load based on your designer or your requirements or whatever you want, instead of having it be tied to that component. Because the component doesn't know how it's being used. So that depends on where you're using it. And I think we saw that in your demo where you got to choose, do you want suspense wrapping both or just one of them? And I guess you couldn't do that if it was inside. No, exactly. So that's the whole point of suspense. You have this declarative loading which before, you wouldn't have that. So you can only do that with suspense as far as I know. Nice.

With PPR, the static shell is flushed before dynamic slots resolve. If a dynamic slot throws after the shell is already sent to the client, how does error recovery work? What does the user actually see? So it depends on how you want to handle error. So you might know we have file-based routing, we have an error TSX file that you can catch errors. But we also ship something or we are shipping something new in 16.3, which is kind of like the React error boundary. But for Next, so it will have a catcher and a retry that will also revalidate the server component, refresh the data, and make sure it doesn't cause any weird layout shifts or re-triggering or suspense. So that's another thing we're stabilizing now in 16.3. So that you can incrementally or granularly wrap your tree and make sure it's handling your errors correctly. Nice.

This question, I actually have this question too. Does the inner suspense wait for the outer suspense or do they start at the same time? This was when in the demo you moved suspense as a nested suspense. So since we're putting the inner server component inside, we're going to make sure we don't wait for that one before we reveal the first content. Because the first content is the most important, but we can't also parallelize them entirely. That's when we get the layout shift. So we reveal the first content and then we have another one to load that independently afterwards. I see. And I guess if you're already caching and you're using these cache things, that nested component could potentially load instantly. Oh yeah. All of my pages were like loading instantly because I put this new prefetching stuff all over my app, because typically that's what you want to do in SPA because everything is user data anyway. And then you wouldn't really see them. But if you go offline, you would see them or if you don't have the prefetch ready, you would still see them. That makes sense. Or initial load, yeah.