Fixing Stale Closures in React with useRef

I recently completed a project focused on building and enhancing a Simple Todos app. This project was a great way to dive deeper into React state management, conditional rendering, and dynamic UI updates. Key features I implemented: ✅ Dynamic Task Creation: Added a text input and "Add" button to create tasks on the fly. ✅ Bulk Task Entry: Built a smart "Multi-Add" feature automatically generates three separate entries. ✅ In-Place Editing: Implemented an "Edit/Save" toggle for each item, allowing users to update titles without leaving the list. ✅ Task Completion: Added checkboxes with a persistent strike-through effect to track progress. ✅ Stateful Deletion: Ensured a smooth user experience when removing items from the list. This project pushed me to think about component structure, reusable props, and clean UI logic in React. Check out the implementation here: https://lnkd.in/dtG46cwU #Day97 #ReactJS #WebDevelopment #Frontend #JavaScript #CodingProject #LearnToCode #ReactComponents #NodeJS #ExpressJS #BackendDevelopment #WebDevelopment #NxtWave #LearningJourney #TechAchievement

🚀 Why useState is a Game-Changer in React. let's breakdown this 👇 💡 What is useState? "useState" is a React Hook that allows you to store and manage dynamic data (state) inside functional components. Without it, your UI wouldn’t respond to user input. 📱 Real-Time Example: Form Input & Validation Let’s take a simple login form 👇 import React, { useState } from "react"; function LoginForm() { const [email, setEmail] = useState(""); const [error, setError] = useState(""); const handleSubmit = (e) => { e.preventDefault(); if (!email.includes("@")) { setError("Please enter a valid email address"); } else { setError(""); alert("Form submitted successfully!"); } }; return ( <form onSubmit={handleSubmit}> <input type="text" placeholder="Enter email" value={email} onChange={(e) => setEmail(e.target.value)} /> {error && <p style={{ color: "red" }}>{error}</p>} <button type="submit">Submit</button> </form> ); } export default LoginForm 🧠 What’s happening here? - "email" → stores user input - "setEmail" → updates input as the user types - "error" → stores validation message - "setError" → shows/hides error instantly useState is what connects user actions to UI behavior. It ensures your forms are not just functional, but smart and responsible 💬 Have you implemented form validation using useState? What challenges did you face? #ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #Coding

🔍 Controlled vs Uncontrolled Components in React If you're working with React forms, understanding this difference can level up your frontend skills 👇 👉 Controlled Components These are components where form data is handled by React state. Single source of truth (React state) Easier validation & debugging More predictable behavior Example: const [name, setName] = useState(""); <input value={name} onChange={(e) => setName(e.target.value)} /> 👉 Uncontrolled Components Here, form data is handled by the DOM itself using refs. Less code Quick & simple for basic use cases Harder to validate and control Example: const inputRef = useRef(); <input ref={inputRef} /> 💡 When to use what? Use controlled components for complex forms, validations, and dynamic UI Use uncontrolled components for simple forms or quick prototypes ⚡ Pro Tip: In real-world apps, controlled components are preferred because they give you full control over user input. #ReactJS #FrontendDevelopment #WebDevelopment #JavaScript #CodingTips #SoftwareEngineering

Some of the hardest React bugs I’ve seen weren’t actually inside React. They were happening somewhere in between. Between the event loop and the render cycle. You know the kind of bug. Everything looks correct. State updates are there. Handlers are wired properly. The logic makes sense. And yet… the UI shows stale data. Something flickers for a split second. It works fine locally, but breaks under real user interaction. Those are the bugs that make you question your sanity a bit. What’s really going on is this. We tend to think of React and JavaScript as one system. But they’re not. JavaScript runs your code - sync, promises, timeouts, all of that. React runs its own process - scheduling renders, batching updates, deciding when the UI actually updates. Most of the time, we blur that into one mental model. And most of the time it works. Until it doesn’t. That gap is where things get weird. You’ve probably seen versions of this: 🔹 You call setState and immediately get the old value 🔹 A setTimeout fires and uses stale data 🔹 A promise resolves and overwrites something newer 🔹 Everything works… until a user clicks fast enough Individually, none of this is surprising. But when it happens in a real app, it feels unpredictable. Because the problem isn’t what your code does. It’s when it runs. That’s why these bugs are so frustrating. You’re not debugging logic anymore. You’re debugging timing. The more I work on complex React apps, the more I notice this - a big part of senior frontend work isn’t just knowing hooks or patterns. It’s understanding how React’s rendering model interacts with the JavaScript runtime. Because once timing gets involved what looks correct can still be completely wrong. #reactjs #javascript #frontend #webdevelopment #softwareengineering #debugging #performance #typescript

🧵 Ever wondered why React feels so smooth, even when your app is doing a lot? The answer is React Fiber and it's one of the most underrated architectural decisions in modern frontend development. Here's what you need to know 👇 🔴 The problem before Fiber The old React reconciler (the "stack reconciler") worked like a phone call you couldn't interrupt. Once React started rendering, it kept going until it was done — blocking the main thread, freezing UI interactions, and causing janky experiences on complex UIs. ✅ Enter React Fiber (React 16+) Fiber is a complete rewrite of React's core reconciliation engine. The key idea? Break rendering work into small units called "fibers" and pause, resume, or even throw them away based on priority. Think of it like a task manager for your UI updates. ⚡ What Fiber actually enables: → Incremental rendering : work is split into chunks → Priority scheduling : urgent updates (like typing) jump the queue → Concurrency : React can work on multiple tasks without blocking the browser → Suspense & transitions : smooth loading states without hacks → Error boundaries : graceful crash handling per component 🔍 How it works under the hood Each component in your tree maps to a fiber node, a plain JS object that holds: • Component type & state • Reference to parent, child & sibling fibers • Work-in-progress flags React builds a "work-in-progress" tree in the background, then commits changes to the DOM all at once which makes updates feel instant. #ReactJS #WebDevelopment #JavaScript #Frontend #SoftwareEngineering #ReactFiber #Programming

🚀 useReducer in React — When useState is Not Enough As your React app grows… 👉 State becomes complex 👉 Multiple updates depend on each other 👉 Logic gets messy That’s where useReducer comes in. 💡 What is useReducer? useReducer is a hook for managing complex state logic using a reducer function. 👉 Inspired by Redux ⚙️ Basic Syntax const [state, dispatch] = useReducer(reducer, initialState); 🧠 How it works 👉 Instead of updating state directly: setCount(count + 1); 👉 You dispatch actions: dispatch({ type: "increment" }); 👉 Reducer decides how state changes: function reducer(state, action) { switch (action.type) { case "increment": return { count: state.count + 1 }; default: return state; } } 🧩 Real-world use cases ✔ Complex forms ✔ Multiple related states ✔ State transitions (loading → success → error) ✔ Large components with heavy logic 🔥 Why useReducer? 👉 useState works well for simple state 👉 useReducer works better for structured logic 🔥 Best Practices (Most developers miss this!) ✅ Use when state depends on previous state ✅ Use for complex or grouped state ✅ Keep reducer pure (no side effects) ❌ Don’t use for simple state ❌ Don’t mix business logic inside components ⚠️ Common Mistake // ❌ Side effects inside reducer function reducer(state, action) { fetchData(); // ❌ Wrong return state; } 👉 Reducers must be pure functions 💬 Pro Insight (Senior-Level Thinking) 👉 useState = simple updates 👉 useReducer = predictable state transitions 👉 If your state has “rules” → useReducer 📌 Save this post & follow for more deep frontend insights! 📅 Day 20/100 #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #StateManagement #SoftwareEngineering #100DaysOfCode 🚀

🚀 React Re-rendering — Key Concepts Re-rendering is the core of how React keeps UI in sync with data. Without it, there would be no interactivity in our applications. Here are some important insights I've learned: 🔹 State updates are the primary trigger for re-renders 🔹 When a component re-renders, all its child components re-render by default 🔹 Even without props, components still re-render during the normal render cycle (without use of memoization). 🔹 Updating state in a hook triggers a re-render, even if that state isn’t directly used 🔹 In chained hooks, any state update will re-render the component using the top-level hook 🔹 “Moving state down” is a powerful pattern to reduce unnecessary re-renders in large applications #ReactJS #FrontendDevelopment #WebDevelopment #JavaScript #SoftwareEngineering #LearningInPublic

Most developers use `useMemo()` because they heard it improves performance. But here’s the truth: `useMemo` is not for making your app “faster” magically. It is for avoiding unnecessary work. Imagine your component renders again and again because some state changes. Every render means: * functions run again * calculations run again * arrays/objects get recreated again And sometimes that becomes expensive. Example: You have a list of 10,000 products and you are filtering or sorting them on every render. Without `useMemo`, even if only a button color changes, the filtering logic runs again. const filteredProducts = products.filter(product => product.price > 1000 ) Now imagine this runs on every render. That is unnecessary work. With `useMemo`: const filteredProducts = useMemo(() => { return products.filter(product => product.price > 1000) }, [products]) Now React stores the previous result and only recalculates when `products` changes. That stored value is called memoization. Memoization = remembering the previous result so you don’t have to calculate it again. Why use `useMemo`? ✅ Prevent expensive calculations from running again ✅ Avoid unnecessary re-renders in child components ✅ Improve performance when dealing with large lists, sorting, filtering, heavy computations What problem does it solve? Without `useMemo`: * Slow UI * Lag while typing/searching * Heavy calculations on every render * Child components re-render because new object/array references are created. So if you pass it to a child component, React thinks it changed every time. const user = useMemo(() => ({ name: "Durgesh" }), []) Now the reference stays the same. But there’s a catch 👇 Do NOT use `useMemo` everywhere. `useMemo` itself has a cost. For simple calculations, just write normal code. Rule of thumb: 👉 Use `useMemo` only when: * the calculation is expensive * the value is passed to memoized child components * re-rendering is causing performance issues Don’t optimize first. Measure first. Then optimize. That’s what good React developers do. #react #javascript #webdevelopment #frontend #reactjs #useMemo #performance #coding

Most developers use `useMemo()` because they heard it improves performance. But here’s the truth: `useMemo` is not for making your app “faster” magically. It is for avoiding unnecessary work. Imagine your component renders again and again because some state changes. Every render means: * functions run again * calculations run again * arrays/objects get recreated again And sometimes that becomes expensive. Example: You have a list of 10,000 products and you are filtering or sorting them on every render. Without `useMemo`, even if only a button color changes, the filtering logic runs again. const filteredProducts = products.filter(product => product.price > 1000 ) Now imagine this runs on every render. That is unnecessary work. With `useMemo`: const filteredProducts = useMemo(() => { return products.filter(product => product.price > 1000) }, [products]) Now React stores the previous result and only recalculates when `products` changes. That stored value is called memoization. Memoization = remembering the previous result so you don’t have to calculate it again. Why use `useMemo`? ✅ Prevent expensive calculations from running again ✅ Avoid unnecessary re-renders in child components ✅ Improve performance when dealing with large lists, sorting, filtering, heavy computations What problem does it solve? Without `useMemo`: * Slow UI * Lag while typing/searching * Heavy calculations on every render * Child components re-render because new object/array references are created. So if you pass it to a child component, React thinks it changed every time. const user = useMemo(() => ({ name: "Durgesh" }), []) Now the reference stays the same. But there’s a catch 👇 Do NOT use `useMemo` everywhere. `useMemo` itself has a cost. For simple calculations, just write normal code. Rule of thumb: 👉 Use `useMemo` only when: * the calculation is expensive * the value is passed to memoized child components * re-rendering is causing performance issues Don’t optimize first. Measure first. Then optimize. That’s what good React developers do. #react #javascript #webdevelopment #frontend #reactjs #useMemo #performance #coding

most React developers don't know why their components re-render more than they should. they blame React. they blame performance. they don't blame their own code. the real problem: objects and arrays created inside render. every single render creates a new reference. children receive new props. they re-render unnecessarily. why it matters: React compares props. if props change, child re-renders. but if you're creating the same object every render, React thinks it changed. performance tanks. the hidden cost: one parent component creating new object = entire subtree re-renders. multiply that across your app and it adds up fast. the solution: create objects outside render. if you must create inside, use useMemo. stable references prevent unnecessary re-renders. the pattern: stable reference = child doesn't re-render. new reference = child re-renders even if data is identical. #reactjs #typescript #webdevelopment #buildinpublic #javascript