React Child Component Re-renders: Why They Happen and How to Fix Them

🚀 Day 22/30 – Folder Structure (Scalable React Apps) Most React projects don’t fail because of code… 👉 They fail because of bad structure 😵 Today I learned how real-world React apps are structured ⚡ 👉 Folder Structure (Industry Level) 💻 The Problem: Everything works fine… until your app grows 👀 ❌ Files everywhere ❌ Hard to find logic ❌ Debugging becomes painful 💻 The Solution: 👉 Feature-based architecture (used in production) ✅ 📁 Example Structure: src/ ┣ app/ → app setup (store, providers) ┣ features/ → business logic (modular) ┃ ┣ auth/ ┃ ┃ ┣ components/ ┃ ┃ ┣ pages/ ┃ ┃ ┣ services/ ┃ ┃ ┣ hooks/ ┃ ┃ ┗ authSlice.js ┃ ┣ user/ ┃ ┗ product/ ┣ shared/ → reusable code ┃ ┣ components/ ┃ ┣ hooks/ ┃ ┣ utils/ ┃ ┗ constants/ ┣ services/ → API config ┣ routes/ → routing ┣ layouts/ → layouts ┣ assets/ → images ┣ App.jsx ┗ main.jsx 💡 Why this is powerful: ✅ Each feature is isolated ✅ Easy to scale without chaos ✅ Teams can work independently 🔥 Reality Check: 👉 Small apps → basic structure works 👉 Real apps → need architecture ⚡ Advanced Insight: Most beginners organize by file type ❌ Real developers organize by feature/domain ✅ 🔥 Key Takeaway: Clean architecture > clean code Be honest 👇 Are you still using basic folders… or building scalable apps? 🚀 #React #FrontendDevelopment #JavaScript #CleanCode #Architecture

🚀 How React Actually Works (In Simple Terms) If you're using React but still feel like it's magic — this post is for you 👇 🔹 1. It’s All About Components React apps are built using components — small, reusable pieces of UI. Think of them like LEGO blocks 🧱 that you can combine to build complex apps. 🔹 2. Virtual DOM (The Secret Sauce) Instead of updating the real DOM directly (which is slow), React creates a lightweight copy called the Virtual DOM. When something changes, React: * Compares old vs new Virtual DOM (diffing) * Updates only what changed (efficient ⚡) 🔹 3. State & Props * State → Data that changes inside a component * Props → Data passed from parent to child Whenever state changes, React automatically re-renders the component. 🔹 4. Reconciliation Process React uses a smart algorithm to figure out the minimum number of changes needed in the UI. This makes your app fast and optimized. 🔹 5. One-Way Data Flow Data flows from parent → child components This makes debugging easier and your app predictable. 🔹 6. Hooks (Modern React) Hooks like: * useState 🧠 * useEffect 🔄 allow you to use state and lifecycle features in functional components. 💡 In Short: React updates the UI efficiently by: 👉 Tracking changes 👉 Comparing Virtual DOM 👉 Updating only what's needed That’s why React apps feel fast and smooth ⚡ 🔥 Pro Tip: If you truly understand how React works internally, debugging and performance optimization becomes 10x easier. #ReactJS #FrontendDevelopment #WebDevelopment #JavaScript #MERN #Coding #SoftwareEngineering #Tech

I improved a React app’s render performance by ~12%… by removing useMemo. ⚡ Yes — removing it. Most developers treat useMemo like a safety net: “Wrap it… just in case.” I used to do the same. That was the mistake. ❌ The problem // Memoizing a trivially cheap value const fullName = useMemo(() => { return `${firstName} ${lastName}`; }, [firstName, lastName]); Looks clean, right? But here’s what actually happens: - React stores the memoized value - Tracks dependencies - Compares them on every render For something as cheap as string concatenation… 👉 the overhead costs more than the computation. ✅ The fix // Just compute it inline — zero overhead const fullName = `${firstName} ${lastName}`; Use useMemo only when the computation is actually expensive: const sortedList = useMemo(() => { return items.sort((a, b) => b.score - a.score); }, [items]); 💡 Why this matters - No unnecessary memoization overhead - Cleaner, more readable code - Easier debugging & profiling - useMemo becomes a meaningful signal (not noise) 📊 Real impact In a component tree with 40+ memoized values, removing unnecessary useMemo calls reduced render time by ~12%. Sometimes, the best optimization is… 👉 removing the “optimization”. 🔍 I’ve seen this a lot in data-heavy dashboards and complex UI systems, where premature memoization quietly hurts performance instead of helping. 💬 What React optimization habit did you have to unlearn the hard way? #React #Frontend #WebPerformance #JavaScript #CleanCode #SoftwareEngineering

Your React app isn't slow. Your folder structure is just a mess. When a React project grows, the "group by file type" approach breaks down. Putting all components in one folder, hooks in another, and utils somewhere else is a recipe for disaster. You end up scrolling through hundreds of files just to fix one bug. Here is how you structure a large React project for scale. Stop grouping by file type. Start grouping by feature. A feature-based architecture means everything related to a specific part of your app lives together. If you are working on the authentication flow, you should not have to leave the auth folder. Inside your src directory, structure it like this: src/  features/   auth/    components/    hooks/    services/    auth.slice.ts    index.ts  shared/   components/    Button.tsx   hooks/    useClickOutside.ts   utils/    formatDate.ts  app/   store.ts   router.tsx Why this works better: 1. High Cohesion Everything a feature needs is in one place. No more jumping between 5 different directories to understand a single workflow. 2. Strict Boundaries Features should not reach into other features' internals. Use an index.ts file to explicitly export only what is necessary. 3. Easier Onboarding New developers can look at the features folder and immediately understand what the application actually does. When a feature gets too complex, it naturally splits into smaller features. This scales infinitely better than the traditional flat structure. #reactjs #javascript #webdevelopment #frontend #softwareengineering #coding #architecture #cleancode #webdev #reactdeveloper

⚛️ Zustand — A Clean & Minimal Approach to State Management in React When building applications with React, one thing that really impacts code quality over time is how you manage state. There are plenty of options out there, but Zustand stands out for keeping things simple without sacrificing flexibility. 🧠 What is Zustand? Zustand is a lightweight state management library that lets you manage global state with very little setup. 👉 No providers 👉 No reducers 👉 No heavy boilerplate It keeps things straightforward and easy to reason about. ⚡ How it works At its core, Zustand is just a simple store: import { create } from "zustand"; const useStore = create((set) => ({ count: 0, increment: () => set((state) => ({ count: state.count + 1 })), })); And you can use it anywhere in your app: const count = useStore((state) => state.count); const increment = useStore((state) => state.increment); No extra wrapping or complex setup needed. 🔥 Why Zustand works well ✔ Clean and minimal API ✔ Updates only what actually changes (better performance) ✔ No need to wrap your entire app ✔ Helps you move faster with less code ⚠️ Where to be cautious Zustand is great, but it’s not a one-size-fits-all solution. 👉 For large-scale apps with complex workflows 👉 When you need strict structure or advanced debugging tools you might want something more opinionated. 💡 Practical perspective Zustand fits really well when: ✔ Your app is small to medium in size ✔ You want to keep things simple ✔ You don’t need heavy state architecture 🚀 Final thought State management doesn’t have to be complicated. Sometimes, keeping things simple is the best decision you can make for your codebase. ❓ What are you using in your projects — Redux or Zustand? 📌 I’ll share a detailed comparison of Redux vs Zustand in my next post. #reactjs #zustand #redux #frontenddevelopment #javascript #webdevelopment #softwareengineering #fullstackdeveloper #dotnetfullstackdeveloper #react

🚀React Bundle Analysis & Optimization Your React app might look fine… But if your bundle is heavy, users will feel the slowdown ⚠️ Let’s break this down simply 👇 🧩 What is a Bundle? 👉 When you build a React app, all your code + libraries are combined into JavaScript files (bundles) 💡 Example: • React • UI libraries • Utility functions ➡️ All packed into one or multiple JS files ⚠️ Why Large Bundles Are a Problem ❌ Slow initial load ❌ More JavaScript to execute ❌ Poor performance on low-end devices 👉 Bigger bundle = Slower app 🔍 What is Bundle Analysis? 👉 It helps you understand: • Which library is heavy • What is increasing bundle size • Where optimization is needed 📊 Tools give a visual breakdown of your bundle 🛠️ Tools You Can Use ✔ webpack-bundle-analyzer ✔ source-map-explorer 👉 Shows which dependency is taking the most space ⚡ How to Optimize Bundle 🧩 1. Code Splitting → Break bundle into smaller chunks ⚡ 2. Lazy Loading → Load components only when needed 🌳 3. Tree Shaking → Remove unused code automatically 📦 4. Dynamic Imports → Load heavy modules on demand 🧹 5. Remove Heavy Libraries → Replace with lighter alternatives 🔥 Real Impact ✔ Faster load time ✔ Better performance ✔ Improved user experience ✔ Smaller bundle size 🧠 Simple Way to Understand • Without Optimization → Big bundle → Slow app ❌ • With Optimization → Small chunks → Fast app ✅ 💬 Have you ever checked what’s inside your bundle? #React #WebPerformance #Frontend #JavaScript #WebDevelopment #Optimization #Coding #SoftwareEngineering

🚀 Day 28/30 – useCallback (Stable Function References) Your child component still re-renders… even after using React.memo? 👀 Today I learned why that happens — and how to fix it ⚡ 👉 useCallback 💻 The Hidden Problem: Every render creates a new function reference ❌ That means: 👉 Parent re-renders 👉 New function gets passed as prop 👉 Child sees changed prop 👉 Child re-renders again Even with React.memo 💻 The Solution: Use useCallback ✅ It memoizes functions and keeps the same reference until dependencies change. 💻 Example: import { useState, useCallback } from "react"; const Child = React.memo(({ onClick }) => { console.log("Child Rendered"); return Click; }); function App() { const [count, setCount] = useState(0); const handleClick = useCallback(() => { console.log("Clicked"); }, []); return ( <> <button onClick={() => setCount(count + 1)}> {count} <Child onClick={handleClick} /> </> ); } 🔥 What actually happens: 1️⃣ Parent re-renders 2️⃣ handleClick keeps same reference 3️⃣ Child prop unchanged 4️⃣ React.memo skips child render ⚡ 💡 Why this matters: ✅ Better performance ✅ Fewer wasted renders ✅ Useful in optimized apps ⚡ Real Use Cases: Memoized child components Large lists with actions Dashboard widgets Event handlers passed deeply ⚡ Advanced Insight: Don’t use useCallback everywhere ❌ If no memoized child depends on it, it may add unnecessary complexity. 🔥 Key Takeaway: React.memo protects components. useCallback protects function props. Be honest 👇 Are you using useCallback smartly… or just because tutorials said so? 👀 #React #useCallback #Performance #FrontendDevelopment #JavaScript

🚀 Day 27/30 – React.memo (Stop Unnecessary Re-renders) Your app feels slow… but the issue might not be logic. 👉 It might be unnecessary re-renders 👀 Today I learned one of the most underrated React optimization tools ⚡ 👉 React.memo --- 💻 The Hidden Problem: You update one state in parent component… But React may also re-render child components ❌ Even when nothing changed. That means: ❌ Wasted renders ❌ Slower UI ❌ Poor performance in large apps --- 💻 The Solution: Use "React.memo" ✅ It tells React: 👉 “If props are same, skip re-render.” --- 💻 Example: const Child = React.memo(({ name }) => { console.log("Child Rendered"); return <h2>Hello {name}</h2>; }); function App() { const [count, setCount] = useState(0); return ( <> <button onClick={() => setCount(count + 1)}> {count} </button> <Child name="Umakant" /> </> ); } --- 🔥 What actually happens: 1️⃣ Count changes 2️⃣ Parent re-renders 3️⃣ Child gets same props 4️⃣ React skips Child render ⚡ --- 💡 Why this matters: ✅ Faster UI ✅ Better scalability ✅ Less wasted rendering work Especially useful in: - Dashboards - Large lists - Complex child components - Real production apps --- ⚡ Advanced Insight: "React.memo" uses shallow prop comparison 👀 So these can still re-render child: ❌ New object props ❌ New function props 👉 That’s why "useCallback" + "useMemo" are powerful partners. --- 🔥 Key Takeaway: Not every render is a problem… But unnecessary renders become expensive at scale. --- Be honest 👇 Have you ever optimized re-renders… or are you only styling components? 🚀 #React #ReactMemo #Performance #FrontendDevelopment #JavaScript

Your React app feels slow, and you have no idea why. The truth is, it is probably re-rendering 10x more than it should be. React core philosophy is that UI is a function of state. When state changes, React re-evaluates the component tree. But if you are not careful, a single state change at the top of your tree can trigger a massive wave of unnecessary re-renders all the way down to the bottom. Here are the 3 most common reasons your React app is re-rendering too much: 1. Passing new object references in props. If you pass an inline object or function like style={{ color: 'red' }} or onClick={() => doSomething()}, React sees a brand new reference on every single render. Even if the contents are identical, React thinks the prop changed. 2. State lifted too high. If you have a form input that updates on every keystroke, and its state lives in a parent component alongside heavy data tables, typing one letter re-renders the entire table. 3. Missing memoization. Complex calculations or heavy child components that do not depend on the changed state will still re-render by default. React is fast, but it is not magic. Example: Instead of passing inline functions like this: <Button onClick={() => handleSubmit()} /> Use useCallback to keep the reference stable: const handleSubmit = useCallback(() => { ... }, []); <Button onClick={handleSubmit} /> Key takeaways: - Keep state as close to where it is used as possible. - Use memo for expensive child components. - Use useMemo and useCallback to preserve reference equality for objects and functions passed as props. #reactjs #webdevelopment #frontend #javascript #performance #softwareengineering #coding #webdev #reactdeveloper #programming

🚀 𝗗𝗲𝗰𝗼𝗱𝗲 𝗠𝗘𝗥𝗡 𝘄𝗶𝘁𝗵 𝗠𝗲 – 𝗗𝗮𝘆 𝟳 Today’s focus wasn’t just UI… It was about writing smarter React code. I explored 𝗖𝘂𝘀𝘁𝗼𝗺 𝗛𝗼𝗼𝗸𝘀— a concept that changes how you structure your applications. Instead of repeating logic in multiple components, I learned how to extract it into a reusable function. So I built a simple project to apply it 👇 📌 𝗣𝗿𝗼𝗷𝗲𝗰𝘁: Notes App with Auto Save A minimal app, but with a strong concept behind it. ✔ Notes are saved automatically ✔ Data persists even after refresh ✔ No backend used — everything handled in the browser ✔ Clean and simple UI with Tailwind CSS ⚙️ 𝗪𝗵𝗮𝘁 𝗺𝗮𝗱𝗲 𝗶𝘁 𝗶𝗻𝘁𝗲𝗿𝗲𝘀𝘁𝗶𝗻𝗴? I created a custom hook: useLocalStorage This hook handles: • State management • Data storage • Sync between UI and localStorage One hook → reusable logic → cleaner components 🧠 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆: When your logic is reusable, your code becomes scalable. And that’s where React starts to feel powerful. 🔗 𝗖𝗼𝗱𝗲: https://lnkd.in/gBuMk4TG Learning one concept at a time. Building one project at a time. #MERN #ReactJS #CustomHooks #WebDevelopment #LearningInPublic #100DaysOfCode