# How React Works Under the Hood

There was a time someone asked me in an interview,

“Can you explain how React works under the hood?”

And I couldn’t provide a good answer to the question.

I use React almost every day — I know my way around `useState`, `useEffect`, and JSX — but I couldn’t really *explain* what React was doing behind the scenes. If you’ve ever used React but never understood *why* it feels so magical, this is for you.  

## React’s Core Idea — "Just Describe What You Want"

React is built around a simple idea:

> “Don’t tell me *how* to update the UI. Just tell me *what* the UI should look like.”

Normally, in plain JavaScript, you’d do things like:

```javascript
const element = document.createElement('h1');
element.textContent = "Hello, Peter";
document.body.appendChild(element);
```

That’s **imperative** — you’re giving the browser step-by-step instructions.

React says, “Nah, just tell me what you want”:

```javascript
function Greeting({ name }) {
  return <h1>Hello, {name}</h1>;
}
```

When `name` changes, React figures out *how* to update the DOM efficiently.  
That “figuring out” is what happens under the hood.

## JSX Isn’t Magic — It’s Just JavaScript

That pretty syntax we use (`<div>`, `<p>`, `<Button />`) isn’t HTML.  
It’s called **JSX**, and it’s just a friendlier way to write JavaScript.

For example:

```javascript
<h1>Hello World</h1>
```

is secretly turned into:

```javascript
React.createElement("h1", null, "Hello World");
```

Which produces an object like this:

```javascript
{
  type: "h1",
  props: { children: "Hello World" }
}
```

## The Virtual DOM — A Smart Middleman

The browser’s DOM is powerful, but it’s also **slow** when updated frequently.  
React solves this using the **Virtual DOM** — a lightweight copy of the real DOM that lives in memory.

So when your component updates:

1. React creates a new Virtual DOM tree.
    
2. It compares it with the previous one.
    
3. It figures out what actually changed.
    
4. And then it updates *only those parts* in the real DOM.
    

That’s why React apps feel fast — it doesn’t repaint everything, just the parts that changed.

## The Diffing or Reconciliation Process

How does React know *what* changed?

It runs something called the **reconciliation algorithm** (or “diffing” for short).

Here’s what happens:

* If two elements have the same type (`<div>` vs `<div>`), React reuses the existing DOM node and updates its attributes.
    
* If they differ (`<div>` → `<span>`), React throws the old one away and creates a new one.
    
* For lists, React uses **keys** to track items. That’s why missing keys cause weird re-render bugs.
    

It’s like React saying:

> “This looks the same… I’ll keep it.  
> This changed… I’ll update it.  
> This is new… I’ll add it.”

All this happens super fast in memory before touching the real DOM.

## The Fiber Architecture — React’s Secret Engine

Before React 16, rendering was synchronous — React had to finish rendering everything before handling anything else.  
If a component took too long, your app would freeze for a moment. 😩

Then came **React Fiber**, the secret sauce of modern React.

Think of Fiber as React’s internal engine that breaks rendering work into small chunks called “units of work.”  
That means React can:

* Pause rendering,
    
* Check if something more important (like user typing) needs attention,
    
* And resume later.
    

Fiber basically made React *smarter* and *more flexible* — it can multitask now.

Each component you render becomes a **fiber node**, a small data structure React uses to track:

* Props and state,
    
* Effects to run (`useEffect`, `useLayoutEffect`),
    
* Links to its parent, child, and sibling components.
    

That’s how React can know what changed and what needs to be re-rendered.

## Hooks, State, and Updates

Hooks like `useState` or `useReducer` aren’t magic either — React keeps them in an internal list for each component (inside its fiber node).

When you call `setState`, React doesn’t immediately update the DOM.  
It:

1. Marks that component for re-render.
    
2. Creates a new Virtual DOM tree.
    
3. Runs the diffing process.
    
4. Updates the real DOM only where necessary.
    

React also batches multiple updates together for better performance.

## The Commit Phase — Where the Magic Shows

Once React figures out what changed, it goes through the **commit phase**:

1. It applies all the updates to the real DOM.
    
2. It runs your effects (`useEffect`, `componentDidMount`, etc.).
    
3. The browser repaints, and your UI updates.
    

That’s when you finally see the result on the screen.

## Concurrent Rendering and Scheduling

In React 18 and above, React got even smarter with something called the **Scheduler**.

Now it can prioritize updates:

* User typing? High priority.
    
* Background data fetching? Low priority.
    

This is what enables features like `useTransition` and `Suspense`.  
They make your app feel smoother, even under heavy load.

## Final Thoughts

When I first learned React, I used to think it was all “magic.”  
But now I know it’s just **really smart JavaScript**, built on solid principles.

If you’ve read this far, you already understand React better than I did at that interview.  
And next time someone asks you *“How does React work under the hood?”* — you’ll have a calm smile, not a blank stare.  
  
*Thanks for reading! If this helped you, share it or leave a comment — I wrote this not as an expert, but as someone who once didn’t know, and decided to dig deeper.*