{"id":4813,"date":"2026-06-11T23:54:29","date_gmt":"2026-06-11T18:24:29","guid":{"rendered":"https:\/\/itsupportwale.com\/blog\/react-best-practices-build-scalable-apps-faster\/"},"modified":"2026-06-11T23:54:29","modified_gmt":"2026-06-11T18:24:29","slug":"react-best-practices-build-scalable-apps-faster","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/react-best-practices-build-scalable-apps-faster\/","title":{"rendered":"React Best Practices: Build Scalable Apps Faster"},"content":{"rendered":"

text
\n[2024-05-22T03:14:02.891Z] SEVERE: [MainThread] Uncaught RangeError: Maximum update depth exceeded.
\n at Object.updateContainer (react-dom.development.js:25331:7)
\n at Object.scheduleUpdateOnFiber (react-dom.development.js:21835:3)
\n at dispatchSetState (react-dom.development.js:15853:7)
\n at onAuthChange (AuthContext.tsx:42:5)
\n[2024-05-22T03:14:03.112Z] FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed – JavaScript heap out of memory
\n[2024-05-22T03:14:03.445Z] Process exited with code 137 (OOM)<\/p>\n

My eyes are vibrating. Not from the four double-shots of espresso I\u2019ve downed since Tuesday, but from the blue light of a 32-inch monitor that has been screaming "OOM" at me for three days. The office smells like ozone and despair. Somewhere in the distance, a janitor is buffing the floors, oblivious to the fact that our entire checkout pipeline just melted into a puddle of unhandled promises and infinite re-renders.\n\nThis wasn't a "bug." It was a massacre. A $50 million refactor, led by a "clever" junior developer who thought he knew **react best** practices because he watched a 15-minute YouTube video on "Clean Architecture." He decided to "decouple" our state. He decided to "abstract" our hooks. He decided to turn our codebase into a recursive nightmare that even the V8 engine couldn't optimize its way out of.\n\nI\u2019ve spent the last 72 hours gutting his "elegant" abstractions and replacing them with code that actually works. If you\u2019re looking for a "vibrant" discussion on the "tapestry" of modern UI, leave. This is a post-mortem. This is how you actually write React when your company\u2019s survival depends on it.\n\n## The 3 AM Incident Report: The Infinite Re-render Loop\n\nThe PagerDuty alert hit at 3:14 AM. By 3:20 AM, our SREs were reporting that the frontend was consuming 4GB of RAM per tab before crashing. The culprit? A "clever" implementation of a global `AuthContext` that triggered a state update every time a user moved their mouse, because "we might need to track engagement metrics in real-time."\n\nThe junior\u2014let's call him Kevin\u2014had implemented a "reactive" observer pattern inside a `useEffect` that lacked a proper dependency array. He thought he was being "efficient" by not "hardcoding" dependencies.\n\n**The Failure:**\n```typescript\n\/\/ Kevin's "Clever" Auth Provider\nexport const AuthProvider = ({ children }) => {\n  const [user, setUser] = useState(null);\n  const [metrics, setMetrics] = useState({});\n\n  \/\/ This "react best" practice according to Kevin\n  useEffect(() => {\n    const unsubscribe = api.onAuthStateChanged((u) => {\n      setUser(u);\n      \/\/ Logic that triggers a re-render on EVERY auth change\n      \/\/ which in turn re-runs this effect because the \n      \/\/ anonymous function is recreated every render.\n    });\n    return unsubscribe;\n  }); \/\/ Look Ma, no dependency array!\n\n  return (\n    <AuthContext.Provider value={{ user, metrics, setMetrics }}>\n      {children}\n    <\/AuthContext.Provider>\n  );\n};\n<\/code><\/pre>\n
Because the useEffect<\/code> lacked a dependency array, it ran on every render. Because it called setUser<\/code>, it triggered a re-render. Because it triggered a re-render, the useEffect<\/code> ran again. Maximum update depth exceeded.<\/strong> The browser didn’t just hang; it choked.<\/p>\n
The “react best” Fix:<\/strong>
\nWe had to strip the “engagement tracking” out of the Auth provider entirely. State that changes frequently (like mouse position or metrics) should never<\/strong> live in the same context as state that is globally critical (like authentication).<\/p>\n
\/\/ The Hardened Fix (React 18.3.1)\nimport { memo, useMemo, useCallback, useEffect, useState } from 'react';\n\nexport const AuthProvider = memo(({ children }: { children: React.ReactNode }) => {\n  const [user, setUser] = useState<User | null>(null);\n  const [status, setStatus] = useState<'loading' | 'auth' | 'unauth'>('loading');\n\n  const handleAuthChange = useCallback((u: User | null) => {\n    setUser(u);\n    setStatus(u ? 'auth' : 'unauth');\n  }, []);\n\n  useEffect(() => {\n    let isMounted = true;\n    const unsubscribe = api.onAuthStateChanged((u) => {\n      if (isMounted) {\n        handleAuthChange(u);\n      }\n    });\n\n    return () => {\n      isMounted = false;\n      unsubscribe();\n    };\n  }, [handleAuthChange]);\n\n  const value = useMemo(() => ({ user, status }), [user, status]);\n\n  return (\n    <AuthContext.Provider value={value}>\n      {children}\n    <\/AuthContext.Provider>\n  );\n});\n<\/code><\/pre>\n
We added isMounted<\/code> flags to prevent state updates on unmounted components\u2014a classic memory leak source. We used useMemo<\/code> for the context value to prevent every consumer from re-rendering unless the user<\/code> or status<\/code> actually changed. This is survival, not “clean code.”<\/p>\n
\n
Table of Contents<\/p>\n