The 3 Rules of React Side Effects

The root cause of most of these headaches is almost always the same: mismanaging side effects. The good news is that you don’t need to memorize every lifecycle nuance to fix it. Instead, you can follow a simple mental model with just three rules.

This article is a practical, jargon-free guide to putting every piece of your logic in the right place so your components stay fast, predictable, and hydration-safe.

The Foundation: v = f(s)

To understand where side effects belong, you first need to understand what a React component really is. At its core, React follows a simple mathematical idea:

view = f(state)

Your component is a function. It takes state (and props) as input, and it returns a description of the UI as output. In other words, your View is a function of your State: v = f(s).

A side effect is anything that happens outside of this calculation.

• •Calculating count * 2? Not a side effect. That’s just math.
• •Changing document.title? Side effect. You are mutating the browser environment.
• •Fetching data? Side effect. You are talking to a server.
• •console.log? Side effect. You are writing to the console.

React’s goal is to keep the rendering process — the calculation of the View — pure and fast. The three rules below exist to protect that purity.

Rule #0: The Golden Rule of Rendering

When React calls your component, it expects to get a description of the UI — nothing more. The body of your component function is sacred ground. It is for calculation only.

A common mistake is to put side-effectful code directly into the function body:

function UserProfile({ name }) {
  // ❌ VIOLATION: Modifying an external system during render
  document.title = `Profile: ${name}`

  return <h1>Hello, {name}</h1>
}

Why this is bad

• •React calls your component many times — whenever parents render, state changes, or even just for internal checks. Running side effects here slows rendering down.
• •It breaks server-side rendering (SSR): on the server there is no document, so this code crashes.
• •It makes behavior unpredictable because you lose control over exactly when the effect runs.

Fix: never put side effects at the top level of your component. Keep render pure; we’ll see where to move this logic in Rules #1 and #2.

Rule #1: Handle User Actions in Event Handlers

This sounds obvious but is one of the most violated rules. A common anti-pattern is to treat state + useEffect as an ad-hoc event system.

The anti‑pattern

Imagine you want to send analytics when the user clicks a notification badge:

function NotificationBadge() {
  const [count, setCount] = useState(0)
  const [clicked, setClicked] = useState(false)

  // ❌ VIOLATION: Using state & effect for a simple action
  useEffect(() => {
    if (clicked) {
      sendAnalytics("badge_clicked")
      setClicked(false) // Resetting state? It's getting messy.
    }
  }, [clicked])

  return (
    <button
      onClick={() => {
        setCount(0)
        setClicked(true)
      }}
    >
      Notifications
    </button>
  )
}

Here, the actual cause of the side effect is clear: the user clicked. The effect, however, is wired to a piece of state instead, creating extra renders and extra complexity.

The fix

function NotificationBadge() {
  const [count, setCount] = useState(0)

  function handleClick() {
    // 1. Update State (UI Logic)
    setCount(0)

    // 2. Run Side Effect (Business Logic) ✅
    sendAnalytics("badge_clicked")
  }

  return <button onClick={handleClick}>Notifications</button>
}

• •React doesn’t even know the side effect happened — it just sees a state update.
• •The render stays pure; the handler runs after the user action.
• •You don’t need useEffect at all for this scenario.

Rule #2: Synchronize with useEffect

This is the only valid reason to use useEffect: synchronization.

What counts as an external system?

• •A database or API connection
• •A WebSocket or subscription
• •The browser DOM (e.g., document.title)
• •Timers like setTimeout or setInterval

If you want your component to stay in sync with one of these systems for as long as it’s on the screen, useEffect is the right tool.

Example: document.title

Let’s revisit the document.title example, now implemented correctly with synchronization in mind:

function NotificationBadge({ count }) {
  // ✅ CORRECT: We are synchronizing the DOM with our State
  useEffect(() => {
    document.title = `(${count}) New Messages`

    return () => {
      document.title = "React App"
    }
  }, [count])

  return <div className="badge">{count}</div>
}

Don’t think of the dependency array as “when this code runs.” Think of it as “what data this effect uses to synchronize.”

When count changes, the previous synchronization is invalid. React tears it down and runs the effect again to bring the external system back in sync.

The Decision Matrix: Where Does This Code Belong?

Next time you’re writing a component and you’re not sure where to put a piece of logic, walk through this simple decision tree:

1. Is this just calculating the View?

   If yes, put it directly in the component body. This is render logic. (Rule #0)

2. Was this triggered by a specific user or system event (click, submit, keypress, etc.)?

   If yes, put it in an event handler. This is action logic. (Rule #1)

3. Do I need to keep my component in sync with an external system over time?

   If yes, put it in useEffect. This is synchronization logic. (Rule #2)

Summary

• •React components are pure functions from state/props to a View: v = f(s).
• •Keep the component body pure — no side effects there. (Rule #0)
• •Put side effects caused by specific events into event handlers. (Rule #1)
• •Use useEffect only to synchronize with external systems over time. (Rule #2)

Once you internalize these three rules, 99% of your side effect logic becomes straightforward — and those infinite loops and hydration errors become rare and easy to fix.