Optimize React Performance: Avoid Unnecessary Re-renders

Today I discovered a React behavior that completely changed how I think about 𝐮𝐬𝐞𝐄𝐟𝐟𝐞𝐜𝐭, 𝐜𝐥𝐨𝐬𝐮𝐫𝐞𝐬, 𝐚𝐧𝐝 𝐬𝐭𝐚𝐭𝐞 𝐮𝐩𝐝𝐚𝐭𝐞𝐬 Like many developers, I used to believe that when state updates, every async callback automatically gets the latest value. But this simple example proved me wrong: function App() { const [count, setCount] = useState(0); console.log("Render", count); useEffect(() => { setTimeout(() => { setCount(count + 1); setCount(count + 1); }, 1000); }, []); return null; } 👉 My expectation: count should become 2 👉 Reality: count becomes 1 Why? Because the setTimeout callback captures the initial state (0) — a concept known as 𝐬𝐭𝐚𝐥𝐞 𝐜𝐥𝐨𝐬𝐮𝐫𝐞. So React actually receives: setCount(1) setCount(1) And due to batching, both updates collapse into a single update. ✅ Final console output: Render 0 Render 1 💡 𝐁𝐢𝐠𝐠𝐞𝐬𝐭 𝐥𝐞𝐬𝐬𝐨𝐧: If your state update depends on previous state, never use the value directly inside async callbacks. Instead use functional updates: setCount(c => c + 1); setCount(c => c + 1); Now React uses the latest queued state and the result becomes 2. 𝐓𝐡𝐢𝐬 𝐬𝐦𝐚𝐥𝐥 𝐜𝐨𝐧𝐜𝐞𝐩𝐭 𝐞𝐱𝐩𝐥𝐚𝐢𝐧𝐬 𝐬𝐨 𝐦𝐚𝐧𝐲 𝐫𝐞𝐚𝐥-𝐰𝐨𝐫𝐥𝐝 𝐛𝐮𝐠𝐬: • 𝐢𝐧𝐭𝐞𝐫𝐯𝐚𝐥𝐬 𝐥𝐨𝐠𝐠𝐢𝐧𝐠 𝐨𝐥𝐝 𝐯𝐚𝐥𝐮𝐞𝐬 • 𝐰𝐞𝐛𝐬𝐨𝐜𝐤𝐞𝐭 𝐜𝐚𝐥𝐥𝐛𝐚𝐜𝐤𝐬 𝐮𝐬𝐢𝐧𝐠 𝐬𝐭𝐚𝐥𝐞 𝐬𝐭𝐚𝐭𝐞 • 𝐫𝐚𝐜𝐞 𝐜𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧𝐬 𝐢𝐧 𝐚𝐬𝐲𝐧𝐜 𝐜𝐨𝐝𝐞 • 𝐮𝐧𝐞𝐱𝐩𝐞𝐜𝐭𝐞𝐝 𝐑𝐞𝐚𝐜𝐭 𝐢𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰 𝐪𝐮𝐞𝐬𝐭𝐢𝐨𝐧𝐬 Sometimes the hardest React problems aren’t about syntax — they’re about mental models. Learning how React thinks is far more powerful than memorizing APIs. If you're preparing for React interviews, mastering render vs commit phase, closures, and batching is a huge advantage 🚀 #React #Frontend #JavaScript #WebDevelopment #ReactJS #LearningInPublic

Why does React always ring twice? 🔔🔔 Day 73 of #100DaysOfCode - CogniChat Update 🚀 Today was supposed to be a pure "UI Polish" day. I spent hours perfecting the Glassmorphism look for the Login/Signup screens. I fixed the layout alignment for the First & Last Name inputs (making it actually industry-standard and responsive). It looks clean. It feels professional. Then, I tested the success message. The Bug (Watch the video): I click login once. The app notifies me twice. It’s the classic React "Double Render" ghost—likely React.StrictMode doing its job in development, or a zombie event listener I forgot to clean up. The Irony? 😅 The LeetCode problem I solved today was "Contains Duplicate." I solved the algorithm, but apparently, my frontend missed the memo. The universe definitely has a sense of humor. Current Status: 🎨 UI: Glassmorphism is 90% done. 🐛 Bug: Hunting down the double-fire issue. 🧠 DSA: Solved "Contains Duplicate" (Video coming soon). Links: 💻 Code: https://lnkd.in/gZqFDF9t 🚀 Live: https://lnkd.in/gJ5hSAYV 🧩 LeetCode: https://lnkd.in/gw-n6TnG React Devs: Is StrictMode the first thing you disable, or do you respect the double-render? 👇 #WebDevelopment #ReactJS #MERNStack #BugLife #UIUX #Glassmorphism #LeetCode #JuniorDeveloper #BuildInPublic

useMemo. useCallback. React.memo. Developers treat these as features. They're not. They're workarounds. Every state change in React triggers a full component re-render. The entire function re-executes. A new Virtual DOM tree is produced. A diffing algorithm compares old vs new. Patches are computed and applied. You're paying the cost of diffing an entire tree just to update a single text node. Memoization can prune branches, but it introduces its own overhead - dependency comparison, cognitive complexity, and it's entirely opt-in. You have to manually identify what to memoize. Miss one spot and your "optimized" app is back to re-rendering everything. What if the framework just... didn't re-render? In Granular, components execute once. When a reactive value changes, only the specific DOM node bound to that value updates. Nothing else runs. Nothing else is compared. No memoization needed. No optimization hooks. No mental model of "which renders can I skip." Full explanation: https://lnkd.in/dtQqp9YW #javascript #frontend #react #webdev #performance

React becomes truly powerful when you move beyond basics and start leveraging its advanced patterns. Recently, I’ve been exploring: ✅ Render Props for flexible component composition ✅ Higher-Order Components for cross-cutting concerns ✅ Custom Hooks for clean logic reuse ✅ Code Splitting to improve real-world performance What stands out: most React performance problems are architectural, not library-related. Still refining how and when to apply these patterns in production-scale apps. What advanced React pattern has given you the biggest win? #React #ReactJS #FrontendDevelopment #WebDevelopment #JavaScript #SoftwareEngineering #CleanCode #FrontendArchitecture #PerformanceOptimization #UIEngineering #TechLearning #Developers #CodingCommunity

If a React Component doesn't have a name, it doesn't belong in your codebase. Naming components isn't just about "pretty code"—it's about debuggability & readability. When you export anonymous arrow functions, your stack traces and React DevTools become a sea of "Anonymous" components. It's the developer equivalent of looking for a needle in a haystack... while wearing a blindfold. 盲 Naming your components is a small habit that pays huge dividends: 1️⃣ Debugging: Know exactly which component crashed without hunting. 2️⃣ DevTools Clarity: Your component tree stays readable at a glance. 3️⃣ Collaboration: Your teammates don't have to guess what index.tsx is actually rendering. 4️⃣ Stack Traces: Errors point to <ProductCard>, not anonymous. Small habits lead to scalable, maintainable codebases. How do you handle exports in your team? Do you enforce named functions, or is it a "wild west" of anonymous exports? 👇 #ReactJS #ReactTips #WebDevelopment #React #CleanCode #CodingTips #Frontend #CodingBestPractices #CodeQuality #itsmacr8

React Error Handling, Error Boundary & Lazy Loading Explained 🚀 While building scalable React applications, I focused on improving stability and performance using some essential concepts: 🔹 Error Handling in React Implemented proper error handling using try-catch for API calls, optional chaining (?.) to prevent undefined errors, and conditional rendering with if-else to ensure smoother user experience. 🔹 Error Boundaries Used Error Boundaries to catch unexpected UI errors and prevent the entire application from crashing — making the app more production-ready. 🔹 Lazy Loading & Code Splitting Optimized performance using React.lazy and Suspense to reduce bundle size and load components only when needed. These techniques significantly improve application reliability, maintainability, and performance — especially in real-world production projects. 🎥 I’ve explained these concepts step-by-step in my latest YouTube videos: 👉Error Handling: [https://lnkd.in/dX3DgaSh] 👉Error Boundary: [https://lnkd.in/dajUSmXS] 👉Lazy Loading: [https://lnkd.in/dvkHSH4N] Let’s connect and grow together: 🔗 LinkedIn: [ https://lnkd.in/d4VFcWrR] 💻 GitHub: [https://lnkd.in/dcgMPcBJ] #ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #PerformanceOptimization #ErrorHandling #CodeSplitting #SoftwareDevelopment #LearningInPublic

𝙏𝙝𝙚 𝙡𝙤𝙜𝙞𝙘 𝙗𝙚𝙝𝙞𝙣𝙙 𝙩𝙝𝙚 "𝙇𝙤𝙖𝙙𝙞𝙣𝙜" 𝙨𝙥𝙞𝙣𝙣𝙚𝙧. ⏳ In my last few posts, I talked about React state and the "invisible logic" of the frontend. But there is one thing that dictates our state more than anything else: 𝙋𝙧𝙤𝙢𝙞𝙨𝙚𝙨. In React, a Promise isn't just a JS concept—it’s the difference between a smooth UI and a broken one. I’ve realized that managing a Promise is really about managing three specific React states: ⏳ 𝙋𝙚𝙣𝙙𝙞𝙣𝙜 (𝙞𝙨𝙇𝙤𝙖𝙙𝙞𝙣𝙜): Keeping the user engaged while the data is in flight. ✅ 𝙁𝙪𝙡𝙛𝙞𝙡𝙡𝙚𝙙 (𝙙𝙖𝙩𝙖): Moving raw API responses into our component state. ❌ 𝙍𝙚𝙟𝙚𝙘𝙩𝙚𝙙 (𝙞𝙨𝙀𝙧𝙧𝙤𝙧): Gracefully handling the "Broken Promise" so the app doesn't crash. If we "promise" a user a feature but don't handle the rejection, we haven't built a UI—we’ve built a trap. My focus right now is moving away from "Happy Path" coding toward robust, predictable logic. Handling every .catch() as carefully as every .then(). How are you handling your "Broken Promises" in React today? Let’s connect! #ReactJS #JavaScript #WebDevelopment #FrontendEngineering #CleanCode #BCA #CodingLogic

I remember a time when my React components were passing props… to other components… which passed them again… and again. It worked, but every small change felt risky and annoying. That’s when I really understood the value of #Context API. Instead of threading data through multiple layers, Context let me share things like user state and themes exactly where they were needed. The code instantly felt cleaner, easier to reason about, and way less fragile. It’s not a magic solution for every state problem — but for the right use cases, it simplifies your app more than you’d expect. Funny how a small change in approach can make development feel enjoyable again. #React #ContextAPI #Frontend #JavaScript #Learning #WebDevelopment

🚀 Day 1 of sharing daily dev learnings Today’s topic: React Performance ⚡ Problem: My page was re-rendering too many times. Even small state changes were slowing the UI. Mistake: I was recalculating heavy data on every render. Fix: Used useMemo to memoize derived values. Example: const filtered = useMemo(() => { return users.filter(u => u.active) }, [users]) Result: ✅ Faster renders ✅ Smoother UI ✅ Cleaner logic Lesson: Don’t optimize everything. Optimize expensive computations only. Small React improvements like this make a BIG difference in production apps. What’s one React optimization you use often? 👇 #ReactJS #Frontend #WebDevelopment #JavaScript #100DaysOfCode

Why useEffect Is the Most Misunderstood Hook in React 📢 When I first started using React, I thought useEffect was simple. “Run this after render.” That’s it. But the more I worked with it, the more I realized… useEffect is not about lifecycle. It’s about synchronization. The Biggest Misunderstanding Many developers treat useEffect like: - componentDidMount - componentDidUpdate Or a place to “just put side effects” That mindset causes: - Infinite loops - Missing dependency bugs - Unnecessary API calls - Confusing behavior What useEffect Actually Is? useEffect exists to synchronize your component with something outside of React. That could be: - An API request - A subscription - A timer - The browser DOM - Local storage If there’s nothing external to sync with… You probably don’t need useEffect. The Dependency Array Is Not Optional This is where most bugs happen. When you ignore dependencies: - React re-runs the effect unexpectedly - Or worse… doesn’t re-run when it should The dependency array is not about controlling when the effect runs. It’s about telling React: “This effect depends on these values. If they change, re-sync.” That mental shift changes everything. Common Mistake Using useEffect to derive state: Common Mistake Using useEffect to derive state: useEffect(() => {  setFullName(firstName + " " + lastName); }, [firstName, lastName]); You don’t need this. You can compute it directly: const fullName = firstName + " " + lastName; No effect needed. If you can calculate it during render, you don’t need useEffect. A Better Rule Before writing an effect, ask: 👉 “What external system am I synchronizing with?” If the answer is “none” — rethink it. Final Thought useEffect isn’t complicated. Our mental model is. Once you stop thinking in lifecycle terms and start thinking in synchronization terms… everything becomes clearer. Sharing what I learn about React and backend fundamentals. Follow for more practical breakdowns. . . . . . . #ReactJS   #FrontendDevelopment   #JavaScript   #WebDevelopment   #SoftwareEngineering   #ReactHooks   #LearnToCode