Frontend First

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

Discussion on Advanced Radix UI and React ARIA components. Challenges in building custom UI components. Benefits and challenges of using Framework Motion and Radix with React. Importance of learning lower-level libraries and customization using Radix. Confusion around react server components and React architecture. Exploring server-side rendering in React and understanding server components.

Topics discussed in this podcast include React Server Actions & Server Components, the SQL Injection Slide at NextConf, high floor vs. high ceiling in programming, the third phase of React, the importance of having one set of opinions, and the benefits of server actions and server components in web development.

Sam and Ryan discuss Remix's architecture and its conventions for Links, Forms, Actions, and Loaders, which eliminate boilerplate and enhance UIs using client-side React. They explore making dynamic pages, how Remix relies on HTTP for routing, backend changes with Forms and Actions, and how Remix layers React on web fundamentals.

Ryan shares details of his custom RSC implementation, discussing how Server Actions allow referencing server-side code. They explore bundling and invoking Server Actions and the security concerns associated with blurring server and client. Topics include implementing server actions, encoding and decoding arguments, and the benefits of server actions in React apps.

Ryan shares how building his own RSC implementation from scratch helped him better understand React’s new paradigm. They talk about fetching RSC Payload from a server endpoint, bundling client code, using a client-side router, and reference projects used.

Discussion on Next.js client-side cache invalidation, the difference between clicking a link and refreshing a page, and using server components for data fetching and rendering. Also explores building a Firebase site and improving data notifications, and the evolution of navigating and loading data in Rails apps using server components and suspense.