How React Thinks

The mental model. Component trees, data flow, when to split things apart, and how to design a screen before writing a line of code.

Knowing what components, props, and state are is not enough. You need a mental model for how they fit together. Without a mental model, every screen feels like solving a new puzzle. With one, you can look at any design and immediately see the structure behind it.

This lesson gives you that mental model.

The Component Tree

Every React application is a tree. At the top is the root component — usually called App. Everything else descends from it.

Think of it like this — A React component tree is like an Excel workbook. The workbook is App. Each sheet is a major section. Each named range is a component within a sheet. Charts reference named ranges. Named ranges reference raw data cells. The hierarchy is the same — one root, many descendants, each doing one job.

Here is the component tree for a CA firm admin dashboard — the type of screen you will build in this program.

Component tree for a CA firm admin dashboard — root to leaf hierarchy with splitting rules Every screen you build has this structure. Before writing code, draw the tree.

When you look at any screen, train yourself to ask: what is the tree here? Flatten the visual. Find the parent-child relationships.

Your Turn — Open the Udyogaseva admin dashboard in your browser. Look at the page visually. Try to name five components you can see: what would you call each one? What is the parent of each? There is no code to write — just the habit of seeing components in any UI.

One-Way Data Flow

React enforces a strict rule: data flows down, events flow up.

Data (props) only travel from parent to child. A child component cannot directly change data in its parent.

This sounds limiting. It is actually liberating. Here is why.

Think of it like this — In a well-structured spreadsheet, raw data lives in one sheet. Every other sheet reads from it. No sheet writes back to another sheet's raw data. If something is wrong with the output, you trace it back up the chain to the raw data. Everything is predictable. If every sheet could write to every other sheet, you would never know where a value came from. React's one-way data flow gives you the same guarantee.

React's one-way data flow creates a predictable system. When something displays the wrong value, you trace it up the component tree to find the source. No circular dependencies. No mystery mutations.

One-way data flow — user action to parent state to child re-render Data flows down. Events flow up. When you understand this, debugging becomes tracing — not guessing.

Events flow up through callbacks. When a child needs to tell its parent something happened (a button was clicked, a form was submitted), it calls a function that the parent passed down as a prop.

SearchBar does not manage the search state. It just calls onSearch when the user types. The parent owns the state and passes it down to CandidateList. Two components share the same data without either one managing it.

When to Split into Components

This is the question every React developer asks dozens of times a day.

Think of it like this — When would you create a named range in Excel? When you use the same formula in more than one place. When a formula is complex enough that you want to name it for clarity. When a section of the sheet is logically self-contained. The same rules apply to React components.

Split a piece of UI into its own component when:

You are repeating it — if you are copying and pasting JSX, that is a component
It is getting too long — a component over 150 lines is doing too much
It has a clear, nameable responsibility — "this renders a candidate's status badge"
It could be reused on another page — stat cards, search bars, table rows

Do not split for the sake of splitting. A component with one child is usually unnecessary. Premature splitting makes the codebase harder to read, not easier.

The naming test: If you can give a component a clear, descriptive name in 2–3 words, it belongs as its own component. If you are writing ThirdSectionOfTheTopPartOfThePageWhenUserIsLoggedIn, you are splitting too granularly.

State Lifting

Here is a problem that will come up constantly.

Two components on the same page need access to the same piece of data. For example: a date filter at the top of the page and a results table below it. When the user changes the date filter, the table updates.

The rule: When two components need to share state, move the state up to their common parent. This is called lifting state up.

The parent becomes the "source of truth." Both children read from the same source. When one changes it, the other automatically sees the update.

Think of it like this — Two charts in Excel that both reference the same named range. Change the named range, both charts update. The named range is the lifted state — one source that both depend on. In React, the parent component is that named range.

Your Turn — In the ComponentPropsPlayground on this page, change any prop in the table. Notice how both the rendered card and the code preview update simultaneously. That is because both read from the same lifted state in the parent component.

The Re-Render

When state changes in a component, React re-renders that component and all of its children. This sounds expensive.

React makes it fast through a process called diffing — it compares the previous output with the new output and only updates the actual DOM where something changed.

You do not need to manage this. But you need to understand it conceptually, because it explains one common mistake.

The mistake: putting expensive calculations directly in the render function.

For simple calculations this is fine. For heavy computations over large datasets, React provides useMemo — which memoizes the result and only recalculates when the input actually changes.

Claude handles this automatically for you; what you need to know is that this is why you sometimes see useMemo in production code.

Try It: Props Make Components Reusable

The playground below shows a StatCard component — exactly the kind you see in every CA firm admin dashboard. The left side is the rendered component. The right side is the JSX code passing props to it. The bottom table is the props list.

Change any prop in the table — edit the title, change the value, switch the trend to "down", change the color to "red" — and watch the component re-render instantly. This is what props do: one component definition, infinite configurations.

Exercise: Draw the Component Tree

Here is a design brief for a CA firm's simple client dashboard. Before you touch any code, draw the component tree.

The screen:

A sidebar on the left with the firm's logo and 5 navigation links
A top bar with the current page title and the logged-in CA's name
Four stat cards in a row: Total Clients, GST Returns Filed, Pending Filings, Revenue This Month
A table below the cards listing recent client activity (client name, last filing date, status badge)

Draw the component tree on paper. Use the same format as the Udyogaseva example above. Give every component a clear, descriptive name.

Count your components. A reasonable answer has roughly 8–10. Fewer than 5 means you are not splitting enough. More than 15 means you are splitting too granularly.

Look at your tree and ask: where would state live? The search on the table — which component owns it? The navigation active state — which component controls it?

The naming test — If you can give a component a clear, descriptive name in 2–3 words, it belongs as its own component. If you are writing ThirdSectionOfTheTopPartOfThePage, you are splitting too granularly.

This exercise is how professional developers approach every new screen. Not by writing code first. By thinking in components first.

Summary

Concept	Rule
Component tree	Every app is a hierarchy. Find the root, trace the children.
Data flow	Data goes down (props). Events go up (callbacks). Never sideways.
When to split	Repeated UI, named responsibility, or over 150 lines.
State lifting	Shared state belongs in the common parent.
Re-render	Automatic when state changes. React figures out what changed.

In the next lesson, we look at the tool that makes everything look good: Tailwind CSS.

This lesson gives you that mental model.

The Component Tree

Every React application is a tree. At the top is the root component — usually called App. Everything else descends from it.

Here is the component tree for a CA firm admin dashboard — the type of screen you will build in this program.

Component tree for a CA firm admin dashboard — root to leaf hierarchy with splitting rules Every screen you build has this structure. Before writing code, draw the tree.

When you look at any screen, train yourself to ask: what is the tree here? Flatten the visual. Find the parent-child relationships.

One-Way Data Flow

React enforces a strict rule: data flows down, events flow up.

Data (props) only travel from parent to child. A child component cannot directly change data in its parent.

This sounds limiting. It is actually liberating. Here is why.

React's one-way data flow creates a predictable system. When something displays the wrong value, you trace it up the component tree to find the source. No circular dependencies. No mystery mutations.

One-way data flow — user action to parent state to child re-render Data flows down. Events flow up. When you understand this, debugging becomes tracing — not guessing.

Events flow up through callbacks. When a child needs to tell its parent something happened (a button was clicked, a form was submitted), it calls a function that the parent passed down as a prop.

When to Split into Components

This is the question every React developer asks dozens of times a day.

Split a piece of UI into its own component when:

You are repeating it — if you are copying and pasting JSX, that is a component
It is getting too long — a component over 150 lines is doing too much
It has a clear, nameable responsibility — "this renders a candidate's status badge"
It could be reused on another page — stat cards, search bars, table rows

Do not split for the sake of splitting. A component with one child is usually unnecessary. Premature splitting makes the codebase harder to read, not easier.

State Lifting

Here is a problem that will come up constantly.

The rule: When two components need to share state, move the state up to their common parent. This is called lifting state up.

The parent becomes the "source of truth." Both children read from the same source. When one changes it, the other automatically sees the update.

The Re-Render

When state changes in a component, React re-renders that component and all of its children. This sounds expensive.

React makes it fast through a process called diffing — it compares the previous output with the new output and only updates the actual DOM where something changed.

You do not need to manage this. But you need to understand it conceptually, because it explains one common mistake.

The mistake: putting expensive calculations directly in the render function.

For simple calculations this is fine. For heavy computations over large datasets, React provides useMemo — which memoizes the result and only recalculates when the input actually changes.

Claude handles this automatically for you; what you need to know is that this is why you sometimes see useMemo in production code.

Try It: Props Make Components Reusable

Exercise: Draw the Component Tree

Here is a design brief for a CA firm's simple client dashboard. Before you touch any code, draw the component tree.

The screen:

A sidebar on the left with the firm's logo and 5 navigation links
A top bar with the current page title and the logged-in CA's name
Four stat cards in a row: Total Clients, GST Returns Filed, Pending Filings, Revenue This Month
A table below the cards listing recent client activity (client name, last filing date, status badge)

Draw the component tree on paper. Use the same format as the Udyogaseva example above. Give every component a clear, descriptive name.

Count your components. A reasonable answer has roughly 8–10. Fewer than 5 means you are not splitting enough. More than 15 means you are splitting too granularly.

Look at your tree and ask: where would state live? The search on the table — which component owns it? The navigation active state — which component controls it?

This exercise is how professional developers approach every new screen. Not by writing code first. By thinking in components first.

Summary

Concept	Rule
Component tree	Every app is a hierarchy. Find the root, trace the children.
Data flow	Data goes down (props). Events go up (callbacks). Never sideways.
When to split	Repeated UI, named responsibility, or over 150 lines.
State lifting	Shared state belongs in the common parent.
Re-render	Automatic when state changes. React figures out what changed.

In the next lesson, we look at the tool that makes everything look good: Tailwind CSS.

How React Thinks

The Component Tree

One-Way Data Flow

When to Split into Components

State Lifting

The Re-Render

Try It: Props Make Components Reusable

Exercise: Draw the Component Tree

Summary

On this page

How React Thinks

The Component Tree

One-Way Data Flow

When to Split into Components

State Lifting

The Re-Render

Try It: Props Make Components Reusable

Exercise: Draw the Component Tree

Summary

On this page