All articles
Frontend6 min readFebruary 15, 2026

Thinking in Components: The Mental Model Behind Modern UI

The hardest part of learning React isn't the syntax — it's learning to see a UI as a hierarchy of composable pieces. Here's how to develop that instinct.

Thinking in Components

When most people start learning React, they spend their time mastering JSX syntax or learning how hooks work. These are important — but they're not what separates developers who build great UIs from those who struggle.

The real shift is learning to see in components.

The Core Idea

Every UI can be decomposed into a hierarchy of pieces. Some pieces are primitive (a button, a label, an input). Others are composed from primitives (a form field = label + input + error message). Others are even higher-level (a checkout form = multiple form fields + a submit button + validation logic).

React forces you to make this decomposition explicit. You can't build a blob of UI and call it done — you have to decide where one component ends and another begins.

This is a feature, not a limitation.

How to Identify Component Boundaries

The single responsibility principle is your first guide: if a piece of UI does one thing, it's probably a good component.

Ask yourself:

  • Reuse: Does this UI element appear more than once, or might it in the future?
  • Complexity: Is this section of code getting long enough that it's hard to scan?
  • Data boundary: Does this piece need different data than the surrounding UI?
  • State isolation: Does this piece have internal state that nothing else cares about?

If you answer yes to any of these, extract a component.

The Hierarchy

Well-structured React apps have a clear hierarchy:

App
└── Layout
    ├── Header
    │   └── Navigation
    └── Main
        ├── CourseList
        │   └── CourseCard (×N)
        └── Sidebar
            └── FilterPanel

Each layer knows about the layers below it, but not the layers above. Data flows down; events bubble up.

The Trap: Premature Extraction

New React developers often go too far. They extract components before they need to, creating abstractions for one-time uses.

The rule: three or more uses justifies extraction. For one-off UI, it's fine to keep it inline.

Practical Exercise

Take any web page you use daily. Open it up and mentally draw boxes around the components. Then draw smaller boxes inside those boxes.

Notice:

  • Which pieces repeat?
  • Which pieces could change independently without affecting the rest of the page?
  • Which pieces group data that belongs together?

Do this exercise ten times, and you'll start to see in components automatically. That's when React starts to feel natural.

Summary

The component mental model isn't about React — it's about how you decompose problems. React just makes that decomposition explicit and composable. The developers who become great at React are the ones who invest in this thinking, not just the API.

reactarchitecturecomponentsmental-models