React 19 Simplifies DOM Logic with Ref Callback Cleanup

React 19 lets you delete useEffect for DOM logic. 👇 👇 For years, integrating third-party DOM libraries (like GSAP, ResizeObserver, or vanilla JS animations) required a specific dance: 1. Create a useRef. 2. Create a useEffect. 3. Check if (ref.current). 4. Return a cleanup function. It separated the "Element" from the "Logic" that controlled it. React 19 introduces Ref Callback Cleanup. ❌ The Old Way: You had to synchronize a mutable ref with an effect. It was verbose and prone to "stale closure" bugs if you forgot dependencies. ✅ The Modern Way: Pass a function to the ref prop. React runs this function when the node mounts. If you return a function, React will automatically run it when the node unmounts. Why this is cleaner: 📉 Less Code: Logic is co-located with the element it affects. 🧠 No Hooks: You don't need useRef or useEffect for simple DOM integrations. ⚡ Safe: Handles node mounting/unmounting lifecycles perfectly. Note: This is perfect for things like ResizeObserver, IntersectionObserver, or auto-focus logic. #ReactJS #React19 #WebDevelopment #Frontend #JavaScript #CleanCode #SoftwareEngineering #TechTips #ReactHooks #Hooks #ReactTips #FrontrendDeveloper #DevloperTips

⚛️ React 19 lets you delete useEffect for DOM logic. 👇 👇 For years, integrating third-party DOM libraries (like GSAP, ResizeObserver, or vanilla JS animations) required a specific dance: 1. Create a useRef. 2. Create a useEffect. 3. Check if (ref.current). 4. Return a cleanup function. It separated the "Element" from the "Logic" that controlled it. React 19 introduces Ref Callback Cleanup. ❌ The Old Way: You had to synchronize a mutable ref with an effect. It was verbose and prone to "stale closure" bugs if you forgot dependencies. ✅ The Modern Way: Pass a function to the ref prop. React runs this function when the node mounts. If you return a function, React will automatically run it when the node unmounts. Why this is cleaner: 📉 Less Code: Logic is co-located with the element it affects. 🧠 No Hooks: You don't need useRef or useEffect for simple DOM integrations. ⚡ Safe: Handles node mounting/unmounting lifecycles perfectly. Note: This is perfect for things like ResizeObserver, IntersectionObserver, or auto-focus logic. hashtag #ReactJS hashtag #React19 hashtag #WebDevelopment hashtag #Frontend hashtag #JavaScript hashtag #CleanCode hashtag #SoftwareEngineering hashtag #TechTips hashtag #ReactHooks hashtag #Hooks hashtag #ReactTips hashtag #FrontrendDeveloper hashtag #DevloperTips

I recently revisited the React countdown timer. It reminded me of a mistake many of us have made at least once. Two common problems with timers in React - Memory leaks - Stale state caused by JavaScript closures The closure problem: When we create setInterval, the callback captures variables at creation time. So setInterval(() => {     setRemainingMs(remainingMs - 1000) }, 1000) This looks okay, but it is incorrect. Because remainingMs inside a closuer is frozen. The interval keeps the old value even after React re-renders. So this leads to - Frozen timers - Skipped seconds - Incorrect UI state The correct fix: use functional state update:     setRemainingMs(prev => Max.max(prev-1000, 0)) Preventing Memory Leaks: If we create something in useEffect (intervals, listeners, subscriptions), we must clean it up: return () => clearInterval(interval) Otherwise, the timer keeps running even after the component unmounts. How I remember: - If state depends on previous state -> use functional updates - If I create side effects -> I must clean them up So, React did not break my timer; JavaScript closures did, React just made them visible. If this saved you from a future bug, it was worth sharing #React #JavaScript #Frontend #WebDevelopment #CleanCode #development #devnote

🧠 Is setState 𝘀𝘆𝗻𝗰𝗵𝗿𝗼𝗻𝗼𝘂𝘀 or 𝗮𝘀𝘆𝗻𝗰𝗵𝗿𝗼𝗻𝗼𝘂𝘀 in React? Short answer 👉 setState is 𝗮𝘀𝘆𝗻𝗰𝗵𝗿𝗼𝗻𝗼𝘂𝘀 — by design. React doesn’t update state immediately. Instead, it schedules state updates and batches multiple updates together to avoid unnecessary re-renders and improve performance. 𝘌𝘹𝘢𝘮𝘱𝘭𝘦:– setCount(count + 1); console.log(count); 𝘖𝘶𝘵𝘱𝘶𝘵:- 0 𝗪𝗵𝘆? Because setState does not update the value instantly — the current render still holds the old state. 🔁 𝗕𝗮𝘁𝗰𝗵𝗶𝗻𝗴 𝗶𝗻 𝗮𝗰𝘁𝗶𝗼𝗻 setCount(count + 1); setCount(count + 1); 𝗥𝗲𝘀𝘂𝗹𝘁 👉 1 (not 2) Both updates read the same stale state, and React batches them into a single render. ✅ The correct pattern (when state depends on previous state) setCount(prev => prev + 1); setCount(prev => prev + 1); 𝗥𝗲𝘀𝘂𝗹𝘁: 2 This works because React provides the latest queued state to each update. 🧠 𝗞𝗲𝘆 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆 setState doesn’t change state immediately. It requests a state change — React decides when to apply it. This behavior enables better performance, smoother UI, and concurrent rendering. 👀 𝗕𝘂𝘁 𝗵𝗲𝗿𝗲’𝘀 𝘁𝗵𝗲 𝘁𝘄𝗶𝘀𝘁... 👉 setState can be synchronous in React — but only in very specific situations and for a specific purpose. I’ll cover when, why, and whether you should ever use it in my next post. Stay tuned 🚀 #ReactJS #JavaScript #Frontend #WebDevelopment #ReactHooks #Performance #SoftwareEngineering

𝗥𝗲𝗮𝗰𝘁 𝗸𝗲𝘆𝘀: 𝗶𝗻𝗱𝗲𝘅 𝘄𝗼𝗿𝗸𝘀… 𝘂𝗻𝘁𝗶𝗹 𝗶𝘁 𝗱𝗼𝗲𝘀𝗻’𝘁. A lot of weird UI bugs in production come from this: ❌ Problem: ``` items.map((item, index) => <Row key={index} />) ``` React doesn’t track list items by “data”. It tracks component identity using keys and reuses DOM/state based on that reference. So when you: • sort • filter • insert • delete the index changes, and React reuses the wrong DOM/state. Result: • inputs swap values • checkbox state mismatches • selected item jumps • animations glitch ✅ Fix: ``` items.map((item) => <Row key={item.id} />) ``` Rule: If the order can change → keys must be stable. Have you ever debugged this bug and later found it was the key? 👀 #ReactJS #Frontend #JavaScript #WebDev #Nextjs

React State Is a Snapshot — Not a Variable (A Concept Every React Dev Should Know) One of the most misunderstood concepts in React is that state is a snapshot in time, not a mutable variable. When React renders a component, it gives you a snapshot of: props state event handlers That snapshot is fixed for that render. setCount(count + 1); setCount(count + 1); setCount(count + 1); You might expect count to increase by 3 — but it doesn’t. Why? Because all three updates read the same snapshot of count. The Correct Mental Model State updates are queued React re-renders later with a new snapshot Code inside the same render never sees updated state The Fix: Functional Updates setCount(prev => prev + 1); setCount(prev => prev + 1); setCount(prev => prev + 1); Now React applies each update to the latest value, not the old snapshot. Why This Matters Understanding state as a snapshot helps you: Avoid stale state bugs Write predictable event handlers Fix issues with async logic, debouncing, and batching Reason better about concurrent rendering in React 18+ Key Takeaway State doesn’t change inside a render. React gives you a snapshot — and the next render gives you a new one. Once this clicks, many “weird” React bugs suddenly make sense. #ReactJS #Frontend #JavaScript #WebDevelopment #ReactHooks #React18

🚀 Day 8 Not Just Motivation — Real Concepts to Build Strong Technical Understanding (Part 8) Why does JavaScript remember variables even after a function finishes? The answer is Closure. Let’s understand this using a real-world example from React: useState. A simplified mental model of useState (conceptual) function useState(initialValue) { let state = initialValue; function setState(newValue) { state = newValue; render(); // re-render component } return [state, setState]; } Here, setState is a closure. It remembers state even after useState finishes execution. Example: Counter Component function Counter() { const [count, setCount] = React.useState(0); return ( <button onClick={() => setCount(count + 1)}> Count: {count} </button> ); } Every render is a new function call. So how does React remember count? Let’s go step by step. Render 1 – Initial Mount 1. React calls the component: Counter(). 2. useState(0) runs and creates a state slot outside the function (heap/fiber). 3. count is set to 0 and setCount is returned as a closure. 4. JSX is rendered and UI shows Count: 0. User Clicks the Button 1. Browser triggers a click event. 2. React handles the event via its synthetic event system. 3. setCount(count + 1) is called. 4. React updates internal state and schedules a re-render. Render 2 – After State Update 1. Counter() runs again. 2. Local variables are recreated, but state is preserved. 3. useState does not reinitialize; it reads existing state from memory. 4. count is now 1 and UI updates accordingly. Final Takeaway The component function re-runs on every render, but state survives because React stores it outside the function. setState works because it is a closure pointing to that preserved state. Closures are the reason useState works. #javascript #closure #reactjs #reacthooks #frontend #webdevelopment

🚀 React Re-renders Why does a component re-render even when props look the same? React re-renders when reference changes, not value. If you pass new objects/functions every render, React treats them as new. Example: Passing `{ user }` where `user` is recreated each render will trigger child updates. In dashboards with 100+ rows, this causes lag. Fix: Memoize values and avoid inline object creation. #ReactJS #FrontendEngineering #JavaScript

⚛️ React Rendering — finally made sense for me today For a long time, I thought React updates the UI in one go. Turns out… that’s not how it actually works 🙂 React does its job in two clear steps: 👉 First, it thinks (Render Phase) 👉 Then, it acts (Commit Phase) In the render phase, React only decides what should change. No DOM updates. No side effects. Just calculations. In the commit phase, React updates the DOM and runs effects. This is where things actually appear on the screen. Understanding this small difference helped me: - avoid unnecessary API calls - fix repeated renders - write cleaner useEffect logic If React rendering ever felt confusing, this breakdown might help you too. 📌 Saved this as a carousel for quick revision 💬 Curious to know — when did React “click” for you? #ReactJS #FrontendDevelopment #WebDevelopment #JavaScript #LearningInPublic #IndianDevelopers

🧠 How Browsers Actually Work (What Every Frontend Dev Should Know) When you hit Enter after typing a URL, the browser doesn’t “open a page”… it builds one from scratch. 🔹 Step 1: Finding the Server (DNS) Browser converts the domain into an IP address so it knows where to talk. 🔹 Step 2: Fetching Resources An HTTP request is sent → server responds with HTML, CSS, JS, fonts, images. 🔹 Step 3: Building the Page HTML → DOM CSS → CSSOM DOM + CSSOM → Render Tree Then comes Layout (sizes & positions) and Paint (pixels on screen). 🔹 Step 4: JavaScript Takes Control JS runs in the browser engine, can block rendering, manipulate the DOM, attach events, and call APIs. 🔹 Step 5: The Event Loop Handles async tasks (callbacks, promises, timers) so heavy JS doesn’t freeze the UI. 💡 Why this matters If you understand this flow, you automatically write: Faster UIs Fewer re-renders Better loading strategies Cleaner React / Next.js apps 👉 Browsers are rendering engines + JS runtimes + networking layers, not just viewers. If frontend is your craft—browser internals are your foundation 🚀 #FrontendEngineering #JavaScript #WebPerformance #ReactJS #NextJS