Thinking in components

One of the hardest shifts in frontend development is moving from "pages" to "components". It's not just a technical change — it's a different way of thinking about structure.

When you think in pages, your mental model is a flat document: a header, some sections, a footer. When you think in components, you're thinking about boundaries, responsibilities, and composition. A button isn't just a styled element; it's a contract with props, states, and accessibility concerns.

The best components are small, focused, and reusable. They don't know too much about their parents, and they communicate clearly through props and events. The worst components are grab bags of unrelated logic that become hard to change without breaking something.

A useful question I ask myself: "If I handed this component to another engineer with no context, would they know how to use it?" If the answer is no, I probably need to simplify the API or split it into smaller pieces.

Component thinking takes practice, but once it clicks, the codebase feels lighter. Every feature becomes a matter of composing what you already have, and the UI starts to feel like a system rather than a collection of pages.