Episodit
-
Sam tells Ryan about his experience setting up an in-browser code editor with CodeMirror that he plans on using for blog posts and code recipes, as well as what he thought about using Radix Themes for the first time in earnest on a side project of his currently styled with Tailwind.
Topics include:
0:00 - Intro4:01 - Building an authoring tool with CodeMirror18:47 - Refactoring Tailwind to Radix ThemesLinks:
CodeMirrorSamâs YouTube video on Radix ThemesRadix Themes docs -
Sam and Ryan talk about why itâs better to think of throw as a general-purpose JavaScript language feature rather than something that should only be used for error handling. They discuss the ambiguity around the phrase âerror handlingâ, situations that call for dealing with errors locally vs. globally, and how throw can be useful for non-error control flow. They also discuss the problems with trying to shoehorn dynamic features into a static site.
Topics include:
0:00 - Intro4:07 - Error handling vs. throw-try/catch23:34 - Errors vs. Exceptions31:52 - How Next.js uses throw for non-error control flow40:44 - Adding a dynamic feature to a static siteLinks:
Global progress in Next.jsWhat color is your function -
Puuttuva jakso?
-
Sam and Ryan discuss the core values of the Next.js framework, and how those values motivate several of the frameworkâs design decisions. They talk about caching, why layouts donât have access to the URL, and why the router doesnât expose navigation events, as well as how developers should think about extending Nextâs functionality with their own application code.
Topics include:
0:00 - Intro2:58 - Why donât layouts re-render in Next.js?7:10 - Push-based vs. pull-based rendering8:56 - Thinking about re-renders in a pure React app11:07 - Why Server Actions need to call the revalidate* APIs12:26 - Why doesnât Next.js pass the request to every page and layout?31:40 - Immediate-mode rendering vs. âDo the least amount of work possibleâ51:54 - Is opting-in to more re-renders framework fighting?53:44 - Helping users by communicating the philosophy56:25 - Why doesnât Next.js expose global router events?1:00:17 - Why itâs important to understand Nextâs design decisions when choosing it for your next project -
Sam talks to Ryan about refactoring an MDX blog post to a React Server Component. They discuss how RSCâs ability to render server-side content with âclient-side holesâ turns out to replace MDX for many uses cases. They also talk about other tools that are (surprisingly) a conceptual subset of the RSC architecture, such as custom Webpack loaders.
Topics include:
0:00 - Intro5:05 - The Next.js happy path for MDX: Local files11:15 - Exploring remote MDX content with mdx-remote14:46 - Separating the serializable parts of MDX from the runtime imports17:13 - Realizing that RSC covers the same problem space, and ditching MDX26:50 - Exploring other APIs and plugin ecosystems that RSC could replace: Webpack loaders, next/image, and Liquid templates32:11 - Reactâs vision for RSCs35:18 - How RSCs could replace build-time plugin APIs44:51 - Replacing MDX with Markdoc, Shiki, and custom node code during renderLinks:
MarkdocShiki -
Sam and Ryan read and discuss the latest update from React Labs.
Topics include:
0:00 - Intro5:26 - Opening6:18 - React Compiler27:27 - Actions51:44 - Asset loading1:13:06 - Next Major Version of React1:15:42 - ActivityLinks:
React Labs blog postSamâs video on Strict Mode -
Sam and Ryan discuss the intuition behind React Transitions, and why Reactâs new useOptimistic hook is a good fit for building a URL-driven filter panel that stays fully responsive to client interactions.
Topics include:
0:00 - Intro1:12 - The problem: In a world of Server Components, URL updates are blocked by a server-side roundtrip10:44 - Attempted solution: Use the browserâs Native History API (history.pushState)15:03 - Realization: The source of truth flips from server to client during the transition â which is exactly what useOptimistic was designed for17:54 - Unwinding our mental model of client-first React apps by thinking about how HTML-only checkout forms work21:44 - The intuition behind React Transitions, and how they put our UI into a state of preparation30:39 - How Transitions improve upon default browser behavior by keeping our current UI 100% responsive, and how useOptimistic solves the checkbox filter panel37:46 - Ryanâs take: Itâs a bonus when tools make you feel smart, but itâs more important for them to not make you feel dumb -
Ryan and Sam discuss the purpose and usage of the useOptimistic() hook, a new experimental API from React.
Topics include:
0:00 - Intro2:18 - Problem: RSCs require a server roundtrip before the UI can be updated10:13 - Solution: useOptimistic() lets you merge ephemeral client-side state with server-side data so you can update the UI during a Server Action or Transition14:03 - How useOptimistic() avoids the notion of identity by discarding the ephemeral state after the app settles21:17 - How useOptimistic() lets you safely âforkâ state that eventually syncs with the server27:32 - Handling error states29:26 - Differences between useOptimistic() and Remix fetchers34:57 - How useOptimistic() lets you avoid managing a long-lived client-side cacheLinks:
Ryanâs useOptimistic tweetRyanâs video on React Cache: Part 2 -
Ryan and Sam discuss the purpose and usage of the cache() function, a new experimental API from React.
Topics include:
0:00 - Intro2:29 - Caching in Next.js vs. React cache()8:11 - Why React invalidates the cache for each server request14:43 - How cache() enables colocation of data-fetching code16:14 - Using cache() to share CPU-heavy or I/O-bound tasks between components19:31 - Why cache() obviates the need for context in Server Components23:19 - The danger of module scope on the server27:54 - Why cache() is implemented with AsyncLocalStorage41:04 - Why cache() is part of React48:27 - Why Server Components donât support cache()53:04 - How cache() eliminates waterfallsLinks:
Ryanâs YouTube video on React Cache -
Sam and Ryan talk about Advanced Radix UI, Build UIâs newest course. They also read and discuss a blog post that describes the RSC architecture in terms of two processes: React Server and React Client.
Topics include:
0:00 - Intro0:49 - Ceilingless libraries + Advanced Radix UI21:02 - Read and discuss: âRSC is React Server + ComponentâLinks:
Advanced Radix UI courseRadix UIRSC is React Server + Component -
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.
Topics include:
0:00 - The Most Memed Man on the Internet09:06 - High Floor vs. High Ceiling19:20 - What the Hell Is Next?23:22 - The Third Phase of React29:09 - Your App Is Not Unique35:23 - Server Actions & Server Components51:33 - CallYourMom.Com01:00:56 - Fat Models, Skinny Controllers01:14:16 - One Set of OpinionsLinks:
Samâs Next.js Conf talkReact is a programming language for UIs -
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.
Topics include:
0:00 - Intro0:31 - The Work Journal app2:20 - Making dynamic pages with Loaders8:00 - How Remix relies on HTTP for routing12:30 - Making backend changes using Forms and Actions19:41 - How Remixâs comprehension of Loaders and Actions eliminates boilerplate25:20 - How Remix layers the full power of React on top of web fundamentalsLinks:
Sign up for the Build UI NewsletterVideo on HTTP Session Cookies -
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.
Topics include:
0:00 - Intro0:52 - Ryanâs course on React Server Components3:06 - Motivating Server Actions, how to bundle them, and how to invoke them27:38 - Sending arguments via hidden inputs or closures, and security concernsLinks:
Ryanâs React Server Components course -
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.
Topics include:
0:00 - Intro2:48 - Making a server endpoint that a client React app can use to re-render the UI15:42 - How the bundling step shims Client Components during a server render with a reference that the client app can later use to execute browser code35:16 - How the React Component API unifies server and client functionality in a single composable interface38:54 - How a client-side router can render different server trees based on the URL49:09 - Reference projects usedLinks:
Simple RSCTangleVite RSCNext.js -
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.
Topics include:
0:00 - Intro1:00 - Suspense boundary identity and the Await component11:07 - How to refresh RSC using a Server Action27:17 - The difference between a navigation and a page refreshLinks:
Ryanâs Data Fetching with RSC courseRefresh App Router code recipe -
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.
Topics include:
0:00 - Intro2:53 - Rendering Server Components and the RSC payload21:49 - Composition vs. top-down data flow and the React cache53:35 - Revalidation after a user event and Server Actions1:06:37 - Revalidation after a server-side state change1:14:02 - Back and forward navigation1:21:43 - Caching layers1:30:53 - Current focus on stability, performance, education, and TurboPackLinks:
Timâs deep dive on caching and revalidatingNext.js docs on Caching -
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.
Topics include:
0:00 - Intro0:40 - Clarifying what the RSC Payload actually is10:12 - Understanding prop serialization when passing props from Server Components to Client Components23:38 - How to define TypeScript types for serialized props, and Remixâs SerializeFrom helperLinks:
Ryanâs RSC course on Build UI -
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 -
Sam and Ryan use some recent Twitter discussion on copying + pasting code (instead of abstracting it for reuse) as a springboard for a discussion about how their thinking on low-level UI components and design systems has changed over the years.
Topics include:
0:00 - Intro2:16 - Copy-paste vs. creating abstractions11:43 - How we used to build shared UI components15:34 - How we use UI components today22:42 - Is copy-paste the easiest way for developers to implement consistent design?27:41 - When should we create abstractions?37:15 - Designing copy-pasteable APIsLinks:
Danâs tweetBuild UI NewsletterSamâs Server Actions video on YouTube - Näytä enemmän