- Publisher |
- Sam Selikoff, Ryan Toronto
- Media Type |
- audio
- Podknife tags |
- Design,
- Technology,
- User Experience,
- Web Development
- Categories Via RSS |
- Technology
- People |
- Country Of Origin |
- USA
- Produced In |
- New York, NY
- Frequency |
- Weekly
- Explicit |
- No
This podcast currently has no reviews.
Submit ReviewRyan talks to Sam about reproducing iOS's new image background treatment for his Open Graph Preview tool, opengraph.ing. They talk about different approaches for generating gradients from images, including finding the vibrant color of an image, luminosity-weighted averages, k-means clustering, and more.
Timestamps:
- 0:00 - Intro
- 3:07 - Apple's new OG image gradient
- 10:06 - Luminosity-weighted average
- 14:22 - Finding the vibrant color of an image
- 21:41 - Contrast ratios on favicons
- 32:21 - K-means clustering
- 41:25 - Refactoring UI tip about rotating the hue
Links:
Sam and Ryan talk about React 19's useActionState hook. They discuss how adding async functions to a plain React app introduces lots of in-between states that developers must grapple with, and how useActionState allows React to collapse and eliminate these states, bringing the simplicity of React's sync mental model to our async code.
Timestamps:
- 0:00 - Intro
- 1:51 - How React normally eliminates state in synchronous apps
- 8:20 - How useActionState lets React eliminate state in asynchronous apps
- 18:17 - Why you shouldn't just pass server actions into useActionState
- 23:00 - TCP/IP and UDP analogy
- 26:39 - Thinking of useActionState like enqueue
- 34:55 - Why the term "reducer" is too loaded for best understanding useActionState
- 51:07 - How useActionState helps you build a Todo app that stays responsive during pending actions
Sam and Ryan talk about using Cloudflare Tunnel for local development, the new React Compiler beta release, and why reading or writing refs during render violates the rules of React.
Timestamps:
- 0:00 - Intro
- 1:42 - Cloudflare Tunnel
- 7:06 - React Compiler
- 14:21 - Reading or writing refs during render
Links:
Sam and Ryan talk about building a useAnimatedText hook that can animate streaming text. They also discuss how React code that uses state changes to approximate events can be simplified, and the benefits of having escape hatches when building UI with Catalyst.
Timestamps:
- 0:00 - Intro
- 1:22 - Catalyst and escape hatches
- 16:03 - Building a useAnimatedText hook (aka useBufferedText)
- 54:10 - Avoiding using state changes to approximate events
Links:
Sam and Ryan talk about how frameworks and infrastructure evolve with each other, using Next.js as a representative example. They discuss how hosting providers like Heroku have always imposed certain constraints on apps, what features those constraints enable hosting providers to support, how burdensome those constraints are across different frameworks, and how frameworks that add infra-specific APIs can best communicate the costs of those APIs and benefits they enable.
Timestamps:
- 0:00 - Intro
- 3:03 - Heroku and the Twelve-Factor App
- 7:39 - GitHub Pages and static sites
- 13:57 - Serverless and JAMstack
- 17:30 - Vercel and CDNs, self-hosting, and Next.js
- 19:00 - How framework APIs can nudge an app towards a particular hosting solution
- 23:09 - What constraints does Next.js impose on your app (e.g. middleware doesn't run node), and what benefits do those constraints give you?
- 36:13 - How Next.js APIs are motivated by wanting to tease apart static and dynamic code, in an attempt to support the needs of any web app with a single stack
- 40:33 - What is the relationship between frameworks and infra?
- 47:37 - How can frameworks that add infra-specific APIs best communicate the costs of those APIs and the benefits they enable?
Links:
Tom Occhino, Chief Product Officer at Vercel and former Engineering Director at Facebook, joins Sam to talk about the pivotal moments in React's history. He talks about how React popularized the ideas of declarative rendering and unidirectional data flow, how GraphQL furthered React's goal of co-locating all the concerns of a particular piece of UI, the problems that GraphQL led to at Facebook and how Relay solved them, and how Suspense, Server Components, and PPR are the generalized spiritual successors to the stack used at Facebook.
Timestamps:
- 0:00 - Intro
- 2:53 - Declarative rendering as React's legacy
- 8:12 - How GraphQL enabled complex components to be fully self-contained
- 20:12 - How React's goal has always been to co-locate all the concerns of a particular piece of UI
- 22:58 - The problem with co-locating GraphQL with components, and how Relay solved it
- 26:28 - How RSC is the generalized spiritual successor to BigPipe and GraphQL
- 34:46 - What PPR is, and how it and Suspense fit into this story
- 55:55 - The general paradigm shift of getting static code to the device as soon as possible
Links:
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 - Intro
- 3:40 - Where did render props come from?
- 6:01 - How hooks replaced many use cases for render props
- 8:14 - Using render props for custom styling
- 10:32 - Data attributes vs. render props for custom styling
- 16:43 - Using render props to peek into an uncontrolled component's internal state
- 21:05 - Forms example and using render props for a smaller public API
- 24:10 - React docs mention of render props
- 25:48 - Where render props shine
Links:
- Headless UI Menu
- ui.com/primitives/docs/components/form#accessing-the-validity-state-for-more-control">Radix Forms
- spectrum.adobe.com/react-aria/forms.html">React Aria Forms
- React docs - Render props
- Our upcoming course on React Component Patterns
- Email Sam
- Email 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 - Intro
- 1:41 - What are controlled and uncontrolled components?
- 6:11 - How to change a component from uncontrolled to controlled
- 8:48 - How do you decide when to use a controlled or uncontrolled component?
- 12:00 - Sortable table example and a single source of truth
- 15:27 - Is it always either controlled or uncontrolled?
- 21:09 - Color picker example and not exposing internal state
- 28:46 - Sortable list example with Framer Motion
- 39:45 - Component boundaries and wearing two hats: the library author vs. library consumer
- 41:43 - How do you know if you are using the wrong approach?
Links:
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 - Intro
- 1: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 share
- 19:36 - Using patterns that preserve React's locality of behavior
- 24:49 - How do you know if an abstraction is good?
- 32:54 - Build UI's upcoming course on Advanced React Component Patterns
Links:
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 - Intro
- 3:58 - Adapter pattern and cohesive boundaries
- 9:43 - Rails is Omakase
- 13:47 - Configurable, but still cohesive
- 17: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 matters
- 34:20 - A framework is a shell of adapters and a brain that coordinates them
- 35:16 - When using services, complexity still exists in the in-between
- 37:59 - A fullstack dev is someone who acknowledges and understands how all the parts come together
- 44:06 - Tweets about the hard problems that Laravel tackles, and the deep design it took to get there
- 49:15 - Frameworks should embrace the strengths and patterns of their language and ecosystem
- 50:35 - Why RSCs and Server Actions mean the “Rails for JS” may end up looking nothing like Rails
- 52:11 - Why users of a “fullstack framework” shouldn’t even care about where the code is running
- 55:31 - Why libraries or services that are easy to install and set up are not a replacement for frameworks
Links:
This podcast could use a review! Have anything to say about it? Share your thoughts using the button below.
Submit Review
