How to Fix 'Rendered More Hooks Than During the Previous Render' in React

Threat/Impact Level: HIGH | Downtime Risk: HIGH | Time to Fix: 5–15 mins

TL;DR

• What broke: A React component called a different number of hooks between renders — React's fiber reconciler lost track of hook state slots and threw a fatal invariant violation.
• How to fix it: Move ALL hook calls to the top of the component, unconditionally, before any return statement or conditional branch. Pass conditions into hooks, never around them.
• Fast path: Use our Client-Side Sandbox above to paste your component and auto-refactor the hook order violation without sending your code to a third-party server.

The Incident (What Does the Error Mean?)

Raw error output from the browser console or Node SSR:

Error: Rendered more hooks than during the previous render.

This error is caused by a React component rendering more hooks than the
previous render. This can be caused by conditional rendering of hooks.
    at updateWorkInProgressHook (react-dom.development.js:...)
    at updateState
    at YourComponent

React tracks hooks via a linked list indexed by call order. On every render, React expects hook call #1 to be the same hook as last time, hook call #2 to be the same, and so on. The moment your component calls useState inside an if block that didn't execute last render, React reads the wrong slot from the linked list. The fiber node is now corrupt. React throws immediately rather than silently return stale, mismatched state — which would be a far worse silent data bug.

Immediate consequence: The component unmounts. If it's high in the tree and not wrapped in an <ErrorBoundary>, the entire React subtree goes blank. In production SSR (Next.js, Remix), this can produce a 500 or a hydration mismatch that breaks the full page.

The Attack Vector / Blast Radius

This isn't a security CVE, but the blast radius is production downtime. Common trigger scenarios:

1. A feature flag check gates a hook call. A/B testing code ships, the flag flips mid-session, the component re-renders with a new hook count.
2. Early return before hooks. A loading guard if (!data) return null placed above a useEffect call. Works fine until data transitions from falsy to truthy on re-render.
3. Hook inside a .map() or .forEach(). Dynamic list length changes → different hook count on next render.
4. Lazy refactor introducing a conditional. A senior dev extracts a hook call inside a new if (featureEnabled) block during a hotfix under pressure. Passes local dev (flag always true), breaks in staging.

Cascading failure path: Component throws → if no ErrorBoundary exists → React unmounts the nearest class component boundary or the root → user sees blank UI → support tickets spike → on-call gets paged.

How to Fix It (The Solution)

Basic Fix — Move Hooks Above All Conditionals

The rule is absolute: every hook call must be at the top level of the component function, called unconditionally, every single render.

// BAD — hook called conditionally, after an early return
function UserProfile({ userId, isAdmin }) {
-  if (!userId) return <Redirect to="/login" />;
-
-  const [profile, setProfile] = useState(null);
-  const data = useFetchUser(userId);
-
-  if (isAdmin) {
-    useAdminAuditLog(userId); // ← ILLEGAL: conditional hook
-  }
-
   return <div>{profile?.name}</div>;
 }

// GOOD — all hooks at top, conditions passed as arguments or handled inside hooks
function UserProfile({ userId, isAdmin }) {
+  const [profile, setProfile] = useState(null);
+  const data = useFetchUser(userId);         // hook handles null userId internally
+  useAdminAuditLog(userId, { enabled: isAdmin }); // condition passed INTO hook
+
+  if (!userId) return <Redirect to="/login" />;
+
   return <div>{profile?.name}</div>;
 }

Enterprise Best Practice — Encapsulate Conditions Inside Custom Hooks

Never rely on call-site discipline alone. Encode the guard inside the custom hook itself.

// BAD — consumer of the hook must remember to guard it
- if (isAdmin) {
-   useAdminAuditLog(userId);
- }

// GOOD — the hook owns its own enable/disable logic
+ // hooks/useAdminAuditLog.ts
+ export function useAdminAuditLog(userId: string, options: { enabled: boolean }) {
+   useEffect(() => {
+     if (!options.enabled || !userId) return; // guard INSIDE the hook
+     auditService.log(userId);
+   }, [userId, options.enabled]);
+ }
+
+ // component — always called, never conditional
+ useAdminAuditLog(userId, { enabled: isAdmin });

Additional patterns for complex cases:

// BAD — hook inside a loop
- items.forEach(item => {
-   const val = useItemState(item.id); // new item = new hook = crash
- });

// GOOD — extract to a child component, let React manage the hook per instance
+ function ItemRow({ item }) {
+   const val = useItemState(item.id); // one hook per component instance, stable
+   return <tr>{val}</tr>;
+ }
+ // parent
+ items.map(item => <ItemRow key={item.id} item={item} />)

💡 Tired of pasting proprietary configs into ChatGPT? Generic AI tools log your component code, internal hook names, and API endpoint strings. StackEngine is a zero-backend, pure Client-Side WASM utility. Drop your failing component into the sandbox above. We redact your secrets locally in the browser and auto-generate the refactored code using your own API key.

Prevention in CI/CD

Don't rely on runtime crashes to catch this. Shift left.

1. ESLint react-hooks/rules-of-hooks — non-negotiable, treat as error

// .eslintrc.js
 rules: {
-  'react-hooks/rules-of-hooks': 'warn',  // too lenient, PRs ship broken code
+  'react-hooks/rules-of-hooks': 'error', // blocks CI on violation
+  'react-hooks/exhaustive-deps': 'warn',
 }

This rule statically detects hooks inside conditionals, loops, and after early returns at lint time — before the code ever runs.

2. Block merges in your CI pipeline

# .github/workflows/ci.yml
- name: Lint (hooks rules enforced)
  run: npx eslint --max-warnings=0 'src/**/*.{ts,tsx}'
  # --max-warnings=0 means any warning = pipeline failure

3. Component-level unit tests with React Testing Library

Write a test that renders the component with the falsy/null prop state that would trigger the early return path. If the hook order invariant is broken, the test will throw the same error in Jest — catching it before deployment.

it('renders without crashing when userId is null', () => {
  // This test would have caught the conditional hook bug
  expect(() => render(<UserProfile userId={null} isAdmin={false} />)).not.toThrow();
});

4. Strict Mode in development

Ensure <React.StrictMode> wraps your app in development. It intentionally double-invokes render functions, making hook order violations surface immediately during local development rather than only in edge-case re-render scenarios.