Skip to content

Module 4

Component API Design

One of the most common questions I've gotten goes like this:

How do I create React applications that scale?

Working in an application with hundreds of React components is a very different ballgame than working in a Todo app with 6 components. In order to keep things maintainable, we need different mental models, different tools, different techniques.

That's what this module is all about.

We're going to learn about lots of individual techniques that I've used in my work to keep complexity manageable as applications grow larger and larger.

We're also going to gain new mental models, ways of thinking that will help us make architectural decisions in our applications.

I'm super excited about this module. Let's get started!

Producers and consumers

Video Summary

  • A few years ago, I had a perspective shift that changed how I thought about architecting React applications. It's the foundation for this module.
  • Let's suppose we're building a Twitter bot that tweets AI-generated images. In order to do this, we need to interact with Twitter somehow.
  • Twitter is a closed system. We can imagine a protective dome that covers their database, their backend code, their support team, everything. We can't access it directly. But we can access the API, the Application Programming Interface.
  • A fun analogy: It's a bit like the waiters / waitresses at restaurants. In the building, there's a chef, and a cooktop, and raw ingredients, but we can't access any of that. Instead, we interact with a waiter who takes our order to the kitchen and returns with our food. The waiter is our interface to our meal.
  • The Twitter API is built and maintained by a team of developers. They work explicitly on the interface, deciding what the API routes should be, what the parameters should be, how the authentication flow should work, how much permission we have, etc.
  • They can design this interface to either be really good, or really bad.
  • The language we often see used for this idea is producers and consumers
  • This is a really common thing in software. Every time we npm install a package, we consume a chunk of code that another developer has produced.
  • A few years ago, I worked at DigitalOcean on the component library team. We built the low-level LEGO bricks, things like Button and DatePicker and Modal.
  • The realization I had is that React components are closed systems, just like Twitter.
  • Each component is a bundle of markup, styles, and logic, and from the consumer point of view, none of it is directly accessible. Instead, consumers interface with React components through props.
  • When we produce React components, we control what the props are, what the props do, what props are not included… This is a tremendous amount of power, an opportunity to make something really good, or really bad.
  • We don't tend to think in these terms because often, we're both the producer and the consumer. We wear both hats at the same time.
  • But, in a larger, long-term React project, this stuff really matters! It might take 1 day to produce a React component, but then we'll be consuming it for years and years to come. Low-level components like Button will be used constantly.
  • If we've done a nice job on that interface — if the props are intuitive and easy to use — then it'll be lovely to use.
  • It also has to do with consistency. Do our components follow the same patterns?
  • This is often the difference between a React application that feels maintainable vs. one that doesn't.
  • The consumer experience is often much more important than the producer experience, and so we should be really intentional about the way we set up the props for our components.