React Architecture
Understand how React structures applications as a component tree with one-way data flow, and how the render-and-commit cycle works.
Introduction
Before writing React components, it helps to understand the underlying architecture that makes React applications predictable and easy to reason about. React organizes UIs as a tree of nested components, moves data through that tree in one direction, and updates the screen through a well-defined two-step process.
This lesson walks through those three ideas — the component tree, unidirectional data flow, and the render-and-commit cycle — at a conceptual level, giving you a mental model you will rely on throughout the rest of this course.
- How React represents a UI as a tree of components.
- What unidirectional (one-way) data flow means and why it matters.
- What happens during React's render-and-commit cycle.
- How this architecture differs from two-way-binding frameworks.
The Component Tree
Every React application is structured as a tree of components, much like HTML elements nest inside one another. A top-level component (often called App) renders other components, which may themselves render further components, forming a hierarchy from the whole page down to the smallest reusable piece.
Thinking of your UI as a tree makes it easier to reason about where data lives, which component is responsible for which piece of the screen, and how a change in one place might affect components below it.
Root Component
The top-level component (e.g., App) that renders the rest of the tree.
Parent and Child
A component that renders another component is its "parent"; the rendered component is its "child".
Reusable Branches
The same component can appear multiple times in the tree, each with its own data.
Isolated Pieces
Each component in the tree manages its own logic and markup, independent of its siblings.
Unidirectional Data Flow
React applications follow one-way (unidirectional) data flow: data moves down the component tree via props, from parent to child. If a child needs to communicate something back up — like a button click or a form submission — it does so by calling a function passed down from the parent, often called a callback.
This is a deliberate constraint. Because data always flows in a single, predictable direction, it is much easier to trace where a piece of data came from and what could have changed it, compared to systems where data can be updated from many different places at once.
Unidirectional data flow makes React applications easier to debug: since data only flows one way, you can always trace a UI change back to the specific state update that caused it.
The Render-and-Commit Cycle
At a conceptual level, React updates the screen through two phases. First, in the render phase, React calls your components to figure out what the UI should look like — producing a description of the UI, not the actual DOM changes yet. Then, in the commit phase, React applies the minimal set of changes needed to the real DOM so the browser reflects that description.
Something changes (e.g. state update)
↓
RENDER: React calls components to describe the new UI
↓
React compares the new description to the previous one
↓
COMMIT: React applies only the necessary changes to the real DOM
↓
The browser displays the updated UISeparating "describing the UI" from "updating the real DOM" is what allows React to batch multiple changes together, skip unnecessary work, and keep applications fast even as they grow.
React vs Two-Way Binding
Some frameworks use two-way data binding, where a change in the UI (like typing into an input) automatically updates the underlying data, and a change in the data automatically updates the UI — in both directions, often implicitly. React deliberately avoids this by default, favoring explicit, one-way data flow instead.
Two-Way Binding (conceptual)
- UI changes automatically update data.
- Data changes automatically update UI.
- Convenient for simple forms.
- Can make it harder to trace where a change originated as apps grow.
React (Unidirectional)
- Data flows down via props, explicitly.
- Events flow up via callbacks, explicitly.
- Every update is traceable to a specific state change.
- Scales predictably as apps grow more complex.
Example: A Small Component Tree
Consider a simple app with a header, a sidebar, and a content area — a common layout shape. Each of these is its own component, and all three are children of a single App component.
function App() {
return (
<div>
<Header />
<Sidebar />
<Content />
</div>
);
}App
├── Header
├── Sidebar
└── ContentApp does not need to know the internal details of Header, Sidebar, or Content — it just arranges them. Each child component is free to manage its own internal logic and, if needed, receive data from App via props.
Common Mistakes
- Trying to update a parent's data directly from a child without using a callback — this breaks the one-way data flow model.
- Assuming the render phase directly changes the DOM — it only produces a description of the UI; the commit phase applies the real changes.
- Building deeply nested component trees with no clear structure, making data flow hard to trace.
- Confusing "parent" and "child" — a parent renders a child, not the other way around.
Best Practices
- Sketch your component tree before writing code — decide which piece of the UI belongs to which component.
- Pass data down via props and pass events up via callback functions, keeping data flow consistent.
- Keep each component focused on one part of the tree rather than mixing unrelated responsibilities.
- Remember that a re-render does not mean the DOM was necessarily touched — React only commits actual differences.
- Use the component tree mental model when debugging: trace a bug by following props down and callbacks up.
Frequently Asked Questions
What is a component tree?
A component tree is the hierarchy formed when components render other components, starting from a single root component down to the smallest reusable pieces.
What does unidirectional data flow mean?
It means data flows in one direction only: down the component tree via props. Any communication back up the tree happens through callback functions passed down from parents.
What is the difference between the render phase and the commit phase?
The render phase is where React calls your components to figure out what the UI should look like. The commit phase is where React actually applies the necessary changes to the real DOM.
Does React support two-way data binding?
Not by default. React favors explicit one-way data flow, though you can build input handling that feels similar by combining state with onChange handlers yourself.
Why does React separate rendering from committing?
Separating the two phases lets React calculate the minimal set of real DOM changes needed and apply them efficiently, rather than updating the DOM on every small data change.
Key Takeaways
- React structures UIs as a tree of nested components, from a root component down to the smallest pieces.
- Data flows down the tree via props; events flow up via callback functions — this is unidirectional data flow.
- React updates the screen in two phases: render (describe the UI) and commit (apply changes to the real DOM).
- This differs from two-way-binding frameworks, where data and UI can update each other implicitly in both directions.
- A simple app like App → Header, Sidebar, Content demonstrates how a component tree is organized in practice.
Summary
React's architecture rests on three core ideas: organizing UI as a component tree, moving data through that tree in one direction, and updating the screen through a predictable render-and-commit cycle. Together, these ideas make React applications easier to reason about, debug, and scale.
In this lesson, you learned how the component tree is structured, how unidirectional data flow works, and how React's render-and-commit cycle updates the screen. Next, you will review the JavaScript, HTML, and CSS fundamentals you should be comfortable with before diving into hands-on React development.
- You understand the component tree concept.
- You can explain unidirectional data flow.
- You know the difference between the render and commit phases.
- You are ready to review the prerequisites for hands-on React development.