DEV Community

Cover image for How I Currently Understand Rendering in React (My Improved Mental Model)
Usama
Usama

Posted on

How I Currently Understand Rendering in React (My Improved Mental Model)

I’m still learning React, but I feel my understanding of rendering is getting better with time.
This blog is my attempt to explain React rendering the way I understand it right now, in simple words.

I’m not trying to sound perfect I’m explaining this as a learner.


Components and Component Instances

First of all, we create a React component.

A component is basically a JavaScript function.
By itself, it has no effect on the browser screen.
Nothing is visible just by defining a component.

When we use that component in JSX, React creates a component instance.

A component can have:

one instance

or multiple instances

Each instance:

has its own state

receives its own props

has its own lifecycle

and keeps its own memory

I think of a component instance like a living object.
It exists in time, can change, can update, and React keeps track of it.


From Component Instance to React Element

Every component instance produces React elements.

React elements are created when JSX is converted into JavaScript using
React.createElement().

So in simple terms:

JSX is syntax

React element is the actual JavaScript object

Each React element describes what should appear in the UI.


React Element Tree and Virtual DOM

All React elements together form a React element tree.

Many people also call this tree the Virtual DOM.

This Virtual DOM plays a very important role in React.
Because of it, React is considered fast and modern.

The Virtual DOM allows React to:

compare UI changes efficiently

avoid unnecessary real DOM updates

update only what is actually needed


React Rendering (What It Really Means)

Now let’s talk about rendering, which is often misunderstood.

In React, rendering does NOT mean showing something on the screen.

Rendering means:

React’s internal process of calculating UI changes


When Rendering Is Triggered

Rendering is triggered mainly in two cases:

  1. Initial Rendering
    When we open a website and the UI appears for the first time.

  2. State Update Rendering
    When any state is updated inside a component.

This entire process happens inside React, not in the browser.


What Happens During Rendering

We already have a Virtual DOM tree.

When a state update happens:

React does not rebuild everything blindly

React re-renders the part of the tree from where the state was updated

Only the affected component and its child components are re-rendered

Parent components are not re-rendered unnecessarily

After that, React compares:

the previous tree

with the newly created tree

This comparison process is called reconciliation.


Fiber and Fiber Tree (Important Part)

Reconciliation is handled by React’s internal engine called Fiber.

Fiber has its own structure called the Fiber Tree.

Key things about the Fiber Tree:

It is created once

It is not recreated again and again

It keeps getting updated over time

The Fiber Tree looks different from the Virtual DOM tree, but it represents the same UI in a more optimized way.


Work-In-Progress Fiber Tree

When an update happens:

React creates a Work-In-Progress Fiber Tree

Changes are applied to this new tree

React prepares everything in the background

Once the work is complete:

The Work-In-Progress tree becomes the current Fiber Tree


Commit Phase

After reconciliation is done, React moves to the Commit Phase.

In the commit phase:

Changes are applied to the real DOM

Updates become visible

This whole process happens synchronously and is hidden from the developer.


Browser Rendering (After React Is Done)

After React finishes its work:

the browser takes control

the browser decides:

layout

painting

how things look on the screen

This is called browser paint, and this part is not React’s responsibility.


Complete Flow (As I Understand It)

This is the full flow in my head now:

Component creation

 → Component instance
 → React elements
 → React element tree (Virtual DOM)
 → Rendering trigger
 → Re-rendering
 → Reconciliation (Fiber)
 → Work-In-Progress Fiber Tree
 → Commit phase
 → Browser paint
Enter fullscreen mode Exit fullscreen mode

Final Thoughts

I believe this explanation is much better than what I understood earlier.

The most important realization for me is:

React rendering is about recalculating UI, not directly updating the screen.

I’m still learning, but this mental model feels solid and practical, and it helps me understand:

why re-renders happen

how React stays fast

and how updates actually reach the screen

This is my current understanding — and I’m confident it will evolve as I go deeper.

Top comments (0)