React Re-renders on State Setter Calls, Not Value Changes

I made React slower trying to optimize it. Wrapped everything in useMemo. Added useCallback everywhere. Felt productive. Performance got worse. Here's what I didn't understand about re-renders 👇 4 things that trigger a re-render: > State change > Prop change > Parent re-renders (even if YOUR props didn't change) > Context update That third one is responsible of unnecessary re-renders I've seen in real codebases. The fix isn't memorizing APIs. It's this order: 1. Profile first Open React DevTools Profiler. Find the actual problem. Takes 2 minutes. 2. Wrap the right components in React.memo Not all of them. Only components that are expensive AND receive stable props. 3. Stabilise your functions with useCallback Without it - new function reference every render --> child always re-renders. Doesn't matter if you have React.memo. 4. useMemo for heavy calculations only Not for "this array map looks expensive." Only when Profiler proves it. The rule I follow now: Don't optimise what you haven't measured. One change in the right place beats 10 changes in the wrong ones. What's the most unnecessary useMemo you've ever written? 😄 #React #JavaScript #Frontend #WebDev

🔥 I used to think React worked like this… 👉 “You change something… and the whole page re-renders.” That was my mental model for a long time. And honestly… it made React feel unpredictable. Then I learned what actually happens. ⚛️ React does NOT re-render everything When state changes, React does NOT rebuild the entire UI. Instead: It creates a new Virtual DOM snapshot Compares it with the previous one Detects ONLY what changed Updates just those parts in the real DOM 💡 So what’s actually happening? ❌ Not: “everything re-renders” ✔ But: “React calculates the difference and patches only what changed” 🧠 The mindset shift This changed how I write React code completely. Now I stop thinking in terms of: 👉 “What re-renders?” And start thinking: 👉 “What actually changes?” 🚀 Why this matters Because performance issues in React usually don’t come from React itself… They come from misunderstanding the rendering model. 🧩 Once this clicks, React stops feeling like magic and starts feeling like a system you can control. Have you ever had a React concept you used for months… before finally realizing how it actually works? #React #JavaScript #Frontend #WebDevelopment #CleanCode

If you think every re-render updates the DOM, this will change your mind. Rendering in React is just a function call. Your component runs, returns JSX, and React calculates what the UI should look like. That’s it. Now the important part 👇 Re-rendering does NOT mean the DOM was updated. It only means 👉 React called your component again The DOM is updated later and only if something actually changed. So the real flow is: Trigger → state or props change Render → React runs your component Commit → React updates only the differences This is why you can type inside an input, the component re-renders, and your text is still there. Because React doesn’t touch what hasn’t changed. The real optimization isn’t avoiding re-renders It’s understanding what happens after them. #React #FrontendDevelopment #JavaScript #WebDevelopment #SoftwareEngineering #ReactJS #FrontendEngineer #TechCareers #CodingTips #DeveloperMindset

Most React performance advice is wrong. Not because the patterns are bad but because developers apply them without understanding what React is actually doing. Here’s what I’ve learned: React.memo without useCallback is just theater. memo tells React: “Only re-render if prop references change.” But if you pass a new function reference on every render, memo does absolutely nothing. // ❌ Kills memo on every render <ProductCard onSelect={(id) => handleSelect(id)} /> // ✅ Actually works const handleSelect = useCallback((id) => { dispatch({ type: "SELECT", payload: id }); }, [dispatch]); useMemo has a cost use it surgically. React still performs dependency comparison on every render. For cheap computations, the memoization overhead can be higher than simply recalculating. Use useMemo only when: the computation is genuinely expensive the result is passed to a memoized child you’ve measured it, not assumed it Before reaching for memo or useMemo, ask: What is actually triggering the re-render? Can you eliminate the trigger instead of memoizing around it? Structural state changes beat memoization every time. What’s the nastiest React performance bug you’ve hit in production? #React #ReactJS #Frontend #TypeScript #WebDevelopment #MERN #JavaScript #SoftwareEngineering

✨ 𝗗𝗮𝘆 𝟱 𝗼𝗳 𝗠𝘆 𝗥𝗲𝗮𝗰𝘁 𝗝𝗼𝘂𝗿𝗻𝗲𝘆 ⚛️🚀 Today I explored what happens 𝗯𝗲𝗵𝗶𝗻𝗱 𝘁𝗵𝗲 𝘀𝗰𝗲𝗻𝗲𝘀 𝗶𝗻 𝗥𝗲𝗮𝗰𝘁 — 𝗥𝗲𝗰𝗼𝗻𝗰𝗶𝗹𝗶𝗮𝘁𝗶𝗼𝗻, 𝗙𝗶𝗯𝗲𝗿, 𝗗𝗶𝗳𝗳𝗶𝗻𝗴, 𝗮𝗻𝗱 𝗞𝗲𝘆𝘀. I learned that when state changes, React doesn’t update the whole DOM. Instead, it compares the previous and new Virtual DOM using a 𝗱𝗶𝗳𝗳𝗶𝗻𝗴 𝗮𝗹𝗴𝗼𝗿𝗶𝘁𝗵𝗺, and updates only what actually changed. The idea of 𝗥𝗲𝗰𝗼𝗻𝗰𝗶𝗹𝗶𝗮𝘁𝗶𝗼𝗻 — deciding what needs to update — was really interesting. And 𝗥𝗲𝗮𝗰𝘁 𝗙𝗶𝗯𝗲𝗿 takes it further by making rendering more efficient and interruptible, so the UI stays smooth. Also understood why 𝗸𝗲𝘆𝘀 are important when rendering lists. They help React identify elements correctly and avoid unnecessary re-renders. It’s fascinating to see how much optimization is happening behind such simple code. React is smarter than it looks 💻⚡ #ReactJS #JavaScript #WebDevelopment #LearningJourney #FrontendDevelopment

For a long time, I tried to stop React from re-rendering. Turns out, I was solving the wrong problem. React is already fast at rendering. The real issue isn’t re-renders—it’s 𝐰𝐡𝐚𝐭 𝐲𝐨𝐮 𝐝𝐨 𝐝𝐮𝐫𝐢𝐧𝐠 𝐞𝐚𝐜𝐡 𝐫𝐞𝐧𝐝𝐞𝐫. If your component runs expensive logic every time it renders, performance will suffer no matter how many optimizations you add. A simple example: const sortedUsers = users.sort((a, b) => a.age - b.age) This runs on every render. A better approach: const sortedUsers = useMemo(  () => users.slice().sort((a, b) => a.age - b.age),  [users] ) Now the sorting only happens when `users` actually change. This small shift changed how I think about performance. The goal is not fewer renders—it’s 𝐥𝐞𝐬𝐬 𝐰𝐨𝐫𝐤 𝐩𝐞𝐫 𝐫𝐞𝐧𝐝𝐞𝐫. Once you focus on that, tools like `useMemo` and `useCallback` start making sense instead of being overused blindly. 💡 Here’s what I apply in real projects: ✔️ Avoid heavy computations directly inside render ✔️ Use `useMemo` only for expensive operations ✔️ Measure before optimizing—don’t guess React performance isn’t about tricks. It’s about understanding where the real cost is. 💬 𝐖𝐡𝐞𝐧 𝐝𝐢𝐝 𝐑𝐞𝐚𝐜𝐭 𝐩𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐜𝐞 𝐟𝐢𝐧𝐚𝐥𝐥𝐲 “𝐜𝐥𝐢𝐜𝐤” 𝐟𝐨𝐫 𝐲𝐨𝐮? 👉 Follow Usman Ahmed for more Updates! #ReactJS #FrontendEngineering #WebPerformance #JavaScript #CleanCode #SoftwareEngineering #ReactHooks

⚡ React.memo is NOT free. Most developers use it wrong. Here’s when it actually helps — …and when it silently makes things worse 👇 ✅ Use React.memo when: • A child component receives the same props often • The parent re-renders frequently (e.g. on every keystroke) • The child is expensive to render ❌ Skip React.memo when: • Props change every render anyway (new object/array inline) • The component is already fast • You haven’t profiled yet 💡 The real gotcha: // ❌ memo does nothing here — new array on every render <MemoChild items={[1, 2, 3]} /> // ✅ stable reference = memo works const items = useMemo(() => [1, 2, 3], []); <MemoChild items={items} /> 🧠 Why this happens: React.memo does a shallow comparison of props. ➡️ New object reference = treated as “changed” ➡️ Component re-renders anyway You just paid: 💸 Comparison cost 💸 Render cost 👉 Lose-lose. 📌 Rule of thumb: Profile first → optimize second #ReactJS #Performance #FrontendDev #WebDev

🧠 useMemo, useCallback, and React.memo — optimise wisely, or pay the price These three tools exist to prevent unnecessary re-renders. But used carelessly, they add complexity without any real benefit. Here's how to know when to reach for them — and when to leave them alone. The golden rule : Premature optimisation is the root of all evil. React is fast by default. Don't memoize code that isn't slow. You'll pay the cost of complexity without any gain in performance. When you do have a real performance problem, these three tools are your solution. Let's break each one down. Tool 1 useMemo — cache an expensive calculation Memoizes the result of a function. React skips recomputing a function unless the dependencies change. Without useMemo, a function runs on every render — even when items hasn't changed. If items is large, that's a real cost Tool 2 useCallback — cache a function reference Memoizes the function itself, not its result. Returns the same function reference between renders. In JavaScript, functions are recreated on every render. That means a child component receiving handleClick as a prop will always see a "new" function — and re-render unnecessarily. useCallback fixes that. Tool 3 React.memo — skip re-rendering a child component Wraps a component so it only re-renders when its props actually change. A higher-order component, not a hook. When to use them — a quick reference Situation=>Use it? Heavy calculation running on every render=>useMemo ✓ Callback passed to a memoized child=>useCallback ✓ Child re-rendering with unchanged props=>React.memo ✓ Simple value like count + 1=>Skip it ✗ Child not wrapped in React.memo=>useCallback won't help ✗ Small list, cheap render=>Not worth it ✗ #ReactJS #ReactDeveloper #FrontendDeveloper #JavaScriptDeveloper #WebDeveloper #NodeJS #FullStackDeveloper #Frontend #JavaScript #WebDevelopment #VirtualDOM #SoftwareEngineer #SoftwareDevelopment

Ever wonder how to get React’s power without the heavy payload? Enter Preact. ⚛️ What is Preact? It’s a fast, ultra-lightweight (3kB) JavaScript library with the exact same modern API as React. You get the Virtual DOM, components, and hooks you already know—just without the bulk. When should you use it? 🚀 Performance-critical apps: Drastically faster load times and lower memory usage. 📱 Mobile Web & PWAs: Perfect for shipping minimal code to devices on slower networks. 🏝️ Islands Architecture: The go-to choice for frameworks like Astro or Fresh where keeping client-side JS tiny is the goal. React vs. Preact: The TL;DR Size: React sits around ~40kB; Preact is roughly ~3kB. DOM Proximity: Preact drops React's Synthetic Events in favor of standard DOM events, and lets you use standard HTML attributes (like class instead of className). The Best Part: Thanks to the preact/compat layer, you can swap React for Preact in your bundler and continue using your favorite React libraries without rewriting your code. If frontend performance is your priority, Preact is a massive win. Have you tried using Preact in any of your projects yet? Let me know below! 👇 https://preactjs.com/ #Preact #ReactJS #WebDevelopment #Frontend #JavaScript #WebPerformance

Your component is re-rendered... Then what? Most developers stop thinking here. And that’s where the real magic starts. This is Post 3 of the series: 𝗥𝗲𝗮𝗰𝘁 𝗨𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗛𝗼𝗼𝗱 Where I explain what React is actually doing behind the scenes. React does NOT update the DOM immediately. Because touching the DOM is expensive. Instead, it follows a 3-step process: Render → Diff → Commit First, React creates something called a 𝗩𝗶𝗿𝘁𝘂𝗮𝗹 𝗗𝗢𝗠. Not the real DOM. Just a JavaScript object in memory. A blueprint of your UI. Every time your component runs, React builds a new tree of this Virtual DOM. And it already has the previous tree stored. Now comes the interesting part. React compares: Old tree vs New tree This step is called 𝗗𝗶𝗳𝗳𝗶𝗻𝗴. It finds exactly what changed. Not everything. Just the difference. Then comes the final step: 𝗖𝗼𝗺𝗺𝗶𝘁 phase React takes only those changes… …and updates the real browser DOM So no, React is NOT re-rendering your whole page. It’s doing surgical updates. The key insight: React separates thinking from doing. Thinking = Render + Diff Doing = Commit That’s why React is fast. Because touching the DOM is expensive. So React minimizes it. Flow looks like this: ✅️ Component runs ✅️ Virtual DOM created ✅️ Changes calculated ✅️ DOM updated ✅️ Browser paints UI Once you see this, you stop fearing re-renders. And start understanding them. In Post 4 of React Under the Hood: How does React actually compare trees? (The diffing algorithm 👀) Follow Farhaan Shaikh if you want to understand react more deeply. 👉 Read in detail here: https://lnkd.in/dTYAbM6n #React #Frontend #WebDevelopment #JavaScript #SoftwareEngineering