After this lesson, you will be able to: Look at any UI and decompose it into reusable components at the right granularity, decide whether a piece of UI should be a component or a styled element, and name components in a way that a teammate could find them.
Component-driven design is the architectural shift that took the React era from "a way to render HTML" to "a way to design entire products." Treating UI as composable pieces is what makes design systems possible, what makes Figma-to-code handoff sane, and what makes a junior developer's code reviewable. This lesson takes you from "what's a component?" to confidently breaking down a marketing page into the five or six components it actually is.
Three reasons a senior engineer treats UI as components and a beginner doesn't yet. **Reuse** — a button on the homepage and a button in the dashboard are the same button. If you make them as one `<Button>` component, fixing the focus ring fixes it everywhere. If you copy-paste markup, you fix it in one place and forget the other three. **Consistency** — designers ship a design system with named components (Button, Card, NavItem). When engineers' code structure mirrors that, the implementation matches the design without ad-hoc invention. **Reviewability** — a 30-line `<UserProfileCard>` is much easier to review than a 200-line `<div>` soup. Components draw boundaries that PRs respect.
Brad Frost's atomic design hierarchy is the most common mental model. It has five levels — you don't have to fully adopt it, but knowing the vocabulary helps you read other people's design systems. **Atoms** are the smallest pieces: a label, a single input, an icon. **Molecules** are atoms grouped into a unit: a labeled input field, a search bar (input + button). **Organisms** are bigger compositions: a header, a product card. **Templates** are page-layout skeletons with placeholder content. **Pages** are templates filled with real data. Most production codebases use the middle three — atoms, molecules, organisms — and skip the page/template distinction because routes naturally play that role.
A three-step process that works on any screenshot or Figma file. (1) **Squint at it.** Identify the biggest visual blocks first — header, content, footer; nav, sidebar, main. These are your top-level layout components. (2) **Find the repeats.** Anything that appears more than once with the same shape is a component candidate. Three pricing cards, six nav links, a list of users — each repeated element is a component. (3) **Notice the same-shape-different-content patterns.** A blog post card and a project card might be the same `<Card>` with different inner content. A 'Save' button and a 'Delete' button might be the same `<Button>` with different variants.
A pricing page in plain HTML on the left; the same page mentally decomposed into components on the right. Notice how repetition collapses: three pricing cards become one `<PricingCard>` rendered three times with different props.
<!-- Raw HTML view --><header><a>Logo</a><nav><a>Plans</a><a>FAQ</a></nav></header><section><h1>Pick a plan</h1><div class="grid grid-cols-3 gap-4"><div class="card"><h2>Hobby</h2><p>$0/mo</p><button>Sign up</button></div><div class="card"><h2>Pro</h2><p>$12/mo</p><button>Sign up</button></div><div class="card"><h2>Team</h2><p>$48/mo</p><button>Contact us</button></div></div></section><!-- Same page, as components --><Header><Logo /><Nav links={[{...}, {...}]} /></Header><PricingSection title="Pick a plan"><PricingCard name="Hobby" price="$0" ctaLabel="Sign up" /><PricingCard name="Pro" price="$12" ctaLabel="Sign up" /><PricingCard name="Team" price="$48" ctaLabel="Contact us" /></PricingSection><!-- Components in play: Header, Logo, Nav, PricingSection, PricingCard --><!-- Five reusable components instead of one giant page. -->
A common trap: making three components (`<PrimaryButton>`, `<SecondaryButton>`, `<DangerButton>`) when one `<Button variant="primary" | "secondary" | "danger">` does the same job. Components share more than they differ — express the differences as props. The opposite trap: cramming every variation into one component until its props list is 30 items long. When that happens, the component is probably trying to be two things — split it. Rule of thumb: if 80% of the code is the same between two variants, use props. If only 30% overlaps, they're separate components.
Not every styled `<div>` should be a component. Components have a real cost — they live in a separate file, they create indirection, they need names. The right boundary: a component when the same shape appears at least three times, OR when the encapsulation buys you something (focus management, accessibility wiring, prop-driven variants). A one-off styled div in a single page is fine as inline markup. Don't pre-extract. Wait for the third repeat, then extract.
Open `bitree.dev` in a browser tab (or another marketing site you like — Stripe.com is a great example). Take a screenshot of the homepage. Then, in writing or on paper, identify five components: their names, what props each takes, and how many times each appears on the page.
Open the homepage of a marketing site in your browser
Scroll through the whole page and take note of every UI block
Name at least five reusable components you'd extract
For each component, list 1-3 props it would need to support the variants you see
Count how many times each component appears on the page
Bonus: for one component, sketch the markup with Tailwind utilities and prop placeholders ({title}, {price}, etc.)
Multiple options are reasonable. Pick the strongest.
Most teams hand off designs in Figma, and reading one is a core developer skill. Open the file and use Dev Mode (or the Inspect panel): click any element to see its exact CSS values (color, font size, line height, padding, border radius), select two elements to measure the spacing between them, and copy the generated CSS or Tailwind values. Map what you see to components first (find the repeated pieces), then to design tokens (the named colors and spacing), then build. You do not pixel-push by eye; you read the values the designer already set and translate them into your component structure.
Sign in and purchase access to unlock this lesson.