Ian Landsman & Aaron Francis join Sam to discuss React Server Actions & Server Components, why it's important to have one set of opinions, and yes, the infamous SQL Injection Slide at NextConf. This is a crossover episode with the excellent podcast [Mostly Technical](https://mostlytechnical.com/).

Sam and Ryan talk about the key parts of Remix’s architecture in the context of the Work Journal app from Build UI’s latest course. They discuss how Remix’s conventions around Links, Forms, Actions, and Loaders allow developers to eliminate boilerplate and take advantage of the best HTTP has to offer, while still providing a seamless way to enhance their UIs using the full power of client-side React.

Ryan continues to share the details behind his custom RSC implementation. He talks with Sam about how Server Actions allow the client to reference server-side code (in the same way client components allow the server to reference client-side code), how Server Actions are bundled and invoked, and the security concerns associated with blurring the lines between the server and the client.

Ryan shares how building his own RSC implementation from scratch helped him better understand React’s new paradigm. He and Sam talk about how a client React app can fetch an RSC Payload from a server endpoint to update the UI, how an RSC server renders and bundles Client code that’s part of a Server Component tree, and how a client-side Router can be used to fetch new RSC trees based on the URL.

Ryan and Sam talk about how to invalidate Next.js’ client-side cache when a different session makes changes to backend data, and ultimately discuss whether clicking a link to a URL vs. hitting refresh on that same URL should render the same page if no backend data has changed.

Tim joins Sam to talk about his work on the new app router in Next.js 13. He explains how the app router leverages Server Components and React’s new cache API to bring a new level of composability to server-side code, how Server Actions are being designed to enable partial revalidation in a single round trip to the server, and how to think about UI updates as a result of server-side state changes.

Sam and Ryan discuss how TypeScript helped them understand the mechanics of how props get passed from Server Components to Client Components, and how to properly type client component props if the prop starts out as a rich data type on the server. They also clarify some points from last episode’s discussion about the RSC payload.

Sam and Ryan explore different ways to think about the RSC architecture, including what problems RSC solve, why RSC are valuable even in a world without server-side rendering, and how React’s reconciliation phase enables RSC to make partial updates to the UI as a result of server-side events.Topics include:0:00 - Intro5:45 - What if RSC were introduced before SSR?10:54 - What does it mean to render RSC?25:41 - Why SSR does not apply to Server Components35:31 - Server-driven UI updates

Ryan shares his thoughts on how Server Actions and the useFormStatus hook are letting him build reusable pending UI for any form in his Next.js side project. Sam talks about how TypeScript prevents an entire class of data-loading bugs that have plagued single-page applications built with a client-side cache.Topics include:0:00 - Tailwind Connect2:38 - Using TypeScript to prevent data-loading errors19:27 - Building reusable form UI with Server Actions and useFormStatusLinks:Server Actions in Next.jsStyling a Radix Dialog with Tailwind CSS

Sam and Ryan share their thoughts on the recent React Roundtable with core team members Sebastian Markbåge and Andrew Clark. They talk about the evolution of Server Components from the perspective of solving the problem of fetching data in React apps, how SPAs have a lower baseline but higher ceiling in terms of the user experience they can deliver, and what they’d like to see from frameworks that are built on the RSC architecture.Topics include:0:00 - Intro0:36 - Recap of Server Components as a solution to data fetching in React11:47 - How Server Components improve the baseline user experience of React apps while also letting us layer in SPA-like enhancements20:11 - What features we give up with server-driven data fetching, and how can we get them back?29:13 - How RSC and Actions bring the setState-and-diff model across the network31:59 - What opinions are left to frameworks that are built on the constraints of RSC, and what would we like to see from them?Links:React Roundtable with Sebastian and AndrewBuild UI Newsletter