Component

For a long time, the code behind a screen was split only by language. What was on the page lived in HTML files, how it looked lived in CSS files, and what happened when you clicked lived in JavaScript files. That is a vertical cut, so understanding a single screen meant opening three files at once.

The trouble surfaced as soon as the same button appeared in more than one place. The confirm button on the login screen, the confirm button at checkout, and the save button in settings looked identical, and their code sat in three separate places. Whoever built the third one copied the markup from the second and appended a number to the style name so it wouldn't collide.

Which is how changing one color turned into opening twelve files. A designer asks for slightly rounder corners, an engineer greps for anything that looks like a button and edits each hit, and one or two always get missed. The misses live on screens nobody visits often, so a user reports them months later. If a button costs that much, anything heavier — a list, a table — gets left alone and duplicated instead. Components are what you get when that same code is cut horizontally instead: divided by piece of screen rather than by language.

Everything a button needs goes into one file under one name: its markup, its styling, and what runs when it is clicked. Every other screen just calls that name.

Using one usually runs in four steps.

1. Define the piece. Create something called Button, and put the tags, the padding and color, and the click handler inside it together.
2. Decide what comes from outside. Labels and colors differ per button, so those are not fixed in the definition — the calling screen passes them in. Values passed this way are called props.
3. Call it where it's needed. Pass "Pay" at checkout and "Save" in settings, and one definition produces two different buttons.
4. Nest pieces inside pieces. Buttons and inputs combine into a form, a form and a heading combine into a card, and a whole screen ends up being one outermost piece.

One definition means one place to edit. Rounding the corners becomes a one-file change, and every screen using that file changes with it. The property cuts both ways: fix one place and twelve screens are fixed, break one place and twelve screens break. So the first step in editing a widely used piece is counting where it is used.

A new question arrives with the structure — where the values a piece has to remember should live. That work is called state management. Something like who is currently signed in has to be visible to many pieces at once, and when a piece at the top hands it down one level at a time, the pieces in between receive and forward a value they never use. That situation has its own name, props drilling. Two levels of forwarding is usually tolerable; by five, a change to the value's shape means editing every piece along the chain, and teams reach for a shared store instead.

Building a new screen usually starts by searching for pieces that already exist. Check whether the buttons, inputs, and tables this screen needs are already defined; reuse what is there and build what isn't. The collection those definitions live in is a component library.

Design talks about screens in the same unit. Atomic design is a method for composing screens from small parts upward, and when the parts in the design file carry the same names as the pieces in code, a designer changing one part points directly at the file an engineer has to open. When the names have drifted apart, every conversation starts by establishing which button anyone means.

It comes up in code review too. When one piece runs past 400 lines and fetches data, computes things, and renders all at once, someone suggests splitting it. Splitting is not automatically a win, though. Divide a piece used on exactly one screen into three and you have three files and a reader who has to move between them. The useful question in review is not how long the file is but how many callers it has and how many jobs it does.

"Don't build a new button — add a color prop to the existing component."

Widen the existing definition instead of shipping a second copy of the same thing.

"This component knows too much. The data fetching should move out of it."

One piece is both rendering and handling data, and the two should separate.

"The design system doesn't have this shape, so I'll make it a one-off component."

A declaration that reuse is not the intent here — this piece belongs to one screen.

At Pagedeck, Noa once proposed raising button height from 40 to 44 pixels. Theo found that the button definition lived in one place, but three screens carried buttons built separately that never used it. Moving all of them onto the shared definition took two days, and height changes have been a one-line edit ever since. The three strays had appeared for ordinary reasons — each needed one thing the shared button could not do yet, and building a separate one was faster that afternoon than extending the definition.

A common belief is that splitting code into components makes it reusable. Pulling a file out and giving it a name certainly looks like readiness. But reuse requires that the piece know nothing about the screen around it. A piece that reaches inside itself for checkout's line items cannot be called from anywhere else, and a near-duplicate appears soon after. What decides reuse is not whether the file is separate but whether every value it needs arrives from outside.

The other mistake is reading smaller as better. Once a piece passes 40 lines, splitting looks tidier — but divide a single-screen piece into six and following the flow means opening six files. The line count is not the criterion. Ask instead whether the piece is used in two or more places, or whether it does two clearly distinct jobs. Fetching a list and rendering that list as a table are distinct and worth separating; a table's header and body always change together and belong side by side.