Episoder

  • Sam and Ryan talk about render props in React. They discuss where they came from, how Hooks superseded them for sharing stateful logic, how data attributes compare to them for customizing styling, and how for certain complex components like forms they're still a great solution for accessing slices of internal state.

    Timestamps:

    0:00 - Intro3:40 - Where did render props come from?6:01 - How hooks replaced many use cases for render props8:14 - Using render props for custom styling10:32 - Data attributes vs. render props for custom styling16:43 - Using render props to peek into an uncontrolled component's internal state21:05 - Forms example and using render props for a smaller public API24:10 - React docs mention of render props25:48 - Where render props shine

    Links:

    Headless UI MenuRadix FormsReact Aria FormsReact docs - Render propsOur upcoming course on React Component PatternsEmail SamEmail Ryan
  • Sam and Ryan discuss controlled and uncontrolled components in React. They talk about how uncontrolled components can be thought of as components that manage their own internal state, why you should model your complex React components after the simpler APIs of native HTML elements like inputs, why you shouldn't try to make components that are both controlled and uncontrolled, and why making a new component boundary is sometimes all you need to make your custom components behave more predictably.

    Timestamps:

    0:00 - Intro1:41 - What are controlled and uncontrolled components?6:11 - How to change a component from uncontrolled to controlled8:48 - How do you decide when to use a controlled or uncontrolled component?12:00 - Sortable table example and a single source of truth15:27 - Is it always either controlled or uncontrolled?21:09 - Color picker example and not exposing internal state28:46 - Sortable list example with Framer Motion39:45 - Component boundaries and wearing two hats: the library author vs. library consumer41:43 - How do you know if you are using the wrong approach?

    Links:

    New course: Advanced React Component PatternsReact docs: Controlled and uncontrolled componentsReact docs: Storing state from previous rendersEmail SamEmail RyanFrontend First on Twitter
  • Mangler du episoder?

    Klikk her for å oppdatere manuelt.

  • Sam and Ryan talk about the pattern of building unstyled components with React. They discuss why unstyled components were created, how they improve upon composition patterns from UI libraries like Bootstrap, how they can be used to share behavior and logic without prescribing any styling opinions, and how they fit into a larger collection of React patterns that can be used to build more powerful components that avoid premature abstractions.

    Timestamps:

    0:00 - Intro1:36 - What are unstyled components?2:24 - How do unstyled components improve upon earlier patterns?6:44 - Why would you want to use an unstyled component?9:58 - How can you compose an unstyled component with a styled component?16:41 - How to decide which pattern is best suited for the code you want to share19:36 - Using patterns that preserve React's locality of behavior24:49 - How do you know if an abstraction is good?32:54 - Build UI's upcoming course on Advanced React Component Patterns

    Links:

    Build UI's newest course: Advanced React Component PatternsSam's YouTube video on Recursive ComponentsEmail SamEmail Ryan
  • Sam and Ryan talk about what sorts of capabilities a tool should have to be considered a web framework. They discuss how frameworks tackle the complexity of getting different systems to communicate with each other, how good frameworks embrace the strengths and patterns of the language they're written in, and why frameworks and services are not in opposition to each other.

    Timestamps:

    0:00 - Intro3:58 - Adapter pattern and cohesive boundaries9:43 - Rails is Omakase13:47 - Configurable, but still cohesive17:04 - Frontend frameworks try to “work with everything”21:42 - Does composition mean a React framework will look different than Rails?29:29 - Why taste still matters34:20 - A framework is a shell of adapters and a brain that coordinates them35:16 - When using services, complexity still exists in the in-between37:59 - A fullstack dev is someone who acknowledges and understands how all the parts come together44:06 - Tweets about the hard problems that Laravel tackles, and the deep design it took to get there49:15 - Frameworks should embrace the strengths and patterns of their language and ecosystem50:35 - Why RSCs and Server Actions mean the “Rails for JS” may end up looking nothing like Rails52:11 - Why users of a “fullstack framework” shouldn’t even care about where the code is running55:31 - Why libraries or services that are easy to install and set up are not a replacement for frameworks

    Links:

    Sam's BigSkyDevCon talkRails is omakasePovilas' Laravel tweetMary's Laravel tweetBuild UI's upcoming React Component Patterns courseEmail SamEmail Ryan
  • Sam joins Lane Wagner in a crossover episode with the Backend Banter podcast. They talk about abstractions in frontend and backend frameworks, what JavaScript is doing differently from other languages and frameworks, why the frontend should drive the backend even if you're building in a server-side framework, and what's so special about React Server Components.

    Timestamps:

    0:00 - Intro2:12 - When abstractions leak6:37 - Recap of Sam's BigSky talk10:51 - What is JavaScript doing differently?19:10 - Why frontend frameworks should have more backend features24:04 - Strong opinions on a library level30:29 - Shipping more standardized interfaces37:06 - The frontend should be driving everything in the backend39:12 - Your types should flow from the database to the frontend, but not your product decisions46:53 - React Server Components

    Link:

    Backend Banter
  • Sam and Ryan read and discuss a fantastic interactive blog post about queueing in HTTP written by Sam Rose.

    Timestamps:

    0:00 - Intro6:57 - Queueing: An interactive study of queueing strategies9:05 - Why do we need queues?13:16 - FIFO and timing out17:55 - LIFO20:58 - Priority queues25:21 - Active queue management29:08 - Comparing queues36:32 - Conclusion

    Links:

    Queueing: An interactive study of queueing strategiesUp and Down the Ladder of Abstraction
  • Sam and Ryan discuss the new features in React 19 that will specifically benefit developers building single-page applications. They talk about how Suspense and Transitions let developers "teach" React about when their apps are in a loading or a pending state, how Client Actions improve upon using events in React 18 to handle data mutations, and how Actions enable React Components to automatically render and discard optimistic updates without any knowledge of the application's data layer. They also discuss several new Hooks like useOptimistic, useFormStatus, useActionState, and useOptimistic.

    Timestamps:

    0:00 - Intro2:19 - How SPAs are built in React 185:29 - How Suspense made loading a first-class concept in React7:48 - The problem with data writes in React 1810:37 - What are Client Actions?12:05 - What does it look like to use Actions?14:13 - What are the benefits of Actions?18:46 - How does React 19 change the Optimistic UI story?29:40 - Working with Transitions outside of Actions36:06 - The useActionState Hook37:51 - Using Transitions to keep the old UI rendered and responsive41:25 - How Transitions enable better composition patterns in third-party libraries43:55 - Building a SortableList that flips between being controlled and uncontrolled

    Links:

    React Unpacked: A Roadmap to React 19
  • Sam tells Ryan about a recent talk he gave at BigSkyDevCon. They chat about how backend frameworks are raising the ceiling of what UIs they’re capable of delivering, how frontend frameworks are raising the floor of what backend features they come bundled with, and what each community can learn from the other.

    Timestamps:

    0:00 - Intro4:23 - Recap of Ryan Florence’s talk6:49 - Overview of "High floor, high ceiling"10:02 - Cohesion is the biggest strength of backend frameworks17:10 - Why doesn’t Rails for JavaScript exist?23:48 - Locality of behavior is the biggest strength of frontend frameworks33:14 - The use of lexical scope in React50:27 - Which community is raising both the floor and ceiling the most?

    Links:

    "High floor, high ceiling" talk
  • Sam and Ryan talk about the difference between the costs of building a feature and the benefits that feature brings to our end users. They discuss how libraries and frameworks can lower the technical cost of building a given feature, how Ryan Florence framed this calculation in his talk at Big Sky Dev Con, and how sometimes developers’ opinions and tastes about tech can smuggle their way from the cost side of the equation into the benefit side.

    Topics include:

    0:00 - Intro6:53 - How Ryan Florence framed the problem in his talk “Mind the Gap”14:38 - How frontend frameworks and backend frameworks both have their own ways of crossing the network gap19:11 - How Network-Sensitive Interactions force technologies to grapple with both server and client environments23:02 - How React is trying to lower the cost of moving interactions between the server and client with Server Components and Server Actions26:53 - Why “Use the right tool for the job” doesn’t capture the dynamic requirements of living software31:53 - How discussions about the product benefits of a feature and the technical costs of that feature are often conflated with each other34:08 - A thought experiment from economics that highlights how uncertainty plays a role in the estimation of product benefits56:54 - How to think about tech choice independently of the estimation of product benefits

    Links:

    "Mind the Gap" by Ryan FlorenceZero-JavaScript View Transitions in Astro
  • Ryan tells Sam about his experiments with using the new View Transitions API in a React photo gallery app. He talks about how he likes the flexibility of the API, how to think about integrating it into any client-rendered app regardless of the framework, and how he used a Promise with an Effect to tie a View Transition to a React Transition.

    Topics include:

    0:00 - Intro1:11 - What it’s like to integrate View Transitions with React7:30 - How View Transitions work16:09 - Building a gallery that animates photos across page navigations19:38 - How to use startViewTransition for enter/update/exit animations26:52 - Using a Promise to link a View Transition to a React Transition43:02 - Do View Transitions replace framework-specific animation libraries?45:17 - Using DevTools to preview and tweak transitions

    Links:

    easings.netIonic Framework's animation curvesShu’s next-view-transitions library
  • 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 Themes

    Links:

    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 site

    Links:

    Global progress in Next.jsWhat color is your functionAlgebraic Effects for the Rest of Us
  • 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 render

    Links:

    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 - Activity

    Links:

    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 cache

    Links:

    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 waterfalls

    Links:

    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 Opinions

    Links:

    Sam’s Next.js Conf talkReact is a programming language for UIs