React Keys: Why Unique IDs Matter for Efficient Updates

Bubbling Concept in React: A Practical Breakdown 🚀 Why Your React Button Click Triggers the Parent (And How to Fix It) One small function can save you from unexpected UI behavior: e.stopPropagation() But what does it actually do? In JavaScript and React, events “bubble up” the DOM tree. That means when you click on a child element, the click event also triggers on its parent elements. Example: <div onClick={() => console.log("Parent clicked")}> <button onClick={() => console.log("Button clicked")}> Click Me </button> </div> If you click the button, the console will log: Button clicked Parent clicked Why? Because the click event bubbles from the button to the parent. 🛑 Preventing Event Bubbling If you want the button click to NOT trigger the parent’s click handler, use: <button onClick={(e) => { e.stopPropagation(); console.log("Button clicked"); }} > Click Me </button> Now only this runs: Button clicked 🛒 Real-World Example Imagine a clickable product card: <div onClick={() => navigate("/product/1")}> <button onClick={addToCart}> Add to Cart </button> </div> Without stopPropagation(), clicking “Add to Cart” will also navigate to the product page. Solution: <button onClick={(e) => { e.stopPropagation(); addToCart(); }} > Add to Cart </button> Now: ✅ The product is added to cart ✅ No unwanted navigation Understanding event propagation is essential for building predictable and clean UI behavior in React applications. Small detail. Big impact. #React #JavaScript #FrontendDevelopment #WebDevelopment

How React Remembers State Between Renders? When a component re-renders, the function runs again from top to bottom. So how does useState not reset every time? 🤔 function Counter() { const [count, setCount] = React.useState(0); return <button onClick={() => setCount(count + 1)}>{count}</button>; } Every render: The function runs again and Variables are recreated. So why doesn’t count go back to 0? What Actually Happens Internally React stores state outside the component function. Behind the scenes: 1) Each component has a Fiber node 2) React keeps a linked list of Hooks 3) It tracks Hooks based on call order State is not stored in your function. It’s stored in React’s internal Fiber system. The function is just a way for React to describe UI. Understanding this makes Hooks feel much less magical. #ReactJS #ReactInternals #ReactHooks #FrontendDevelopment #SoftwareEngineering #JavaScript

Frontend Learning: How Virtual DOM Actually Works in React (Step-by-Step) One concept that truly changed frontend performance is the Virtual DOM in React. Here’s the simple 5-step mental model I use 👇 🔹 1️⃣ Initial Render Component returns JSX → React creates a Virtual DOM tree (lightweight JS object). This is then used to generate the Real DOM in the browser. 🔹 2️⃣ State or Props Change When state/props update, React creates a new Virtual DOM in memory. No direct DOM manipulation yet. 🔹 3️⃣ Diffing React compares the previous Virtual DOM with the new one. It calculates the minimal set of changes required. 🔹 4️⃣ Reconciliation Based on the diff, React determines exactly which nodes in the Real DOM must update. 🔹 5️⃣ Efficient DOM Update Only the changed elements are updated — not the entire DOM. This selective update makes UI rendering significantly faster. 💡 Senior takeaway: Virtual DOM isn’t “faster DOM” — it’s a smarter update strategy that minimizes expensive browser operations. Understanding this helps when optimizing re-renders, handling large lists, or debugging performance issues. What’s your go-to strategy when optimizing heavy UI updates? 👇 #FrontendLearning #ReactJS #FrontendEngineering #WebPerformance #JavaScript

What Runs First in React? (Rendering vs useEffect vs useCallback vs useMemo) One day I wrote this small React code just to test my understanding: import { useEffect, useCallback, useMemo } from "react"; export default function App() { useEffect(() => { console.log("useEffect"); }, []); const increment = useCallback(() => { console.log("useCallback"); }, []); const squaredCount = useMemo(() => { console.log("useMemo"); }, []); return ( <div> {console.log("Rendering JSX")} </div> ); } And I asked myself: 👉 What runs first? At first, I guessed randomly. But then I stopped thinking like a coder… and started thinking like React. 🧠 Step 1: React always renders first React’s first job is simple: Build the UI. So this runs first: Rendering JSX Because React must render before doing anything else. 🧠 Step 2: During rendering While React is rendering: • useMemo runs immediately (it calculates something) • useCallback does NOT execute — it only stores the function So you’ll see: useMemo✅ But not: useCallback❌ That function only runs if we call increment() manually. That was my “aha” moment 💡 🧠 Step 3: After rendering → useEffect runs Once the UI is painted, React runs: useEffect Because useEffect always runs after render. ✅ Final Order (on first mount) 1️⃣ Rendering JSX 2️⃣ useMemo 3️⃣ useEffect (useCallback only runs if called) 💡 The lesson I learned Don’t just learn hooks. Learn when they run. Understanding execution order made debugging 10x easier for me. Now whenever something feels “weird” in React, I ask one question: 👉 Is this running during render or after render? Still learning React in human language. 🚀 #JavaScript #FrontendDevelopment #LearningInPublic #CleanCode #ReactJS #useEffect #useMemo #useCallback #FrontendDevelopment #LearningInPublic #JavaScript #WebDevelopment #DeveloperJourney #ReactHook

While starting to learn React, I decided to keep things simple. I built the same Todo List twice with the same UI design: First using pure JavaScript, Then rebuilding it with React. This helped me clearly see the difference between: • JavaScript DOM manipulation • React’s component-based thinking Project features: • Add new tasks • Delete tasks • Toggle task completion • Search tasks • Filter tasks (All / Completed / Not Completed) Small project, but a big learning step for me. Live Demo: JS version: https://lnkd.in/ebWQRNar React version: https://lnkd.in/eJt2Svj7 #React #JavaScript #FrontendDevelopment #WebDevelopment #LearningInPublic #TodoApp

I just finished Frontend Masters “A Tour of JavaScript & React Patterns” and the biggest mindset shift for me was this: Most React “performance problems” are actually rendering problems. Not “React is slow”, but “I accidentally made more of the tree render than needed”. A few things I’m taking away and actively applying: ✅ Context is not a state manager It is a delivery mechanism. If the value changes often, it becomes a re-render broadcaster. That is perfect for “rarely changes” state (theme, locale, auth), risky for high frequency state. ✅ The fastest component is the one that does not re-render Before reaching for memo everywhere, I ask: Can I move state down? Can I split the provider? Can I pass a stable callback? Can I avoid creating new objects in props? ✅ Render cost is usually in the children Even small parent changes can re-render expensive lists, charts, tables. Splitting components and isolating heavy parts pays off more than micro-optimizing one hook. ✅ Patterns are about shaping render boundaries Custom hooks, compound components, provider splitting, controlled vs uncontrolled components. These are not just “clean code” choices. They decide how much UI updates when data changes. And a big one outside the component tree: ✅ Performance starts before React even runs Choosing the right rendering strategy changes the whole user experience: CSR when you need app-like interactivity and data is truly user-specific SSR when you need fast first paint plus fresh data per request SSG when content is stable and you want maximum speed ISR when you want SSG speed but still keep content reasonably fresh without rebuilding everything Simple rule I like now: Architecture is often performance in disguise, both in your component tree and in your rendering strategy. #react #nextjs #javascript #performance #frontend #webdevelopment #softwareengineering

𝗥𝗲𝗮𝗰𝘁 𝗘𝘅𝗽𝗲𝗻𝘀𝗲 𝗦𝗽𝗹𝗶𝘁𝘁𝗶𝗻𝗴 𝗔𝗽𝗽 Just a small React application to better understand how state, logic, and UI stay in sync. This project simulates splitting expenses with friends. While it looks simple, building it forced me to think carefully about how React state should be structured and updated. I worked with multiple pieces of state at once — the friends list, the selected friend, form inputs, and derived values like balances — and learned how easily things can break if state responsibilities aren’t clear. Some key things this project helped me understand better: • how to update complex state immutably using map and functional • state updates • how derived values (like who owes whom) don’t always need their own state • how conditional rendering simplifies UI instead of adding complexity • how lifting state up keeps different parts of the UI consistent One important realization for me was that React becomes much easier to reason about when the UI is treated as a direct result of state, not something to be manually controlled. Small projects like this are helping me move away from guessing and towards writing React code that feels predictable, explainable, and easier to debug. Still learning React fundamentals, still building, and enjoying the process. #React #ReactJS #JavaScript #FrontendDevelopment #WebDevelopment #ReactDeveloper #LearningInPublic #BuildInPublic

𝗪𝗵𝘆 𝘁𝗵𝗲 𝗸𝗲𝘆 𝗣𝗿𝗼𝗽 𝗶𝗻 𝗥𝗲𝗮𝗰𝘁 𝗜𝘀 𝗠𝗼𝗿𝗲 𝗜𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝗧𝗵𝗮𝗻 𝗬𝗼𝘂 𝗧𝗵𝗶𝗻𝗸 Most developers know: “You should add a key when rendering lists.” But many don’t fully understand why. Example: {users.map((user, index) => ( <UserCard key={index} user={user} /> ))} This works. But using an index as a key can cause subtle bugs. Why? Because React uses the key to: • Identify which items changed • Reuse existing DOM nodes • Decide what to update If the list order changes and you’re using the index as the key: React may reuse the wrong component instance. This can lead to: • Wrong UI updates • Input fields losing focus • State appearing in the wrong item Better approach: {users.map((user) => ( <UserCard key={user.id} user={user} /> ))} A stable, unique key helps React track items correctly. The key prop isn’t just a warning fix. It directly affects how React’s reconciliation works. Small detail. Big impact. Day 8/100 — sharing practical frontend engineering lessons. Have you ever faced a bug because of incorrect keys? #ReactJS #FrontendEngineering #JavaScript #WebDevelopment #SoftwareArchitecture

Why This useEffect Runs More Than You Expect ⚛️ Ever written this and thought React was misbehaving? useEffect(() => { fetchData(); }, [fetchData]); The effect runs again… and again… 😵💫 React isn’t buggy. It’s being very precise. What React actually sees 👇 React reads this as: “Run this effect after every render where the reference of fetchData changes.” Not when the logic changes. Not when the output changes. Only when the reference changes. Here’s the hidden gotcha 🧠 In JavaScript, functions are objects. So if fetchData is defined inside your component: const fetchData = () => { // API call }; A new function is created on every render. From React’s perspective: prevFetchData !== nextFetchData // true ➡️ Dependency changed ➡️ Effect runs again Even if the function looks identical. This isn’t a React quirk ❌ It’s a design choice. React avoids deep comparisons to stay: Fast Predictable Consistent Guessing here would cause far worse bugs. 💡 The takeaway If useEffect feels “random”, it usually isn’t. Your dependencies are changing, even when your values aren’t. Once you think in references instead of values, useEffect finally makes sense. 💬 Question for you: Which dependency caused your most confusing useEffect bug? #ReactJS #JavaScript #WebDevelopment #FrontendDevelopment #CodingBlockHisar #MERN #Hisar

🚀 Day 4/30 — Lists & Keys in React Continuing my 30 Days × 30 React Projects series, today’s focus was on understanding how React efficiently renders lists using keys. This project emphasizes how dynamic data is rendered in UI and why proper key usage is critical for performance and correctness. Key concepts covered: ➡️ Rendering lists using map() ➡️ Assigning unique keys to elements ➡️ Understanding React’s reconciliation process ➡️ Preventing unnecessary re-renders ➡️ Maintaining stable component identity Keys are not just a syntax requirement — they directly influence how React tracks and updates components in the Virtual DOM. Using improper keys (like array indices in unstable lists) can introduce subtle UI bugs and performance issues. Getting this right early prevents bigger problems later. 🔗 GitHub Repository: https://lnkd.in/duerXpu4 Why this matters long term: ➡️ Strengthens understanding of React reconciliation ➡️ Improves performance-aware thinking ➡️ Encourages clean dynamic rendering practices ➡️ Builds production-ready habits from the start Still focusing on fundamentals. Still building daily. ✅ More projects coming. ✅ Consistency over complexity. #ReactJS #FrontendDevelopment #WebDevelopment #LearningInPublic #JavaScript #ReactBasics #30DaysOfCode #FrontendEngineer