Why we build UIs out of reusable pieces.
What is a component?
A component is a self-contained, reusable piece of UI. Instead of writing one massive page top to bottom, you break the interface into smaller parts and build each one once. A comment box is a component: the avatar, the text field, the post button, and the logic tying them together, packaged under a single name you can drop in anywhere.
Think of components like LEGO bricks, but notice why they snap together. It is the stud, one standardized bump every brick agrees on, so a piece from one set fits a piece from another. A component’s props are that stud: the small, agreed-on set of inputs it accepts. Anything can use the component by supplying those inputs, without knowing a thing about what is inside it.
So a <Button> might accept a variant prop to switch between “primary” and “outline” looks. Same component, supplied different props, rendering a different result each time. Write it once; reuse it four times in a grid with four different labels.
Why it matters
Picture styling a Submit button forty times across an app by hand. A request comes in to round the corners. You change it in twelve files, ship, and a screenshot comes back with three square buttons still sitting in the checkout flow. That is the tax on copy-pasted markup: every change is a manual hunt, and the copies you miss are the ones users find.
Define that button once as a component and the math flips: you change the definition, and every place that uses it updates at once. This is the DRY principle (Don’t Repeat Yourself) applied to your UI, and it is how design systems work, a shared library of trusted pieces that the whole app pulls from instead of reinventing.
Edit it eight times
Ship a copy-pasted card in eight places, then get asked to add one line of text to it. That is eight separate edits, and eight chances to fat-finger one.
The one you missed
The single copy you forget renders last month's design right next to this month's.
Rebuilt from scratch
New features should start from pieces you already trust. Without a shared library, each one rebuilds its own modal from scratch, and the tenth still carries bugs the first nine already fixed.
Interactive demo
Before you touch it: if you switch border-radius to pill, how many of the three buttons change, and how many CSS rules does it take? Toggle disabled per button and edit the shared style, then read the two code panels.
Props Inspector
Style Editor
border-radius
size
<Button variant="solid"> <Rocket /> Submit </Button> <Button variant="outline"> <Rocket /> Submit </Button> <Button variant="ghost"> <Rocket /> Submit </Button>
.button {
border-radius: 0.25rem;
padding: 0.75rem 1.5rem;
font-size: 0.875rem;
}Try breaking it:
disabled; the other two are untouched. Same component, different props.How it works
Toggle disabled on any row of the Props Inspector, or change border-radius and size in the Style Editor. The live buttons and both code panels update together: the JSX (React’s HTML-in-JavaScript syntax) on one side, the CSS on the other.
The split between the two editors is the thing to notice. disabled is a prop, set per instance, so you can switch off one button and leave the rest alone. Border-radius lives in the shared style every instance reads, so one edit moves all three. Props vary from one use to the next; the definition underneath stays the same.
Props are inputs passed in from outside. When a piece of UI needs to remember something on its own, that is state, the next concept.
If you remember one thing
Define a piece of UI once, give it a few inputs, and reuse it everywhere, so one change updates every copy.