Nested Components
Nested components are components that contain other components as children. A card component might contain a header component, a body component, and a footer component. A navigation bar might contain multiple button components and a logo component.
Nesting mirrors how real interfaces are structured and lets you build complex layouts from simple, testable pieces.
How nested components reduce prototyping complexity
Without nesting, complex interface elements are built as flat collections of layers. A data table with sortable headers, row actions, and pagination is one giant element with dozens of tightly coupled layers. Changing the header style means finding and editing layers buried in the structure.
With nesting, that same table is composed of a header component, a row component, and a pagination component. Updating the header style means editing one small component. The change propagates to every table that uses it.
Nesting also enables mix-and-match composition. The same row component can appear in a table, a list view, and a search results panel. The same pagination component works for tables, card grids, and activity feeds.
Building with nested components
- Identify the smallest reusable pieces in your interface. These are your leaf components — buttons, icons, labels, status badges. Build and test these first.
- Compose leaf components into mid-level components. A form field component contains a label, an input, and an error message. A card component contains a title, body text, and an action button.
- Compose mid-level components into full interface sections. A checkout form contains multiple form field components arranged in a layout. A dashboard panel contains multiple card components in a grid.
- Define override points at each nesting level. The top-level component should expose overrides for the most commonly customized properties of its children, like card title text or button label.
- Test nested components in isolation before using them in screens. Open the source component and verify that all child component overrides work correctly and transitions between states behave as expected.
- Document the nesting hierarchy for the team. A simple diagram showing which components contain which children helps team members understand the structure and know where to make changes.
Nesting pitfalls that slow teams down
- Nesting more than four levels deep. Each level adds rendering overhead and makes the component harder to understand. If you need deeper nesting, reconsider the component architecture.
- Exposing too many override points from deeply nested children. A top-level component that surfaces twenty overrides from three nesting levels is overwhelming. Expose only the overrides that instances actually need.
- Changing a child component without checking how it affects all parent components that use it. Nested changes cascade upward, and a small change at the leaf level can cause unexpected visual shifts in complex compositions.
- Creating nested components that only make sense in one parent context. If a child component is never used outside its parent, it probably should not be a separate component.
- Not testing state transitions across nesting boundaries. A button state change inside a card inside a list needs to animate correctly at every level. Test from the outermost component.
Measuring component architecture efficiency
- Average nesting depth: The mean number of nesting levels across all components. Keep this under three for most projects.
- Component independence: The percentage of child components that are used in more than one parent. Higher independence indicates good decomposition and reuse.
- Override utilization: The percentage of exposed override points that are actually used by at least one instance. Low utilization means the override surface area is too large.
- Render performance: The time to load and interact with screens that use deeply nested components. Track this to catch performance regressions before they affect testing sessions.
When nesting is the right pattern
- When the interface element you are building has distinct subparts that could reasonably be used independently, like a media card with a separate image, title, and action section.
- When you need to create variations of a complex element by swapping internal parts. A product card and a team member card might share the same card shell but have different internal components.
- When building a design system library where composition flexibility is important for covering diverse use cases across projects.
- When prototyping data-heavy interfaces like tables, lists, and dashboards where consistent row or cell formatting matters across hundreds of data points.
Key concepts
- Nested component: A component that contains other components as children, creating a hierarchy that mirrors real UI structures like cards, lists, and navigation.
- Composition: The practice of building complex interface elements by combining simpler components, enabling modular construction and easier maintenance.
- Depth limit: The maximum nesting level supported before prototype performance degrades. Keeping nesting shallow improves both performance and maintainability.
FAQ
- How deep can nesting go? The practical limit is four to five levels deep. Beyond that, prototype performance may degrade and the component hierarchy becomes difficult to maintain.
- Can I override properties of deeply nested children? Yes. Overrides cascade through the nesting hierarchy, so you can customize any level from the top-level instance.
- When should I flatten nested components? When the nesting structure mirrors implementation architecture rather than serving prototype interaction needs, or when performance becomes noticeably slow.
Next steps
Identify the most complex component in your current prototype and refactor it into nested sub-components using the patterns above. Test whether the refactored structure is easier for your team to understand and modify.