Frontend First Sam Selikoff, Ryan Toronto

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.