State-of-the-art React Server Components Developer Tooling

♪ Hello everyone. Thank you so much for deciding to spend this time with me here. As you heard, my name is Toby, or Toby, which apparently means bathtub in Dutch, I learned yesterday. Is this funny? Yeah, so Redwood, I don't think I actually saw any hands in there when you asked, so... Redwood is a super-productive framework for building full-stack JavaScript, TypeScript web applications. This is Redwood Studio. It's a companion app that you have access to with every Redwood app that you build. It's a collection of useful tools that you as a developer can use.

Right here, we see the main dashboard with some performance graphs. If we look at the navigation menu, you can see what else is available. We have OpenTelemetry monitoring. There's a section for some GraphQL tools. We have the database section where you can see your database schema in a graph, so like an ER diagram, and we use Prisma as our ORM. By going here, you can see the actual SQL statements being sent to your database.

Next up, we have the mailer integration. So, when you run Studio, you have your own dev time email inbox, so when you work on any features of Redwood where you send emails, you never run the risk of sending test emails out to actual customers, because they will all end up here in Studio. And you can also preview your email templates.

Then we have the RSC section, which is what we're going to talk about today. But finally, I just want to mention SSR, where you get a preview of what your different pages will look like when you share them on social media. And finally, there's just some Studio information at the bottom there.

Before I jump into the RSC section, I just want to make sure that we're all on the same, like, kind of baseline level of knowledge about React Server components. I mean, this is React Advanced, and you have all decided to listen to a talk on React Server component dev tools, so I guess you have some sort of idea about what React Server components are. But just quickly, React Server components is a way to execute React components on the server in a server context. Like, we've been doing React components on the server for a while with SSG and SSR, but that has always been in a client or a browser context. And all those components are then also sent to the browser and executed in the browser as well. With server components, they're only ever run on the server in a server context. And then the result of running those components is sent to the client with this new format known internally as Flight, but more commonly known as the RSC payload. It's a new-aligned, delimited, JSON-ish kind of format.

So now that you know that, if we go into the first item there in our RSC, part of the menu, we have the cache. And right off the bat here, you can see this RSC payload format as the cache values. The cache key, I don't know, it's too small for you to see, but the cache key is the URL on the page that you're visiting, and the value is, as I said, the RSC payload. Caching is difficult. Caching on the server is difficult. Caching on the client is a little bit more difficult. Cache invalidation on the client is super difficult from a framework perspective. So I knew that as soon as I started implementing caching support on the client, I needed to build, or I wanted to build some dev tooling around that. So that's why I added this. Honestly though, we hope that we can ship without RSC client-side caching.

We think that as a developer, you have much more control if you can do the caching on the server, especially around caching validation. Maybe we make it opt-in for routes where you know that it would really make a difference. But if we do, we're definitely also going to make the caching validation strategy configurable for you as a developer. But yeah, hopefully we can ship with just server-side caching and then just do normal, state-wide validating logic on the client. And hopefully that will give a good enough user experience.

This is client-side caching, and more specifically, full-page client-side caching. So the cache entry is actually much, much longer than what you can see here. It's the entire page payload that is cached. I have some other ideas around more focused caching, like more granular just for data fetching. In current Redwood, we use GraphQL, and we have the Apollo Client cache. It's super powerful. And it would be interesting to see if there are any concepts from how the Apollo cache works that we can apply to data fetching with Rack Server Components. Maybe there's something in the back of my head here around RcIslands, but now I'm just mostly dreaming. So take it down a notch and keep going with what's actually possible and available right now.

This is the third... Sorry, this is the last page. We had cache, then we have RcPayloads. We're going to skip that for now, because that's the juicy part, and do render routes. This is the feature that we have the most work left to do on. But the idea is that you have a list of all your routes. When you click on one of the routes, you get a graph of all of the components that are visible on that page. And then we can highlight what components are rendered as server components and what components are rendered client components. We think that this can be super helpful, especially from an educational standpoint, because we, as a framework, we feel that we need to educate our users, but also for app developers and team members on your team to quickly see what components you have on your page and where they render.

This actually started out as a simple Excalidraw graph like this. I drew this graph a long time ago when we first started exploring Rackstar components within Redwood. So at the top, you have the page components, example page. And then that is a server component. And everything below in orange is also server components. And then I can probably guess the blue parts are client components. The aha moment here, or what you can see, is that as soon as we switch over to client components, everything below that is client components. But there's one important thing here. This means that the blue components are imported from other client components. It's the import. It's where a component is imported that is important. Having a graph like this makes it easy to see if you have components that you thought were only ever rendered on the server that are now being rendered on the client. Like, if we look at number.txt here, for example, that component is rendered on the server under data display. But it also renders a client component at the bottom. I mean, there's nothing wrong with this. This might be exactly what you wanted. But if you thought that it was only rendered on the server, having a graph like this can be really eye-opening for you. So if you wanted it to be a server component only, only ever rendered on the server, you can definitely do that. What you would have to do is move the import, because right now it's imported from td.tsx, but if you move that import up to where the graph is orange, so, for example, in table data cell, you would have a graph that looked like this instead. So now it's a server component that is passed down as props to td and then rendered to the screen. So this is the kind of graph that I want to have in the middle here.

There's still a lot for us to figure out to make that possible, but that's the goal here.

And now the final part of our RSC tooling, the RSC payload. Before I dive into this section, I want to pause a little bit and say that as a framework, we write a lot of code, of course, a lot of glue code between different libraries that we integrate. But we also depend on a lot of code that other people have written, so I want to take this opportunity to give a special shout-out to Alvar Lagerlöf, who is here in the audience today. The RSC payload part of Studio would be nowhere near as good as it is if it wasn't for the awesome work that Alvar has done on his RSC partial library. So thank you, Alvar. And actually, yeah, why don't we give a huge round of applause? A huge round of applause. Not just to Alvar, but to all of the open-source maintainers whose work benefits us all daily. Thank you. Thank you, everyone.

So back to the RSC payloads page. Up top, you see a timeline of all of the RSC responses that the app has received. And then below, there's a list of all those same responses as well. I'm going to focus on the fourth one from top. The key is the slash, so this is for the root page or the home page. So if I click on that in our dev tools here, I'm taken to this page. Starting in the top right corner, we have the raw RSC payload. There are ten lines of this new line delimiter JSON-ish kind of format there, each line representing one chunk of the home page. On the other side, you have a circle diagram. And in that circle diagram, you have all those same ten chunks. And we can immediately see that there's one chunk, the green one. That's like half of the payload size. So that might be a chunk that we want to dive into a little bit deeper. Below, below the circle diagram, those same chunks are also available. And you can get a name for them. So the green one, you can probably not see, but the green one is called model zero. Going back to the other side again, below the raw RSC payload, we have some statistics. So this is useful if you compare different payloads. What we see there or what is available there is the render duration. So you can see, okay, how long did it take for the server to render this server component? And you also get the payload size.

Like how big is this payload in total? And that might give you some insight into, okay, wow, this is really big. Why is this component so big? Maybe there's some data there that we don't need to include in the initial RSC payload. Maybe we can lazy load it on the client later for some speedups.

All right, so let's dive into the big one, the green model zero one. If I click on that one, I'm taken further down the same page to this view. What we have up top there is just that single chunk line from the raw payload. It's super wide and very difficult to read. So right below it, we have a 3D printed version of it, the same payload. It's also still kind of hard to read because instead of being super wide, now it's just super long instead. But what's neat about the 3D printed version is that it's interactive. You can click here.

So what I can do is I can collapse the top div element, the first div element there, and see that we have this. So now, just a fair warning here, you're going deep. This is on a technical framework React internals level, but what we have here is in the 3D printed version we have an object with a key of __rwjs__routes. That's just me making sure that I'm not overwriting anything. This is unique to Redwood. And then we have the entire chunk. You can see that this big chunk was just one big div element with a bunch of nested elements inside.

So in the payload, we can see... Here we go. So in the payload we can see in green, in the preprinted version, you see class name and then navigation layout.

And remember that I clicked on the fourth item from the top with just a slash with a root URL, and that maps to the homepage. And that's what you possibly, at least if you're in the front row, can see in this route file at the top there. You have a route definition for the slash path, and then that maps to the homepage. You can also see in the route file that up top there's a navigation layout that wraps all of the pages. So what the router will actually render here is the navigation layout and then the single page that mapped to the URL we're currently on. And what we can start doing now is mapping what we have in the payload with what is actually rendered. So in the payload, we can see... Here we go. So in the payload we can see in green, in the preprinted version, you see class name and then navigation layout. And if you look closely in the raw output, you can see that also in the middle. So that corresponds to each other. And if we look at the actual implementation of the navigation layout, the source code, we can see that it has the same class name right there. And below it, there's a standard HTML nav element. That's also available in the payload. That's like at the end of what we can see in the raw output. And then also in the preprinted version. So now you can start getting a sense of how the payload works. It's basically just a more compact version of your raw JSX. And then there are some blue nodes there. I will get into them in a second. But first I want to show you one more thing. And to do that, I need to go back to this view. So all of the payloads are mapped to something that looks like a URL. But there's one that stands out. In the middle, right below the one with the tick, there's one that's different. If you can't read it, it says RSA action 0.mjs and then a hash and then an identifier which is on send in this case. So because it's different, of course, we need to look into that. Why is that different? What is that? So I click on it and I come here. And it looks pretty much exactly the same as for the home page that we just looked at. There's still this big green one for model 0.

So I'm going to keep going into model 0. It's still the same. But now if I collapse all of the elements inside the div, we get here. And now we can see there's actually one more. There's a new thing here. So let me zoom in. If you look at the preprinted version here, you see the key is still for routes and the div with all of the nested elements. But below it, you have something called RSA data, hello world, et cetera. So this is how I have chosen to implement support for XServer actions. When you execute the server action, you get the result of that action execution. The return value of your action or your function, you get that returned.

But also you get the whole page again that you're currently on. So if your server action updated a value that is part of some of your server components, you get that as part of the return value as well. And you don't get just the return value, but you also get the entire page rendered with this value already updated in the page.

So now we can just ask React to take the updated payload and do a virtual DOM diff to what it's currently rendering on the user's browser and just update the value that was updated by your action. This saves us from doing another round trip to the server just to get the updated value.

Okay. Now let's keep going again, expanding the div there. Now going more deeply into the nested objects, we see these blue nodes again that I promised I would get back to. We have two. That says LazyNode, and this is how React knows to lazily load one of your client components. So remember the RcPayload is all about the server components. And you need a way to tell React to load client components as well, and that's how that worked. There's a LazyNode thing in the payload. In the middle, we have a server reference. And these blue nodes are all clickable, so I can click on one of them. I click on the server reference, and it would take me to that part of the payload.

If you look at the preprint version here, you can see it's a long file name. And at the end of the file name, you see rcActions0, mgs, hash, and then the ID onSend. And now we actually come full circle, because that's exactly what I clicked on right here. So this is how you can navigate and explore your RcPayload inside Redwood Studio. And all of the tools that I've shown to you here today have been immensely useful internally on the team for us to get a better understanding on how React server components work. And they have been especially useful and especially educational for us who have been part of implementing this. That's mostly been me and another guy on the team named David Cyruson. Redwood is open source, and we're always looking for contributors. So if you also want to be a common Rc expert, I can really recommend that you help us flesh out the missing features here. And I will personally help you get a PR merch for Studio, if you're interested.

That's all I had to say. Thank you so much for listening. Thank you. We're going to jump into the audience questions.

First question is from Lazlo. Are these React server components tools available outside of Redwood JS Studio? Yes and no. So the library that I used that Alva wrote, that's available to anyone. It's actually available as a plugin that you can enable in Chrome. So you can inspect the payload for any page that uses server components. The rest is for Redwood Studio only. But who would use that outside of Redwood Studio? Exactly. And since Redwood, it's backed by Preston who was at GitHub, one of the founders, right? Yeah, he founded GitHub and sold it to Microsoft. And so it's been around for like four or five years now, but it's not gaining the traction that I would expect it to be with that backing. But what are some of the users that you know that you think, well, I can't imagine user x company x is using the product that I'm working on?

So what's the question again? Basically, advertise your users that you're proud of. So I think Redwood is definitely the best framework out there if you want to get started on a full application as a small team or even a single developer. I can see that it's difficult to adopt if you already have an existing backend because we are a proper full stack framework. We have a database, proper backend, currently a GraphQL. But also a frontend framework. It doesn't really make sense to just use the frontend part of Redwood. You need to kind of buy into at least the backend, but ideally that backend plus the frontend. And I noticed you now said we currently have GraphQL. And you also mentioned that while you were still speaking. Does that imply you're investigating something else or am I?

Yeah. So going forward, we want our React components to be the default for sure, for data fetching and for the backend. But personally, I also don't want to leave our current GraphQL users left behind. But the feedback that we've gotten is that GraphQL is too complicated, especially if you just want to quickly get started. So we're trying to focus more on, as I said, a single developer or a very, very small team or some just hackathon users or something that you work on on weekends and evenings. So we want to have something more simpler. And I think that with React components, we can definitely make something that is much, much more simple to get started with. Then we can offer GraphQL as something that you can enable later when you need it, if you need it.

So you want to lower the barrier of entry, but not lose the power that you have. Exactly. So for example, if you need a mobile client, if you need an app, you probably need a proper API as well. And then we think, yeah, GraphQL is perfect for that.

Cool. Another question from Laslo. What was the biggest aha moment you learned about React Server components while implementing these tools? The payload format is actually very flexible. And this aha moment came when I needed to implement server actions. I didn't realize that I could just add another item to my ... Or actually, that I could send back an entire object and have one key for the payload and another key for the server return value or return value. I thought it could only be like the serialized components. But now, anything that can be serialized can be sent as the payload.

Yeah. It's quite powerful. Yes. Luckily. A question from Anonymous. Was it hard to figure out how to implement server actions? Yeah. So if you saw the talk earlier about Wacko, we definitely have the same challenge as he has. He showed five different ways that people can define server actions. But when you actually get into parsing the components to find them, there are at least twice as many. Because at least the way that we do it, or that I do it, is I parse the AST. And when you have a function, you can have either an error function or a normal old-school function. And they need to be handled. Because they're two different entities in the AST. So you need to handle both of them. So for everyone, there's always two different versions to write it. So yeah. At least ten, if you count different ways people can write it. Just ten.

Yeah. There's multiple ways to roam, but that's a lot.

Next question is from Amir. Are you trying to be the Laravel of JavaScript? We are. Yes. Or Ruby on Rails, if you will. Cool. If there's any more questions, then keep them coming, please.

So if you have an elevator pitch, because we have one minute left, to use Redwood in someone's next project, what would it be? I think I've already mentioned it. But getting up and starting with a new project as quickly as possible. That's definitely where Redwood shines. I don't know if you all have watched any of Jason's YouTube videos where he had people come and build the same thing with different frameworks. We had one of the team members, Amy, was part of that show a little while ago. And yeah, I think she did very well on the show, thanks to using Redwood. We definitely do compete with Laravel and the other proper full stack frameworks in terms of productivity.

Very cool. All right. That's all we have. And that's all the time we have. So everyone, please give a warm round of applause for Toby. Thank you.