Nesting Components: Building Systems, Not Just Screens

WHY IT EXISTS To manage complex UIs at scale. Without nesting, a small change like a brand color update requires manually finding and editing every single instance of an element across dozens of files. This is slow, tedious, and guarantees inconsistencies will creep into the design.

THE MENTAL MODEL Think of it like building with Lego. You don't build a car model from raw plastic; you assemble it from pre-made, reusable parts like wheels, a chassis, and a steering wheel. In UI design, you don't build a complex card from raw shapes and text; you assemble it from pre-built Button, Icon, and TextField components.

HOW IT WORKS You create a 'child' component, like an Icon. Then, you create a 'parent' component, like a Card. Inside the Card's design, you place an instance of the Icon component, not a raw vector shape. Now, any change to the main Icon component will automatically update inside every Card instance. This also unlocks instance swapping, which lets designers easily switch the nested icon for another one (e.g., a 'settings' icon for a 'profile' icon) from a dropdown, without rebuilding the card.

WHEN TO USE IT Use nesting when building any element that is composed of smaller, reusable parts. It's the foundation of a scalable design system. A Header component might contain a nested Logo component and a Navigation component. A Modal might contain nested Title and Button components. If an element appears in multiple places and must remain consistent, it should be a component that can be nested.

WHEN NOT TO USE IT For truly one-off compositions that will never be reused or need systematic updates. However, the more common mistake is the opposite: not nesting when you should. The main challenge isn't if you should nest, but what to nest. The decision depends on your team's needs and the structure of your design system. If you're unsure, lean towards componentizing; it's easier to detach an instance later than to retroactively create components from hundreds of static designs.

ONE CANONICAL EXAMPLE A habit tracker card in an app. The main Card is a component. The icon inside it is not a simple vector, but an instance of an Icon component. This allows two things: first, if the icon style changes across the app, you only update the main Icon component. Second, you can use an instance swap property on the Card to change the icon for different habits (e.g., a book icon for reading, a shoe icon for running) without creating dozens of card variants.