How React's Diffing Algorithm Works Internally

I used to think React was just "smart about re-renders." Then I actually dug into how reconciliation works. And I realized I had been writing components that quietly fought the algorithm for years. Here's what's actually happening under the hood — and why it matters for your app's performance. — When state changes, React doesn't touch the real DOM immediately. It builds a new Virtual DOM tree, compares it to the previous one, and figures out the minimum set of changes needed. That comparison process is reconciliation. The naive version of this problem is O(n³). For 1000 elements — that's a billion comparisons. Completely unusable. So React cheats. In a smart way. It uses a heuristic O(n) algorithm built on two assumptions: → Elements of different types always produce different trees → Keys tell React which elements are stable across renders Simple rules. Massive performance gain. — Here's where it gets interesting — and where most bugs actually come from. Rule 1 in practice: If you swap a <div> for a <section>, React tears down the entire subtree and rebuilds from scratch. Every child component unmounts. All local state is lost. This isn't a bug. It's the algorithm doing exactly what you told it to do. I've seen this cause subtle bugs in forms — a wrapper element change during a conditional render, and suddenly input state resets mid-user interaction. — Rule 2 in practice — the key trap: Using array index as a key is one of the most common mistakes I've reviewed in code. If you have a list and insert an item in the middle, every index below it shifts. React sees completely new keys, throws away the existing nodes, and rebuilds them. What looked like a simple insert becomes a full list re-render. Use stable, unique IDs. Always. — Fiber changed everything in React 16. Before Fiber, reconciliation was synchronous — once started, it couldn't be interrupted. A heavy render could block the main thread and freeze the UI. Fiber broke rendering into small units of work. React can now pause, prioritize, and resume rendering. That's what powers Concurrent Mode, Suspense, and transitions. The algorithm didn't change. The scheduler around it did. — Practical things I now do differently because of this: → Never create component definitions inside render — new reference = React thinks it's a different type = full unmount every render → Keys on lists always come from data, never from index → Wrap stable subtrees in React.memo when the parent re-renders frequently → Use the Profiler in DevTools to actually see which reconciliation decisions are expensive — Reconciliation is one of those things that's easy to ignore until performance starts hurting. But once you understand the two rules React operates on, a lot of "React behaves weirdly" moments suddenly make complete sense. What's the most unexpected reconciliation bug you've run into? #react #frontend #javascript #webdev #reactjs #frontenddevelopment #softwaredevelopment

When working with React, one of the most important ideas to understand is immutability. It affects how state is managed and how changes are detected within an application. In React, immutability is a core principle that directly influences how state changes are detected and how the user interface is updated. Immutability means you do not change existing data. Instead, you create new data when something needs to be updated. Why does React care about this? React decides whether to update the UI by checking if data has changed. It does not deeply inspect every value inside an object. It only checks if the reference has changed. In simple terms, React asks: “Is this the same object, or a new one?” If it is the same object, React assumes nothing changed. If it is a new object, React updates the UI. Here is where problems begin if you mutate data. Example of mutation (not recommended): const state = { count: 0 }; state.count = 1; setState(state); In this case, the object is modified directly. The reference remains the same, so React may not detect the change. Now the correct approach using immutability: const state = { count: 0 }; const newState = { ...state, count: 1 }; setState(newState); Here, a new object is created. Even though most values are the same, the reference is different. React sees this and updates the UI correctly. #react #web_devlopment

🔍 React 19.2: 3 anti-patterns now visible like never before You asked for a follow-up. Here it is. In the last post, I explained how DevTools in React 19.2 show the real reason behind every re-render. Today, I'm showing you 3 anti-patterns you used to ignore. But not anymore. Let's go. 1️⃣ Anonymous objects in props ❌ How many write: <div style={{ margin: 10, padding: 20 }}> ✅ How to fix: const boxStyle = { margin: 10, padding: 20 }; <div style={boxStyle}/> Why? A new object is created every time. React thinks: "Oh, props changed! Need to re-render!" In DevTools you'll see: "Style prop changed: new object created" 2️⃣ useEffect with no dependencies ❌ How many write: useEffect(() => { setCount(count + 1); }); ✅ How to fix: useEffect(() => { setCount(prev => prev + 1); }, []); Why? Without the dependency array, the effect runs after EVERY render. Hello, infinite loop. In DevTools you'll see: "Infinite render loop detected" 3️⃣ Custom hook returning a new function ❌ How many write: function useToggle() { const [value, setValue] = useState(false); return { value, toggle: () => setValue(v => !v) }; } ✅ How to fix: function useToggle() { const [value, setValue] = useState(false); const toggle = useCallback(() => setValue(v => !v), []); return { value, toggle }; } Why? Without useCallback, a new function is created on every call. The consumer component re-renders for no reason. In DevTools you'll see: "Toggle function changed: new reference" 📊 Summary 🔹 Anti-pattern #1 — Anonymous objects in props → Solution: extract object to a constant 🔹 Anti-pattern #2 — useEffect with no dependency array → Solution: add empty array [] 🔹 Anti-pattern #3 — New function on every render → Solution: wrap with useCallback 💬 Question for you Which of these three anti-patterns do you see most often in your codebase? Mine was #1. What about you? Drop your anti-patterns in the comments. #React19 #ReactJS #CleanCode #CodeReview #JavaScript #WebDev #ReactHooks #DevTools

A React component re-renders when state or props change. It also re-renders when its parent re-renders. That second one is where most performance bugs hide. On a trading dashboard updating 10 times per second, every wasted render is a dropped frame. Users notice. The app feels sluggish. And the fix isn't "rewrite it" — it's understanding three hooks and when to actually reach for them. The memoization toolkit in React is useMemo, useCallback, and React.memo. Most devs know what they do. Fewer know when not to use them. USEMEMO — CACHE AN EXPENSIVE COMPUTATION const processedData = useMemo(() =>  rawTrades.filter(t => t.volume > 1000).sort(...),  [rawTrades] // only recomputes when rawTrades changes ) Use this when the derivation is genuinely expensive — sorting, filtering, or aggregating large datasets. Don't use it to memoize a string concatenation. The cache itself has a cost. USECALLBACK — STABLE FUNCTION REFERENCE FOR CHILD PROPS const handleSelect = useCallback((id: string) => {  setSelected(id) }, []) // same reference across renders = child won't re-render Without this, a new function is created every render. If that function is passed as a prop to a memoized child, it breaks the memo — the child sees a "changed" prop and re-renders anyway. REACT.MEMO — SKIP RENDER IF PROPS HAVEN'T CHANGED const TradeRow = memo(({ trade }: { trade: Trade }) => {  return <tr>{trade.symbol}</tr> }) Only works when the props are stable. If you're passing a new object or function reference on every render, memo does nothing — you need useMemo and useCallback upstream first. Here's the answer pattern that lands well in interviews: "I'd profile first with React DevTools to confirm which components are actually re-rendering unnecessarily. Then I'd stabilise callback references with useCallback, memoize expensive derivations with useMemo, and wrap pure display components with React.memo. Memoization is a last resort — not a default — because it adds overhead. The profiler tells you where that overhead is justified." The word "profile" is doing a lot of work in that answer. It signals that you don't guess at performance problems — you measure them. That's what separates the senior answer from the junior one. The trap interviewers set: "So should I just wrap everything in memo?" The correct answer is no — and knowing why not is the whole point. What's the worst unnecessary re-render bug you've debugged? Drop it below 👇 #React #JavaScript #FrontendDevelopment #WebPerformance #SoftwareEngineering

A well-intentioned optimisation broke my component silently. Here's what happened. 🧵 I built a component that read a URL param and rendered based on it. It worked perfectly. Later, while optimising, the callback was wrapped in useCallback with all state dependencies correctly added. But one thing was missing. The URL param — fetched via useSearchParams — wasn’t in the dependency array. Reports came in: the component wasn’t updating when the URL changed. Tracing through the code, the issue was clear. The callback captured the initial param value and never updated. The UI changed, but the logic was stuck with stale data. The fix? One line: add the param to the dependency array. But the interesting part isn’t the fix. It’s why this was easy to miss. When we think “what does this depend on?”, we think props and state. Router values don’t feel like dependencies — but they are. 👉 This becomes even more subtle with useSearchParams vs useParams. Path params usually change during navigation, making bugs visible. Query params can change without navigation — the UI updates, but callbacks may still hold stale values. The lesson: → Optimisations should never change behaviour → Router values belong in dependency arrays → eslint-plugin-react-hooks (exhaustive-deps) catches this — use it Have you hit a stale closure bug in useCallback or useMemo? Drop it below 👇 (Detailed breakdown with code examples in comments) #React #JavaScript #Frontend #WebDevelopment #ReactHooks #SoftwareEngineering

Class-08 'Let's get classy' from the Namaste React course by Akshay Saini 🚀 01. How do you create Nested Routes react-router-dom cofiguration? npm i react-router Create a router and pass it to RouterProvider: import React from "react"; import ReactDOM from "react-dom/client"; import { createBrowserRouter } from "react-router"; import { RouterProvider } from "react-router/dom"; const router = createBrowserRouter([   {     path: "/",     Component: Root,     children: [       { index: true, Component: Home },       { path: "about", Component: About },       {         path: "auth",         Component: AuthLayout,         children: [           { path: "login", Component: Login },           { path: "register", Component: Register },         ]       },       { path: "concerts",        children: [         { index: true, Component: ConcertsHome },         { path: ":city", Component: ConcertsCity },         { path: "trending", Component: ConcertsTrending }       ]        }     ]   } ]) const root = document.getElementById("root"); ReactDOM.createRoot(root).render(   <RouterProvider router={router} /> ); 02. What is the order of life cycle method calls in Class Based Components? 1. constructor function 2. calling super function to initializes parent's constructor. 3. render method. (Mandatory) 4. React DOM (return JSX from the render method) 5. componentDidMount(){} 6. componentDidUpdate(){} 7. componentWillUnmount(){} 03. Why do we use componentDidMount? After initial rendering/mounting a component to the UI(i.e, DOM) we atleast showed something on the UI to the user, now background API calls, timers, subscriptions or any asynchronous operations to happen, we put them inside it. After successful completion of the function, we can set the state it re-render the component, updates will be reflected  in the UI. 04. Why do we use componentWillUnmount? Show with example We use this function to clearup any function that needs to be end, before unmounting a component. Also, this prevents memory leak, affects app performance. 05. Why do we use super(props) in constructor? super(props) is not Mandatory in modern react code. Whenever we use constructor for writing customize initial values in the component/class. We must use super() to initializes parent component (React.component) constructor function. This setup initial values and state in the constructor function. 06. Why can't we have the callback function of useEffect async? useEffect hook callback function designed to return nothing (undefined) or cleanup function. However async function can be written inside the hook, that is declared and called inside it. Please have a look at my github repo at the 'branch 08' I've shared all my assignments. #frontend #reactdeveloper #reactjs #javascript #jsx

Your frontend is not slow. It’s just doing too much. Let me explain 🧵 Modern frontends quietly became: • State managers • API orchestrators • Cache layers • Validation engines • Offline systems ...and also “the UI” Somewhere along the way, we decided: “Let’s move logic closer to the user” And accidentally moved everything. Now your browser is handling: • business rules • pagination logic • filtering • optimistic updates • retry logic While the server just sits there. This creates a hidden problem: 👉 Two copies of reality. One on the server. One in the browser. And now your app spends more time: syncing state than actually serving users. That’s why you see: • loading spinners everywhere • inconsistent UI states • “works after refresh” bugs • endless edge cases The fix is not: “better state management” The fix is: 👉 less state in the frontend. A better mental model: • URL → shareable state • Session → short-term memory • Database → source of truth • Frontend → just rendering When you do this: • less duplication • simpler code • fewer bugs • faster features The frontend becomes calm again. The browser was never meant to be your backend. We just kept promoting it. Be honest. What’s the most ridiculous thing your frontend is currently responsible for? Read more on why you don’t always need a state management library https://lnkd.in/d_9iksGS

Who really owns your form data? In a standard HTML input, the DOM is the boss. It holds the value in its own internal memory, and you only "ask" for it when the user hits submit. But in React, we don't like hidden state. We want every piece of data to be explicit and predictable. This is where Controlled Components come in. In this pattern, the React state is the single source of truth. The input doesn't maintain its own value. Instead, you tell the input exactly what to display using the 'value' prop, and you update that value through an 'onChange' handler that modifies the state. The input is "controlled" because its behavior is entirely driven by the React component. Why go through this extra boilerplate? It gives you total coordination over the UI. Since the data lives in your state, you can perform instant field validation, disable the submit button based on specific criteria, or even format the user's input in real-time. There is no "syncing" issue between the DOM and your logic because they are never out of alignment. Of course, controlling every single character stroke in a massive form can feel like overkill. For simple, high-performance scenarios where you just need the data at the end, Uncontrolled Components using 'refs' might be faster. But for most applications, the predictability of a controlled flow far outweighs the cost of a few extra lines of code. It ensures that what the user sees is exactly what your application "knows". #ReactJS #SoftwareEngineering #WebDevelopment #FrontendArchitecture #CodingTips #Javascript

𝗪𝗵𝘆 𝗬𝗼𝘂𝗿 𝗗𝗲𝗯𝗼𝘂𝗻𝗰𝗲 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻 𝗙𝗮𝗶𝗹𝘀 You add debounce to your search input. You expect one request. You see many in the network tab. This happens in search bars and product filters. Your code looks correct. The bug still happens. Most developers misdiagnose this. Debounce delays the start of a function. It does not stop requests already running. This creates race conditions. User types jav. Request one starts. User types javascript. Request two starts. Request one finishes last. You see old data. You need two tools. - Debounce to reduce calls. - AbortController to cancel old requests. Use AbortController inside your fetch. Call controller.abort before starting a new request. Only the last result wins. React developers face a different bug. New renders create new debounce functions. The timer resets. Use useMemo to keep the function stable. Pass values directly to your search function. Do not use delayed references. This keeps data fresh. Ask yourself one question. Are you delaying execution or controlling stale requests? The answer reveals the bug. Source: https://lnkd.in/gp-XS-eK

Day 11/30 — React Journey Forms in React are painful… until you understand THIS shift 😎 Most developers treat forms like traditional HTML. That breaks everything. In React, forms are not static inputs… They are state-driven systems. 👉 Make React the single source of truth Every input = tied to state Every change = controlled by logic Every value = predictable 🧠 Why This Changes Everything React follows unidirectional data flow: State → UI → User Action → State No hidden DOM behavior. No unexpected bugs. No chaos. 🚀 What Most Developers Miss 👉 Stop thinking “input fields” 👉 Start thinking data model Form = structured object Inputs = just views of that data Updates = controlled transformations This is how real scalable apps work. ⚡ When your form grows: Don’t manage fields individually Think in systems, not elements 👉 One logic layer 👉 One data flow 👉 Infinite scalability Top devs don’t reinvent forms. They use: React Hook Form → performance-focused, minimal re-renders Formik → structured, enterprise-grade 🧲 The Real Mindset Shift ❌ Forms = UI elements ✅ Forms = state machines Once you see this… Forms become predictable, scalable, and easy. 🔥 Master this ONE shift… and forms go from frustrating → effortless. Most developers never realize this.