Atomic design, proposed by Brad Frost, gives teams a shared vocabulary for thinking about UI composition. Atoms are the smallest UI building blocks: a button, input, icon, or single token, not useful alone but combined into molecules. Molecules are small groups of atoms that work as a single unit, such as a labeled input with helper text and an error message. Organisms are complex UI sections composed of molecules and atoms, such as a navigation bar, card grid, or checkout form. Templates are page-level layouts that arrange organisms with placeholder content, and pages are templates populated with real content that users actually see. This bottom-up framing helps teams discuss UI at the right level of abstraction, while the pattern vocabulary above it captures higher-level solutions made of multiple components working together for common use cases.
Component API design is the practice of defining props, states, and variants so components are flexible without becoming confusing. A few habits separate good APIs from bad ones. Variants should be limited intentionally because too many make the system harder to learn, maintain, and use consistently. The prop count smell warns when a component has too many props, often more than ten: it is usually trying to be many components and should be refactored with composition. The boolean prop trap encourages replacing boolean toggles with a string enum so options remain readable and extensible. Conventions like a consistent named size scale, with tokens like xs, sm, md, lg, xl, reduce cognitive load across the system. An as prop supports polymorphism by allowing the rendered HTML element to change, for example, rendering a button as an anchor, while preserving styling.
Modern systems lean on composition over configuration. Compound components share context across subcomponents like Tabs.List and Tabs.Tab, producing a flexible and intuitive API. Slot patterns accept named children slots so consumers can compose flexibly without exposing every prop. Render props are a function-as-children pattern that lets consumers control rendering while inheriting behavior, powerful but less idiomatic in modern React. Headless components ship only behavior, including state, ARIA, and keyboard handling, with consumer-supplied markup; this is the pattern used by Radix UI, Headless UI, and Reach UI. shadcn/ui extends this with copy-paste recipes built on Radix and Tailwind, designed explicitly for deep customization rather than as a traditional library. Styling choices also matter: utility-first frameworks like Tailwind CSS compose design via class names, CSS-in-JS solutions like Emotion and styled-components provide flexibility at runtime cost, CSS Modules offer locally scoped CSS as a middle ground, and zero-runtime tools like Vanilla Extract provide type-safe styling compiled at build time. Open Props offers a collection of CSS custom properties forming an open-source design token set. Modern systems often blend approaches rather than pick one, and the utility-first debate increasingly resolves into a question of which blend fits the team's workflow. System components serve many products, while product components serve one and are usually built on top of system primitives.