React Performance Tips from 8 Years of Debugging

I struggled with this React concept more than I expected… 👇 👉 Why are my API calls running twice? ⚙️ What you’ll notice You open your network tab and suddenly see this: api/me → called twice api/roles → called twice api/permissions → called twice Just like in the screenshot 👇 Same request, duplicated… again and again. ⚙️ What’s actually happening In React (development mode), if your app is wrapped in Strict Mode, React will run effects twice on purpose. useEffect(() => { fetch("/api/users") .then(res => res.json()) .then(setUsers); }, []); Even though it looks like it should run once… it doesn’t (in dev). 🧠 What’s going on under the hood React basically does a quick cycle: mount → unmount → remount Why? To catch hidden side effects To check if cleanup is handled properly To make sure your logic doesn’t break on re-renders So if your API call runs twice, React is just making sure your code can handle it. 💡 The important part This only happens in development Production behaves normally (runs once) Your side effects should be safe to run multiple times 🚀 Final thought If your network tab looks “noisy” like the screenshot, it’s not React being broken — it’s React being careful. And once you understand this, debugging becomes a lot less confusing. #React #Frontend #JavaScript #WebDevelopment #ReactJS #SoftwareEngineering

The React Hook "Periodic Table": From Basics to Performance ⚛️ If you want to write clean, professional React code in 2025, you need more than just useState. While useState is the heart of your component, these 7 hooks form the complete toolkit for building scalable, high-performance apps. Here is the breakdown: 🌟 The Core Essentials 1️⃣ useState: The bread and butter. Manages local state (toggles, form inputs, counters). 2️⃣ useEffect: The "Swiss Army Knife." Handles side effects like API calls, subscriptions, and DOM updates. 3️⃣ useContext: The prop-drilling killer. Shares global data (themes, user auth) across your entire app without passing props manually. ⚡ The Performance Boosters 4️⃣ useMemo: Caches expensive calculations. Don't re-run that heavy data filtering unless your dependencies actually change! 5️⃣ useCallback: Memoizes functions. Perfect for preventing unnecessary re-renders in child components that rely on callback props. 🛠️ The Power Tools 6️⃣ useRef: The "Persistent Finger." Accesses DOM elements directly (like auto-focusing an input) or stores values that persist without triggering a re-render. 7️⃣ useReducer: The "Traffic Cop." Best for complex state logic where multiple sub-values change together. If your useState logic is getting messy, this is your solution. 💡 Pro-Tip : Keep an eye on React 19 hooks like useOptimistic (for instant UI updates) and useFormStatus (to simplify form loading states). The ecosystem is moving fast! Which hook do you find yourself reaching for the most lately? Is there a custom hook you’ve built that you now use in every project? 👇 #ReactJS #WebDevelopment #Frontend #CodingTips #Javascript #SoftwareEngineering #ReactHooks #WebDev2025

I just started a deep dive into React and came across how it uses snapshots to re-render the view, by strictly comparing references of the old state copy in memory to the newer one. That immediately triggered a question: When we do so many state updates in a large production app, we are essentially creating so many snapshots in memory that will most likely never be used again. What happens to all this garbage sitting in memory? There must be massive leaks everywhere, right? Short answer: No. Long answer: Here's why. Every state update creates a new snapshot in memory. The old one loses all references pointing to it. JavaScript's Garbage Collector sees this and frees it automatically. GC's only rule → if nothing points to it, it's gone. 🧹 Real leaks in React come from YOU accidentally holding references outside React's control: ❌ Pushing state into an array that lives outside the component ❌ Adding event listeners without removing them ❌ setInterval running after the component unmounts In all these cases GC sees "something still points here" and leaves it alone, forever. useEffect cleanup exists for exactly this reason: return () => window.removeEventListener("resize", handler); One line. Prevents an entire class of memory leaks. React is not the problem. Uncleaned side effects are. #React #JavaScript #Frontend #SoftwareEngineering #WebDev

Some of the hardest React bugs I’ve seen weren’t actually inside React. They were happening somewhere in between. Between the event loop and the render cycle. You know the kind of bug. Everything looks correct. State updates are there. Handlers are wired properly. The logic makes sense. And yet… the UI shows stale data. Something flickers for a split second. It works fine locally, but breaks under real user interaction. Those are the bugs that make you question your sanity a bit. What’s really going on is this. We tend to think of React and JavaScript as one system. But they’re not. JavaScript runs your code - sync, promises, timeouts, all of that. React runs its own process - scheduling renders, batching updates, deciding when the UI actually updates. Most of the time, we blur that into one mental model. And most of the time it works. Until it doesn’t. That gap is where things get weird. You’ve probably seen versions of this: 🔹 You call setState and immediately get the old value 🔹 A setTimeout fires and uses stale data 🔹 A promise resolves and overwrites something newer 🔹 Everything works… until a user clicks fast enough Individually, none of this is surprising. But when it happens in a real app, it feels unpredictable. Because the problem isn’t what your code does. It’s when it runs. That’s why these bugs are so frustrating. You’re not debugging logic anymore. You’re debugging timing. The more I work on complex React apps, the more I notice this - a big part of senior frontend work isn’t just knowing hooks or patterns. It’s understanding how React’s rendering model interacts with the JavaScript runtime. Because once timing gets involved what looks correct can still be completely wrong. #reactjs #javascript #frontend #webdevelopment #softwareengineering #debugging #performance #typescript

🚀 useReducer in React — When useState is Not Enough As your React app grows… 👉 State becomes complex 👉 Multiple updates depend on each other 👉 Logic gets messy That’s where useReducer comes in. 💡 What is useReducer? useReducer is a hook for managing complex state logic using a reducer function. 👉 Inspired by Redux ⚙️ Basic Syntax const [state, dispatch] = useReducer(reducer, initialState); 🧠 How it works 👉 Instead of updating state directly: setCount(count + 1); 👉 You dispatch actions: dispatch({ type: "increment" }); 👉 Reducer decides how state changes: function reducer(state, action) { switch (action.type) { case "increment": return { count: state.count + 1 }; default: return state; } } 🧩 Real-world use cases ✔ Complex forms ✔ Multiple related states ✔ State transitions (loading → success → error) ✔ Large components with heavy logic 🔥 Why useReducer? 👉 useState works well for simple state 👉 useReducer works better for structured logic 🔥 Best Practices (Most developers miss this!) ✅ Use when state depends on previous state ✅ Use for complex or grouped state ✅ Keep reducer pure (no side effects) ❌ Don’t use for simple state ❌ Don’t mix business logic inside components ⚠️ Common Mistake // ❌ Side effects inside reducer function reducer(state, action) { fetchData(); // ❌ Wrong return state; } 👉 Reducers must be pure functions 💬 Pro Insight (Senior-Level Thinking) 👉 useState = simple updates 👉 useReducer = predictable state transitions 👉 If your state has “rules” → useReducer 📌 Save this post & follow for more deep frontend insights! 📅 Day 20/100 #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #StateManagement #SoftwareEngineering #100DaysOfCode 🚀

useEffect is the most abused hook in React. Here's what to use instead. I've reviewed hundreds of React codebases. useEffect is in the wrong place in about 60% of them. Not because developers are careless. Because nobody explained when NOT to use it. Here are the cases I see constantly — and what actually belongs there: // ❌ Case 1: Deriving state useEffect(() => { setFullName(`${firstName} ${lastName}`) }, [firstName, lastName]) // ✅ Just compute it const fullName = `${firstName} ${lastName}` No state. No effect. No re-render bug. // ❌ Case 2: Fetching data on mount (with App Router) useEffect(() => { fetch('/api/user').then(...) }, []) // ✅ Use a Server Component or TanStack Query // Data fetching is not a side effect in modern React // ❌ Case 3: Syncing two pieces of state useEffect(() => { if (selectedId) setDetails(getDetails(selectedId)) }, [selectedId]) // ✅ Derive during render const details = selectedId ? getDetails(selectedId) : null The React team has said explicitly: if you're using useEffect to sync state with other state, you probably have one piece of state too many. useEffect is for: → Connecting to external systems (WebSocket, third-party libraries, browser APIs) → Setting up subscriptions → Manual DOM manipulation That's mostly it. If you're using useEffect for anything that feels like when X changes, update Y, there's almost certainly a cleaner way. What's the strangest useEffect usage you've come across? #React #JavaScript #TypeScript #FrontendDevelopment #WebDevelopment

Most React developers write custom hooks. But many of them don’t scale. You only realize this when your app grows. At first, hooks feel easy: Fetch data → store state → return it. Everything works… until: → You need the same logic in multiple places → Small changes break multiple screens → Side effects become hard to track → Debugging takes longer than expected The problem? We treat hooks like shortcuts instead of thinking about structure. What works better: → Keep hooks small and focused → Don’t hardcode logic — pass it as input → Separate fetching, logic, and UI → Return consistent values (data, loading, error) → Avoid unexpected side effects Simple mindset shift: Custom hooks are not just helpers. They define how your app handles data and logic. If a hook is poorly designed: → it slows you down later If it’s well designed: → everything becomes easier to scale Some of the React issues I’ve seen, started with bad hooks, not React itself. Have you faced this with custom hooks? #React #Frontend #JavaScript #WebDevelopment #SoftwareEngineering #ReactJS #FrontendDevelopment #Programming #CleanCode #TechLeadership

26 questions. The difference between knowing React on paper and surviving a real production codebase. Here are the 26 questions categorized by the depth of experience required: Level 1: The Foundations => How does React’s rendering process work? => What’s the difference between state and props? => What are hooks, and why were they introduced? => What are controlled vs uncontrolled components? => When would you use refs? => How do you handle forms and validations? Level 2: State & Logic => When should you lift state up? => How do you manage complex state in an application? => When would you use useState vs useReducer? => How do useEffect dependencies work? => How do you handle API calls (loading, error, success states)? => How do you manage shared state across components? => Context API vs Redux — when would you use each? Level 3: Performance & Scale => What causes unnecessary re-renders, and how do you prevent them? => What is memoization in React? => When would you use React.memo, useMemo, and useCallback? => How do you structure a scalable React application? => How do you optimize performance in large-scale apps? => What tools do you use to debug performance issues? => How do you secure a React application? => How do you test React components effectively? Level 4: The War Stories => Have you faced an infinite re-render issue? How did you fix it? => Tell me about a complex UI you built recently. => How did you improve performance in a React app? => What’s the hardest bug you’ve fixed in React? => How do you handle 50+ inputs in a single form without lag? Syntax is easy to Google. Deep understanding is hard to fake. #ReactJS #FrontendDevelopment #TechInterviews #JavaScript #WebDevelopment #Developers

CORS becomes very easy to understand with one real example. Imagine this: You’re building a React app on http://localhost:3000 Your backend API is running on http://localhost:8000 From your frontend, you make a request: fetch("http://localhost:8000/api/profile") Looks normal, right? But the browser sees this as: Frontend → localhost:3000 Backend → localhost:8000 Same machine. Same localhost. Different port. And that different port is enough for the browser to say: “Hold on — this is a different origin. I need permission first.” So before sending the real request, the browser asks your backend: “Is localhost:3000 allowed to access you?” That’s the CORS check. If your backend responds with: Access-Control-Allow-Origin: http://localhost:3000 The browser allows the request. If not, it blocks it and throws the CORS error. That’s why this fails: fetch("http://localhost:8000/api/profile") Not because your API is broken. Not because React failed. But because the browser is protecting the user. And that’s the key thing most beginners miss: CORS is not a server error. It’s the browser asking the server for permission. Once you understand that, CORS stops feeling random. #Frontend #WebDevelopment #JavaScript #ReactJS #NodeJS #FullStack #SoftwareEngineering #Developers #TechConcepts

Most React devs know when to use useLayoutEffect. Almost none can explain why it behaves differently. The answer lives inside the commit phase. React's update cycle has two big stages: render (reconcile, diff, no DOM writes) and commit (apply changes, run effects). Commit itself splits into 3 sub-phases: → Before Mutation — read DOM snapshots before anything changes → Mutation — insert, update, remove DOM nodes → Layout — refs attached, useLayoutEffect fires here, synchronously useEffect never runs in the Layout pass. During reconciliation, React builds an Effect List — fiber nodes tagged with pending work. Fibers marked HookLayout flush during the Layout sub-phase. Fibers marked HookPassive get handed to the scheduler and run after the browser paints. React docs put it directly: "React guarantees that the code inside useLayoutEffect and any state updates scheduled inside it will be processed before the browser repaints the screen." Classic case where this matters: tooltip positioning. With useEffect, users catch a flicker — the tooltip renders in the wrong spot, then jumps. With useLayoutEffect, both renders complete before any pixel changes on screen. The tradeoff: useLayoutEffect blocks paint. Use it only when you need to measure or mutate the DOM before the user sees the frame. Data fetching, subscriptions, analytics — those belong in useEffect. One gotcha: useLayoutEffect is a no-op in SSR. React will warn you. Guard with typeof window !== 'undefined' or default to useEffect in universal code. #frontend #reactjs #javascript #typescript #frontenddevelopment #softwareengineering #webdevelopment