Why Redwood Adopted React Server Components

I get the after-lunch crowd. And that's because I'm going to make you be interactive. We're going to have a really good time. We're going to learn about Redwood.

Let's talk about the elephant in the room. Some of you don't know what Redwood is, so we're going to address that. We're also going to talk a lot about RSCs. I'm on the leadership team at Redwood. I mentioned a couple of the things I do. And the most important part of the theme that draws other things together is I love, and the teams I work with, we love to help make people successful. We love to help make others successful, so that can make the Redwood Project successful. And that's a lot of what we're doing. And React Server Components is definitely doing that for Redwood. And we're also hoping that we can move some things with React Server Components forward. But first off, let's just cut to the end here. Are we getting the... There we go. I'm going to cut to the chase. I'm actually going to tell you the point before I do any of the presentation, because who knows what's really going to happen next? All you need to remember is that Redwood is all in on React. So everything I'm about to talk about, the summary at the end is that we're all in on React, and there's a lot to come. We're really excited about what's happening with React, and that's where Red... Because of where React is going, that's where Redwood is going.

All right. Here we go. Engaging part. All right. Your journey with React. So this will require a little bit of audience participation. It's true I actually can't see any of you right now because of the bright light, so I won't know if you're participating, but I'll be able to hear, and it'll be fun, we're going to have a good time. So if you can remember way back when, I want you to reflect on that time in your journey with React very early on where you might have felt that creative possibility. Right? JavaScript ecosystem, we love these kind of things, we get really caught up with shiny things. Why? Because it gets us excited about what's possible. So think way back in.

All right. Everybody stand up. I know you have laptops. I can see the laptop. Stand up, that's good. Yeah, these people in the front, I like these guys. That's Tom by the way. All right. Stand up, that's good. I'm going to come over to the side so I can lead a little bit.

Here's what you're going to do. All right. If you were a 1, 1 is going to mean, wait, people get to be creative, right? 1 is the lowest on the scale. Could be better. Could be worse. That's medium scale. 3 is that sense of unbound possibility. Maybe not quite that high but, you know, somewhere in there. So think back when you first discovered React, interactive UIs on the client. Now, go ahead and sit down. If you were rating yourself, your relationship to creativity and unbound possibility at the If you were a 1 when you first encountered React, go ahead and sit down. Meaning like, people got to be creative? Okay. All right. Honest people. I'm not calling anybody out, but I saw that, thank you. If you were 2, way back when you first started your React journey, sit down. Okay. Good. If you were 3, you're standing up. Nice. Somebody, one person who's a 3. What was something you were really excited to do? A sense of unbound possibility, shout it out. Something you were excited to do with React the first time. Nobody. Writing a reconciler and for like, different stuff, like React 3 fiber and like, KC fiber, those technologies were really cool and sort of got me into the head space of like, you could really do anything. You could do anything. I like it. Super nerdy, great example. All right.

Okay. Everybody, stand back up. Stand back up. One more time. Now, I want you to imagine last week. Now, you're hyped up because you're at the conference, this is not about the conference, so a week ago, or the last project you were on, what was your relationship with React and the creative possibility for it, right? So, this is like a week ago. This is recent now. So, go ahead and sit down if you were a one. Oh, wow. If you were a two. If you were a three.

Okay. And then go ahead and sit down if you're a three, right? That resonates a lot with me. So, for those who didn't see in the room, most people sat down at two, right? Like, the creativity and possibility shifts over time. But, boy, howdy. I'm excited to show you what's happening with React server components because I hope we can open up for you not how server components work, nerdy, very interesting. But that's not what we're going after. What are the opportunities and possibilities we have?

Okay. So, first off, what is Redwood? Elf in the room, we don't know what it is. So, I wanted to go through these slides really quickly. Redwood is... Do we have the right slide? No, this was the slide. Redwood, when we first launched it, full stack for the Jamstack. That was true, true about three years ago when we launched. That's not as much true today. Redwood is a full stack JavaScript typeset web application framework. In the future, we're going to be the full stack web app framework. That's right. We're going for the title. And Tom Preston Warner, who conceived of Redwood, got it started. He built one of the largest Ruby on Rails apps in existence. You know? I feel like we got a contender. We're not there yet, but that's where we want to head.

First class citizens. What we mean when we say full stack, what you need to know is that Redwood is all these things get full attention, full integration. They get the status of being first class citizens of Redwood. I'm going to read these really quickly. React, GraphQL, and Prisma. We've got a test suite from front end to back. TypeScript. All those that yolo, yes, you can go strict. We have Vite CLI. You have generators. All kinds of things you can do with a CLI. Very Rails-like. Cache enabled. Out of the box. Authentication security. Redwood is secure by default. We consider separations of concerns. We have a storybook implementation out of the box. Very important for a full stack framework out of the box. And also, Redwood is full of conventions and a golden path to get you started quickly and to allow you to keep maintainability going as you scale. These are all built into Redwood. This is really important for us at React Summit. The database is a first-class citizen in Redwood. The backend server is a first-class citizen in Redwood. And another first-class citizen is collaboration. We are highly collaborative. We're working with the teams, building all of these tools every day. We're working with the React team at Meta on a weekly basis.

They're joining us for working sessions. And we do collaboration also with our community. So we invite you to collaborate with us, as well.

Redwood today. It is an independent and open source project. It is free to use. We are not making money on Redwood, which begs the question, how will we make money? We're not making money today. I don't know, Tom. Do we have an answer to that? No, we don't know. I want people to use Redwood first. It's three years old. We've got 16 plus 16K stars on GitHub. We're already at version 6.4. You can do a first-class deploy to Fastify. So we are Fastify first, so for server full. You can also deploy service-ly on AWS Lambdas. What we know of startups using Redwood and critical infrastructure, they've raised over $75 million. They are scaling. A new one coming out you should be excited about is called Puzzmo.com. That's Orta Therix, and Orta is using Redwood and Puzzmo. And it's super fun. It's a little gaming app. Think like New York Times Crossword Puzzles, only like all kinds of other things. That's Puzzmo.com. We feel that Redwood is the best in class today. SPA framework and out-of-the-box GraphQL framework. Where's my aside? I'll do an aside over here. So aside. You've been lied to about GraphQL. I know, right? What? GraphQL is not terrible. So who knew? Now, there are things that are really hard about GraphQL, but if you can implement those out-of-the-box and get started with GraphQL and make that easy, it turns out GraphQL is a really powerful tool. It's just not great for everything. Here's some full-stack features for Redwood. I could do 20 minutes on each one of these. But this is what we mean when we say full-stack. Man, I'm so excited about these! I can only show slides, but I've got a page I'm going to send to you at the end, and you can try all these things out for yourself, including our RSE experiments and demos. All right? So that's coming at the end. Stay tuned. Full-stack features, these are the new ones to Redwood, and we are super excited about them. Redwood Realtime. Redwood Realtime, without WebSockets. Ask me how in the Q&A. Redwood JS Realtime. Go to Realtime.RedwoodJS.com and we have five apps in one. You can try out our chat app. You can try out our countdown timer. These are using subscriptions and what's called live queries with GraphQL. We have tons of documentation on this. It's really fun to use. This is great.

This is using OpenAI's API. Nailed it the first time. I'll screw it up before I get done with this section. OpenAI's API. You can take a long time to get responses when you're hitting up that magical AI generator. You can pick some words and it tells you a story. It's really fun. Bed time with your kids. This one's good too. Pick two movies. OpenAI's API. Twice in a row, Jack. Nailed that.

This is also using subscriptions so it creates a movie based on a mashup. This is a bidding application using live queries. Go try those out. They're really fun. This is deployed on fly. I think that's using superbase for the back end. Highly performant. Really well.

Okay. Who knew that a mailer could be awesome? Redwood's mailer is awesome. Because it turns out, if you can actually do your templating inside of your framework and then preview those while you're doing development on them, then mail gets fun again? Who knew? So that's what Redwood mailer is. There's an API. You can selfhost. You can plug into other providers. This is Redwood mailer. And you're seeing the template preview right there. And also, we proxy the requests during local development. So you can actually send e-mails locally to test without hitting everybody up in your entire mail subscription database. Right? So no more interns will be sending their mail to everyone on the list. It's a test e-mail. Anyway, that's Redwood mailer.

Redwood studio. Wouldn't it be nice if you could fire up a local development app that gave you full visibility and introspection into what's happening at dev time. So this is showing we have open telemetry. You can actually see open telemetry traces during dev time with Redwood studio. You fire up Redwood studio by running Redwood studio. Right? So this is just available to you at the command line with Redwood. More things on traces. You can do things with Prisma. Graphical. It's all there inside of Redwood studio. Redwood studio is amazing. And this is what we mean when we say full stack. Does that make sense so far? All right. So Redwood is a full stack framework. There are some things that are hard with Redwood. It turns out we're best in class SPA.

There are a lot of use cases that we tell people not to use Redwood for if it's not SPA. Probably some of the reasons why you might not have used Redwood today.

Okay. Not everybody loves GraphQL. And I get it. There's actually some things you don't want to do with GraphQL that make it hard. I'm referring to my notes over here. One of them is... Oh, the notes are for the other... Never mind. No notes. Things that are hard with GraphQL. One, getting started with GraphQL. If you don't need GraphQL because you're a single client or small team, you don't need GraphQL for those things. And also, it turns out, there's still a learning curve. And Redwood made it really easy to start with GraphQL. We take care of all the boilerplate for you. We handle the resolvers. But it's still hard to get started with GraphQL. And frankly, this is the number one reason we think people don't use Redwood today. Is because I don't want to use GraphQL. Totally fair. Totally fair.

Another thing that's hard with Redwood is... Ah, there we go. You know what? I'll be honest. We did a good enough React implementation for Redwood because we weren't Reactive developers. Secrets out. Some of us weren't exactly Javascript developers when we started the Redwood project as well. We came from Ruby on Rails. We've done work in Python. Other frameworks. And we came in and brought the best of class that we loved and said... We want to do this inside of Javascript, and we want to do it with node. So we had a lot to learn. And frankly, we didn't do everything that this community of React developers, React first framework developers wanted us to do in Redwood. And so there's a lot of great options for the things you want to be able to do in React that are available right now. And that's why some people haven't chosen Redwood yet. It worked really well. Our conventions were amazing. But we still have some work to do.

So introducing Redwood's Bighorn Epoch. Isn't that a beautiful photo? That's really nice. So we don't do marketing around major versions. Right? So 6.7... It turns out we know the guy that did SimVer standards. So we break things. We upgrade. But we have what we call Epochs. And that's kind of our marketing and our roadmap.

And Redwood's Bighorn Epoch is happening right now. And what was the one thing I wanted you to take away from this talk? Redwood is all... All in on React. See? Jack got it. Redwood's all in on React. So guess what the Bighorn Epoch is about? Redwood's all in on React. Man! I can see you're here. I know it's... I'm blind. Anyway. Redwood's all in on React. So that means our code and our features, we're catching up to and then going beyond. We're getting up to where the React framework... Sorry, the React Roadmap is. So Redwood is all in on React. We're gonna collaborate with you all. We're collaborating with the React team. We're collaborating... We've got Lens from the Apollo team. We're working in channels day-to-day, week-to-week with people to collaborate on making Redwood be all in on React and what does that mean, and also we're collaborating with the community. So we're bringing our communities together with other communities and that's what it means for Redwood to be all in on React. You can see our Roadmap down there. If you scan that thing, it'll take you there. But go to Redwoodjs.com forward slash Roadmap.

Okay. Finally the guy's gonna talk about the thing that was in the title. Right? So all of that was what is Redwood? And also, why is — I'm setting things up here to show you why Redwood and React Server Components is a really nice fit. So why did Redwood choose React Server Components? These are the three things I'm about to talk about next. It's what comes after streaming and suspense. We built a solution for streaming and suspense. I'll show you. And it turns out if we're gonna keep up with the roadmap for React, we're in. We're in for React Server Components as is the React team. But we're just — we're on the roadmap now. Also, I believe it was Sebastian wrote an article about what comes after GraphQL. There's some things I'm gonna show you about how, when you've built a framework that does first-class citizenship for GraphQL, it turns out the concepts and some of the architectural design for RSC — it just pairs really, really nicely, because they're highly related. And then, also, we're gonna talk about this thing I'm just calling Fetch Anything for Now. I'm not gonna do a deep dive on what is RSC, how to implement it. Our belief is that the framework's gonna do a lot of that for you. You'll need to understand how it works, but I'm not gonna go into the code. I've got some more on that later. You can see how the code works. We've got some good demos. But let's talk about how the React team talks about what is RSC. RSC combines a simple request-response mental model of service-centric multi-page apps — they talked about this in the panel before lunch, if you recall — with the seamless interactivity of client-centric single-page apps, giving you the best of both worlds. Right? So, being able to shift back and forth from that server-centric model to the client-centric model and to be able to, in some cases, merge those two mental models together into one use case is really nice. I'm gonna show you what that means for Redwood.

So, first off, streaming and suspense — you probably don't know about it but Redwood has SSR capabilities. So, let me show you — we built this for the Redwood Conference, which was a month ago — this was our ticketing and badge app. And this is Redwood SSR using React streaming and suspense. We'd been working on this at the end of last year. Well, let me just show it to you, what it is, and then I'll tell you what we did with it. But check this out. Ticket.redwoodjs.com. So, it's already in there, but streamed down — that was actually a pre-rendered page. Nice little fun interactivity, right? It's your email address, and it's going to let you authenticate behind-the-scenes with GitHub. And now I've got a customized badge app. Notice I just copied that share URL, and with Redwood before, what would you expect to see here? Nothing. And what do you see now? You see all of your head OG tags. And all of that was just real time. It's that fast, it's deployed on fly, and it's using Neon for the database on this. And this is available now. So, you can do SSR with Redwood. We had a pre-render feature available before, but now you can do full server-side rendering with Redwood. We built this before we chose to do RSC. But it turns out that all the building blocks you need for RSC, we already handle those because we switched over to VEET for our bundler. We're running VEET on the server, so we have a frontend server now. We have our own router, Redwood router. We switched over and re-architected under the hood to use a suspense router. And we love what we're able to do with SSR, and RSC's a natural fit because it's going to live right on top of that.

So I talked about this before. Number two, RSC and GraphQL, like, they are very complementary both in terms of concepts, what you can do, but also because of the ways we built in conventions and this golden path into Redwood with GraphQL. RSC just makes sense in the context of Redwood, so for example, we don't need to create another router for Redwood, we'll just build RSC right into it and right on top of it.

I want to show you, really quickly, this GraphQL Fragment Pattern. This might make sense to you. For those who work on Apollo Client in the room, please plug your ears and close your eyes for just a second. And then I want to show you a Redwood implementation of Server Components with Server Actions, because I think it's true that we are the second framework to implement Server Actions behind Next. So, yeah, go Redwood. Toby, actually, go with Toby. That guy's amazing. Right, Tom? Toby's killing it.

Okay, so, real quick, let's talk about GraphQL Fragments. I know, already you're like, I didn't come for GraphQL. But this is a really interesting, high-level idea. And for those who Next and for those who Remix, this should actually look really similar. So, this is how Fragments work. This is how Relay works. You've got a parent component, and you have a root query inside of it. All the data you need for all the components on that page, you're going to go fetch it with that root component. This is how fragments work, okay? So, the parent component, it's going to go fetch the data, render, and now it has all the data it needs on the page, because it knows about these fragment queries inside of the child components, child one and child two. So, what happens? Fetch the root query, get all the data, pass those down. The fragments know what fields to ask for, so the data's there, and then in Fragments and in the GraphQL model, all of your caching, all of your updating, just happens automatically behind the scenes. Apollo Client does this really nicely. There are Redwood startups that are using this pattern at scale, and it works really well. Highly performant, blazing fast. And again, so say you update that root query with a mutation, so there's an update to the data on your page, and then everything, just in a nice little flow behind the scenes, updates and re-renders automatically. That sounds awesome, right? It can be really hard, but that sounds great. So, what if we could do that with something that wasn't GraphQL and made a little more sense inside of the React world? Well, check it out. This is, and I only get to show you 30 seconds, this is a real app you can play with later. This is Redwood server action. And a couple things I want to point out before I run the demo. Notice this is already rendering a server component and a child component. This is functionality working in Redwood right now. And what you're about to see is how we can interact with a client component. Stay on the client component and look at what happens. I'm running this now. Look at what happens with the server component, right. So the red box, outside parent is the server component. Child component, client component inside. Right, so we'll talk about a couple things here real quick. But watch, the two counters are going up separately. Did you see the fetch happen when the server component was incremented? Did anyone notice what just happened there when the page re-rendered? I'm going to run this twice. Okay, the page re-renders. That's it. And I'm going to run that one more time. Okay, couple things happen here. Actually, Tom did talk about this for 20 minutes at a keynote. I'll tell you how to get to this and go through the full presentation here. Right, there is state being managed on the client for the client component. When you fire the server action, you're seeing a fetch there, that's a server action, updates on the server, and that updates the server component, right, which then passes down in everything you need, right, both component and data is passed down from the server.

I'm going to run this one more time. So, does anyone notice what happens when the page refreshes, right? That's the mental model I want you to get. Along with this is just like magic in general. So client components being integrated. Where's the state for the client component happening? On the client. Okay? Page is about to be refreshed. Watch the server counter. Server counter did not change. Why? Where's the state for the server counter? What do we call state on a server most often? A database. All right, you're going to need a database. Redwood has a database. But isn't that amazing? Okay, sorry. I just think we think this is really cool. All right. So, anyway, it turns out that RSC goes great with GraphQL and server actions are amazing, you're going to want to use them. They're great. Okay, next up, fetch anything. We have a convention called a Redwood cell. Let me show this to you with GraphQL. Well, what happens if we create a Redwood server cell with dot, dot, dot? This is what I want to show you next. So fetch anything is going to make sense here in a second. All right. I can't even see your hands. I was going to ask you to show of hands. A Redwood cell convention is effectively a higher order component that does everything you need in one component for fetch and component state. All right, so what you're seeing here, lot of code. Very simple. You have a GraphQL query. That is your fetch. And then you have, you see, the components for loading, empty, failure, and success. Right? So all of these are handled. So the whole life cycle of state is handled inside of one client component. This is real. This is what startups are using when they build with Redwood today. This is a Redwood cell component. All right? Notice where that is. So what happens if you use a server cell. Let's just say, for example, you want to import the database client. And then instead of doing a query through GraphQL, you just do a database query right there inside of a server component. Right? This is absolutely possible. This is a big aha moment for us with Redwood server cells, maybe. This is where we're starting to think, what if. So this is possible. This is probably not what you're going to want to do. But all of a sudden, with server components, Redwood goes from GraphQL to being able to fetch from anywhere, from any data source, including just a direct data query from your database or any other data source. Makes sense? So you probably don't want to do this, though. So what's coming for Redwood with RSCs? This is huge for us, because I told you what's one of the reasons people don't use Redwood right now? GraphQL. So what happens if you don't need GraphQL to get started? Or GraphQL at all? Would you guys try Redwood then? Come on, raise your hand. I know you will. OK, OK, so anyway, thank you.

Jack is with me up here. That's good. That's good he's in the front row. So one, we're really excited about what's possible here. This is something we stumbled into. This transparent API, in addition to GraphQL, is something that we are going to figure out and make very powerful in first class in Redwood's server components.

This idea of fetching from any data source, we want to keep it sane, though, is going to make it really possible to do all kinds of things with Redwood's React Server Component implementation. And just real quick, this is how we see keeping it sane. How might your data flow? If you have a database, which you might not need a database, your services, your data for your database will go into your services. That's a concept in Redwood. We have a convention for services. That's where all of your back end logic goes. So that exists in Redwood today, your services where your back end logic will go for whatever data source you're hitting, but the data would flow from the database, in this case services. And your services, that is where the data flow would flow into your web. So you're going to be importing a function from your services. It'll be type safe across your whole app and you'll have some sane ways to work with whatever data source that you want inside of your Redwood React Server components. We're super excited about that.

All right. So a new transparent API is coming to Redwood. We don't know what the design on that's going to look like, but we'd love you tell us what you want it to do. And the person to talk to is Tom, he's in the room. So last, last thing. This is the bonus. Like this is really why Redwood, this is the why why, why Redwood's choosing React Server components. Because React Server components got us to start asking, what if? And remember that whole creative possibility thing that I talked about at the beginning? Like React Server components has been that for the Redwood team. It has caused us to ask what if. It's caused us to get really excited about, to get creative about the possibilities. It's opened up for the Redwood framework. And again, Redwood defines its success by making others successful. So seeing what startups are going to be able to do and what they're able to build, or any builder is going to be able to do with Redwood because of React Server components, like that's our jam. So we are really excited about it. So if you would do us the honor, this is a part of collaborating with the community. Like I said, this hasn't been our world, React in this community. You all have been embedded here. And you know much more deeply what's possible with React even than we do. So will you tell us, like right now? I don't know, pull out that phone or that gadget with you. And would you, like, if you're into the app forum, and your name is Twitter, that's mine, the David Price and Tom at Majumbo. Would you tell us, what's your what if? Like, what if React Server components could do bill on the dot, will you send that to us? Like, we want to know. Send it to us on Twitter. I'm also on the LinkedIn. I don't know how you tag me there, but I'm David S. Price. I'm not the baseball player. I'm not the motivational speaker from Australia. I'm not the British footballer or the US Congressman. I'm the David Price. Sounds pretentious, but just tongue in cheek. But we want to hear. Hang out with us afterward in the Q&A, like we want to know. A couple of next steps for how you can join us.

Amy Dutton, who's also on the leadership team of Redwood, she is going to be presenting a workshop in two days on Thursday. That's one of the free workshops, if you bought a ticket here. It's how to do full stack for React, but she's going to be talking about Redwood, how to do full stack React, and also what's coming with React server components. She'll be talking about that.

And then here's the thing, see that down there? Redwoodjs forward slash React Summit. That is a Notion document that has everything I just talked about in it. We have quick demos you can fire up for every React server component example we have right now. You want to play with server actions, go there. Tom did an incredible keynote at our conference. He's going to be writing. We'll have a blog coming soon. So you'll be able to see, if you want the deep dives, we're posting all that on the Notion doc. So go to Redwoodjs.com, React Summit.

And I took three minutes less than I thought I would. So we've got time for questions. We have three minutes. Thank you so much. I hope you know that we're all in on React server components. Did you get that point? Oh, sorry. We're all in on React. That's it. That's all I wanted you to know. All right. Well, there's another RSC framework out there. Yeah, Next.js. So for all these folks in the audience, is your elevator pitch on why they should choose Redwood.js over Next.js? Yeah. So let me start from here. You might end up using both. So right now, there's a lot of Next apps that are actually powered by Redwood's API. So that's a real thing. If you want to use the Vercel platform, it is impossible to beat, right? Like, Vercel's platform. So when I think of, like, what does a Next full-stack application look like? Really, it's like Next plus Vercel, right? Like, that's full-stack for Next. And I mean, frankly, they're the only one. But if you're going to start... So one, if you want conventions and you want a golden path and you want what we're calling now, like, something that Next has done really, really well is what I call hackathonability. That was in my notes, I should have got over there. Like, Redwood is not very hackathonable right now, right? But there's gonna be things you can do with Redwood out of the box with React server components that make it much more of a, like, getting started early application. So why choose Redwood? We think React server components is going to fit more naturally into Redwood than it will any of the existing frameworks right now. And one of the reasons for that you can see right now is, like, Redwood router was built for it. I didn't talk about that. You don't need another app router. Like, you're not gonna have choices. You're not gonna have to choose the page router or the app router. Like, that'll all be one thing. You can do both within one context with Redwood. Also, Redwood is, Remix is gonna have some similar challenges as well. Now they'll get there, those are all great frameworks. And then the other thing is, like, Redwood is an independent open source project, right? So I think that's gonna speak to a lot of people in terms of, like, wanting to feel like, I wanna be a part of the open source, I wanna drive some of the vision behind it. We're a lot smaller. I mean, NeXT is paving the way, and I don't wanna say anything.

We're actually learning from them how to do this, right? So to put that out there. But, yeah, if you want, it's gonna feel different. There's gonna be a different vibe, and you're gonna be able to have a different kind of participation in the community, which is something that we are all about. And you're gonna have a different feel for how you can actually influence the direction of the project, as well. So I think those are some really great reasons to get involved.

And, frankly, I don't know. I know that after the after-party, people are gonna be back in the hotel. They're not gonna be sleepy. They're gonna be like, hey, I wanna try out something. How are they gonna get started with Redwood.js? Should they go to that Notion document? Are there some good sample apps there to start with? Yeah. Like, how do they start out with this?

Thank you, Jack, that's another great question. So, right now, the best way to get started with Redwood is the Redwood tutorial, which is more like a course. It's actually amazing if you wanna learn full stack development and GRaphQL. We are in between right now. We have the same problem that the React team does on a much, much smaller scale, which is all of this is working in Canaries and Experimental. I highly recommend you go to our forums. So, community.redwoodjs.com, and that's where you'll see these examples. You'll see a forum post that's just about RSC. Toby is dropping all the development change log there. The example apps are there. So, right now, if you go to our docs, same thing that's happening in React. All of our docs are for stable 6.4. If you want to play with all these new things that are happening with React's server components, those are in our Experimental Canary versions, and all of that is happening in real-time on our forums. But that's where we're committing to the community to give you updates on what's happening right now. The best place to try those things out is drop into our forums and run through the steps and set up commands from there.

All right, fantastic. Was that a good answer? Yeah, it was great. All right. Jack liked it. Give it up again for Dave Price. Thank you. All right, buddy. Thank you.