Why React Cares So Much About “Pure” Rendering

There’s a moment when learning React where something starts to feel… restrictive.

You try to fetch data, set up something, or run a piece of logic—and suddenly you’re told:

“Don’t do that here. Use useEffect.”

At first, it feels like React is just being annoying.

Why can’t we just run things when the component is about to mount? Why must everything wait until after render?

The answer sits in one idea that React takes very seriously:

rendering should be pure.

What “Pure” Actually Means

When React calls your component, it expects one thing:

function Component() {
  return <div>Hello</div>
}

Given the same inputs (props, state), it should always return the same output.

No surprises. No hidden behavior.

That’s what “pure” means here.

Where It Starts to Break

Now imagine doing this inside your component:

function Component() {
  fetch("/api/data")

  return <div>Hello</div>
}

It might work… but something feels off.

Because now your render is doing more than just describing UI.

It’s:

• triggering a network request
• causing side effects
• interacting with something outside React

That’s no longer pure.

Why React Doesn’t Allow This

The problem isn’t just about “clean code”.

It’s about how React actually runs your component.

React doesn’t guarantee that a render will always be used.

It can:

• render a component
• pause it
• throw it away
• render again

This happens in modern React with things like concurrent rendering.

Now Imagine This Scenario

function Component() {
  fetch("/api/data")
  return <div>Hello</div>
}

React:

• renders → API call happens
• discards render
• renders again → API call happens again

You now have:

• duplicate requests
• inconsistent behavior
• bugs that are hard to trace

This Is Why Purity Matters

By keeping render pure, React ensures:

• no side effects during render
• no accidental duplication
• predictable behavior

Rendering becomes something React can safely run multiple times.

So Where Do Side Effects Go?

That’s where useEffect comes in.

useEffect(() => {
  fetch("/api/data")
}, [])

Now the flow is different:

1. React renders
2. DOM updates
3. Effect runs

This guarantees:

• the component is actually mounted
• the work is not wasted
• the side effect runs at the right time

The Trade-off

You lose something:

• you can’t run logic “before render”

But you gain something more important:

• consistency
• safety
• control in a more predictable way

A Better Way to Think About It

Instead of asking:

“When should this run in the lifecycle?”

Think:

“Is this part of rendering, or is this a side effect?”

If it affects the outside world:

• API calls
• timers
• event listeners
• third-party libraries

It doesn’t belong in render.

Why This Design Feels Different

If you’ve used frameworks like Vue, this can feel limiting.

You’re used to hooks like:

• beforeMount
• mounted

Where you can control exactly when things happen.

React takes a different approach.

It removes that control in exchange for stronger guarantees.

The Core Idea to Keep

Rendering is just a description.

It should not:

• change anything
• trigger anything
• depend on external effects

It should only answer:

“What should the UI look like right now?”

Final Takeaway

The restriction isn’t there to make things harder.

It’s there to make React reliable.

Once you accept that rendering is pure, everything else starts to fall into place:

• why useEffect exists
• why there’s no beforeMounted
• why React can re-render freely

And most importantly:

why your UI stays predictable even as your app grows