Usman Ahmed’s Post

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

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

There’s something interesting about working with Next.js in real-world projects — the benefits don’t always show up in documentation, but they become obvious once things go into production. One noticeable shift is how performance starts improving without constant manual optimization. Features like Server Components quietly reduce client-side load, which reflects directly in smoother user interactions. Routing and layouts also feel more structured. Instead of managing scattered logic, the project naturally moves toward a cleaner architecture, especially as it scales. Another practical observation is with Incremental Static Regeneration (ISR). It helps keep content fresh without sacrificing speed — something that used to require custom solutions before. On the development side, iteration feels faster. Changes reflect quickly, debugging becomes simpler, and overall friction reduces during builds. But the real difference shows up in consistency — fewer performance issues, better load times, and a more stable user experience over time. Next.js doesn’t feel like just another framework in the stack anymore. It starts influencing how applications are designed from the ground up. Curious — what changes have you noticed after using Next.js in actual projects? #NextJS #FrontendDevelopment #WebPerformance #JavaScript #TechInsights

Have you ever needed to touch the DOM directly while working in React? React is designed to be declarative. You describe the UI based on state, and the library handles the updates. But occasionally, you need what we call an 'escape hatch.' This is precisely where 'refs' come into play. They provide a way to access a DOM node or a React element directly, bypassing the standard re-render cycle. The most common reason to reach for a ref is to manage things like focus, text selection, or media playback. If you need a specific input field to focus the moment a page loads, you cannot easily do that with state alone. You need to reach into the DOM and call the native '.focus()' method. Beyond the DOM, refs are also perfect for storing any mutable value that needs to persist across renders without triggering a UI update. This includes things like timer IDs or tracking previous state values for comparison. However, with great power comes responsibility. Using refs is essentially stepping outside of the React ecosystem and taking manual control. If you can achieve your goal using props and state, you should. Overusing refs can make your components harder to debug and breaks the predictable flow of data that makes React so reliable. It is a tool for the edge cases, not the daily routine. Use it when you need to talk to the browser directly, but keep your core logic declarative. #ReactJS #SoftwareEngineering #WebDevelopment #Javascript #Frontend #CodingTips

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

🚀 React.memo — Prevent Unnecessary Re-renders Like a Pro In React, re-renders are normal… 👉 But unnecessary re-renders = performance issues That’s where React.memo helps. 💡 What is React.memo? React.memo is a higher-order component (HOC) 👉 It memoizes a component 👉 Prevents re-render if props haven’t changed ⚙️ Basic Example const Child = React.memo(({ name }) => { console.log("Child rendered"); return <h1>{name}</h1>; }); 👉 Now it only re-renders when name changes 🧠 How it works 👉 React compares previous props vs new props If same: ✅ Skips re-render If changed: 🔁 Re-renders component 🔥 The Real Problem Without memo: <Child name="Priyank" /> 👉 Even if parent re-renders 👉 Child also re-renders ❌ With React.memo: ✅ Child re-renders only when needed 🧩 Real-world use cases ✔ Large component trees ✔ Expensive UI rendering ✔ Lists with many items ✔ Components receiving stable props 🔥 Best Practices (Most developers miss this!) ✅ Use with stable props ✅ Combine with useCallback / useMemo ✅ Use in performance-critical components ❌ Don’t wrap every component blindly ⚠️ Common Mistake // ❌ Passing new function each render <Child onClick={() => console.log("Click")} /> 👉 Breaks memoization → causes re-render 💬 Pro Insight (Senior-Level Thinking) 👉 React.memo is not magic 👉 It works only if: Props are stable Reference doesn’t change 📌 Save this post & follow for more deep frontend insights! 📅 Day 21/100 #ReactJS #FrontendDevelopment #JavaScript #PerformanceOptimization #ReactHooks #SoftwareEngineering #100DaysOfCode 🚀

⚡ 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

React Fiber: what it actually means for your code Most React devs know what Fiber is by name. Fewer know why it matters day to day. The old reconciler worked synchronously. State changes, React walks the whole tree, diffs it, writes to the DOM. One pass, no stopping. On a large component tree that blocked the main thread long enough for users to notice — animations stuttered, inputs lagged. Fiber fixed this by replacing the recursive call stack with a linked list. Each fiber is a plain object: component type, props, state, and pointers to parent, first child, next sibling. React now owns the execution, so it can pause whenever something more urgent comes in. Work splits into two phases, and this is the part worth understanding. The render phase builds a work-in-progress tree in memory without touching the DOM. React can stop mid-tree, hand control back to the browser for a keypress or a frame, then continue. If a higher-priority update arrives, it discards the in-progress work and starts over. The commit phase doesn't pause. Once the tree is ready, React applies all DOM mutations in one go. This part has to be synchronous — a half-applied DOM update breaks the UI. Here's where it connects to your actual code. useTransition works because React can genuinely deprioritize a state update and interrupt it if needed. Without Fiber, marking something as "non-urgent" would be meaningless — the old reconciler couldn't stop anyway. Suspense pauses a subtree while data loads for the same reason. React keeps the current tree on screen, builds the new one in the background, swaps when ready. Slow renders that only appear under load, inputs that lag when a big list re-renders, Suspense boundaries not behaving as expected — all of these trace back to how Fiber schedules and interrupts work. When something's off and the profiler gives you a confusing flamegraph, knowing that React works in two phases (one interruptible, one not) usually tells you where to look. #react #frontend #javascript #webdev #reactjs #frontenddevelopment #softwaredevelopment

🚀 React Render vs Commit Phase — How React Actually Updates UI Most developers know: 👉 React re-renders components But what really happens behind the scenes? 👉 React works in two phases 💡 1. Render Phase (Calculation Phase) 👉 React prepares what needs to change ✔ Creates new Virtual DOM ✔ Compares with previous tree (Reconciliation) ✔ Decides what to update ❗ No DOM updates happen here 💡 2. Commit Phase (Execution Phase) 👉 React applies the changes to the real DOM ✔ Updates DOM ✔ Runs useEffect ✔ Updates refs 👉 This is where UI actually changes ⚙️ Flow (Step-by-step) 1️⃣ State/props change 2️⃣ Render Phase runs (diffing) 3️⃣ React calculates changes 4️⃣ Commit Phase updates DOM 🧠 Why this matters 👉 React separates thinking from doing: Render Phase → “What to update?” Commit Phase → “Apply updates” 🔥 Important Behavior ✔ Render phase can run multiple times ✔ Commit phase runs once per update 👉 This enables features like: Concurrent rendering Interruptible updates ⚠️ Common Mistake // ❌ Side effects in render const data = fetchData(); 👉 Causes bugs → should be inside useEffect 🔥 Best Practices ✅ Keep render phase pure ✅ Avoid side effects in render ✅ Use useEffect for side effects ❌ Don’t trigger DOM changes in render 💬 Pro Insight (Senior-Level Thinking) 👉 Render phase can be paused, restarted, or discarded 👉 Commit phase is always final 📌 Save this post & follow for more deep frontend insights! 📅 Day 23/100 #ReactJS #FrontendDevelopment #JavaScript #ReactInternals #PerformanceOptimization #SoftwareEngineering #100DaysOfCode 🚀