JavaScript Closures and Memory Leaks

I recently ran into a debugging issue that many frontend engineers may relate to. My pagination worked perfectly in development, but once we deployed to pilot, the **Next button stopped fetching new data**. The URL updated. The page number changed. But the API never fired again. After digging deeper, I discovered the real issue wasn’t pagination at all — it was **React Query caching caused by a static query key**. Because the query key didn’t include the dynamic parameters (pageNumber), React Query kept returning cached data instead of refetching. I wrote a short article explaining: • what caused the issue • why it only appeared outside development • and the small change that fixed it If you're working with React Query, pagination, or server-state caching, this lesson might save you hours of debugging. Read the story here: https://lnkd.in/ej6t5Tnf Curious if others have encountered similar caching issues when moving from dev to staging or production. #React #ReactQuery #JavaScript #WebDevelopment #SoftwareEngineering

🚀 The Event Loop: Browser vs. Node.js 🌐 Ever wondered how JavaScript stays "fast" despite being single-threaded? The secret sauce is the Event Loop. But depending on where your code runs, the Event Loop wears different hats. 🎩 Here is a quick breakdown of how it works on the Client-side vs. the Server-side: 🖥️ 1. JavaScript in the Browser (Client-Side) In the browser, the Event Loop is all about User Experience. The Goal: Keep the UI responsive. How it works: When a user clicks, scrolls, or fetches data, these actions are added to a task queue. The Flow: The Event Loop constantly checks if the Call Stack is empty. If it is, it pushes the next task from the queue to the stack. This ensures that heavy tasks don't "freeze" the screen while rendering. ⚙️ 2. Node.js (Server-Side) In Node.js, the Event Loop is the backbone of High-Concurrency servers. The Goal: Handle thousands of simultaneous requests without blocking. The Heavy Lifters: For "blocking" tasks like File System (FS) or Database operations, the Event Loop offloads the work to Worker Threads (via the Libuv library). The Callback Cycle: 1. The Event Loop registers a callback for an operation. 2. It hands the task to a worker thread. 3. Once the worker is done, it sends the result back to the queue. 4. The Event Loop picks it up and executes the final callback to send the response. 💡 The Bottom Line Whether you are building a snappy UI or a scalable backend, understanding the Event Loop is the difference between a laggy app and a high-performance system. #JavaScript #NodeJS #WebDevelopment #Programming #SoftwareEngineering #TechTips #react #express #next

That Slow Down Your React Applications Even with experience, it's easy to fall into these traps that impact performance and maintainability: 1. Direct State Mutations: Modifying state or props directly instead of using update functions. This breaks the one-way data flow. 2. Use Effect Abuse: Using it for derived calculations or state synchronizations that could be handled at render time. 3. Forgetting Dependencies: Empty or incomplete dependency arrays in useEffect and useCallback lead to subtle bugs and stale data. 4 Rendering Lists Without a Unique Key: Using the index as the key forces React to unnecessarily recreate components when order changes. 5 Use State Overuse: Storing derived values in state instead of calculating them directly at render. The key? Understand the component lifecycle and let React do its reconciliation work efficiently. What's the trap that cost you the most debugging time? #ReactJS #WebDevelopment #CleanCode #Frontend #JavaScript #BestPractices

𝐆𝐨𝐭 𝐛𝐢𝐭𝐭𝐞𝐧 𝐛𝐲 𝐚 𝐮𝐬𝐞𝐒𝐭𝐚𝐭𝐞 𝐛𝐮𝐠 𝐭𝐡𝐢𝐬 𝐰𝐞𝐞𝐤 𝐭𝐡𝐚𝐭 𝐡𝐚𝐝 𝐦𝐞 𝐬𝐜𝐫𝐚𝐭𝐜𝐡𝐢𝐧𝐠 𝐦𝐲 𝐡𝐞𝐚𝐝 𝐟𝐨𝐫 𝐚𝐧 𝐡𝐨𝐮𝐫. It's easy to fall into the trap of directly updating state based on its current value, like `setCount(count + 1)`. Works fine for simple stuff, right? But in scenarios with multiple rapid updates, or when you're relying on state from a stale closure inside an effect or async operation, you can end up with unexpected results. Your `count` might not be what you think it is. The fix? Use the updater function pattern: ```javascript // Don't do this if 'count' might be stale: // setCount(count + 1); // Do this for reliable updates: setCount(prevCount => prevCount + 1); // Or for complex objects: setUsers(prevUsers => [...prevUsers, newUser]); ``` This ensures your update always receives the latest state snapshot, not the one from when the function was created. It's a small detail, but it can save you from some tricky debugging sessions, especially in React apps with a lot of moving parts. Have you ever run into subtle `useState` issues like this? What's your go-to pattern for complex state updates? #React #JavaScript #Frontend #WebDevelopment #Debugging

🔑 Resetting State with key in React — A Simple but Powerful Pattern If you’ve ever tried to reset a component’s state in React and thought: “Why is this still holding onto old data?” — you’re not alone. Here’s the key insight 👇🏽 State belongs to a component instance, not the component itself. The common misconception Most developers think the key prop is only for lists. But key actually controls component identity. What really happens when key changes? When React sees a different key, it doesn’t just re-render. It: - Unmounts the old component - Discards its state - Creates a brand-new component instance - Initializes state from scratch In other words: a full reset. Why this matters Instead of: Manually resetting multiple useStates When this is especially useful ✅ Resetting forms after submission ✅ Switching between users or profiles ✅ Restarting multi-step flows ✅ Clearing deeply nested state The takeaway Using key to reset state is not a hack. It’s React working exactly as designed. Once you understand that changing the key means “new component”, your mental model becomes much clearer—and your code gets simpler. If React ever felt “stubborn” about resetting state, now you know why. Have you used this pattern before—or just learned it today? 👀 #React #FrontendDevelopment #JavaScript #WebDevelopment #LearningInPublic Adding complex useEffect logic Fighting leftover state

🚀 JavaScript Memory Management & Garbage Collection (Under the Hood) Understanding how JavaScript handles memory is key to writing efficient and bug-free applications. Here’s the mental model that made it clear 👇 🧠 Garbage Collection (Automatic Memory Management) JavaScript automatically frees memory using a garbage collector. 💡 Rule: An object stays in memory as long as it has at least one reference. let user = { name: "Rahul" } let anotherUser = user user = null 👉 The object is NOT removed — because anotherUser still holds a reference. 🔁 Closures & Memory Retention Closures can keep variables alive even after function execution. function outer() { let count = 0 return function () { count++ console.log(count) } } const counter1 = outer() const counter2 = outer() 💡 Each call creates a new closure with its own memory: • counter1 → independent state • counter2 → independent state ⚡ Why It Matters • Prevents memory leaks • Helps understand hidden data retention • Improves performance awareness • Essential for large-scale apps 🎯 Takeaway: Memory isn’t about allocation — it’s about references and lifecycle. Building a deeper understanding of how JavaScript behaves beyond just writing code. 💪 #JavaScript #MemoryManagement #Closures #WebDevelopment #FrontendDeveloper #MERNStack #SoftwareEngineering

𝗠𝗲𝗺𝗼𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗻𝗼𝘁 𝗮 "𝗳𝗿𝗲𝗲" 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝘄𝗶𝗻. ⚡ It’s tempting to wrap every calculation in useMemo or every function in useCallback. But in a large-scale React application, this can backfire. 𝗧𝗵𝗲 𝗖𝗼𝘀𝘁 𝗼𝗳 "𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻": Every time you use these hooks, you aren't just saving a calculation. You are: 1. 𝗜𝗻𝗰𝗿𝗲𝗮𝘀𝗶𝗻𝗴 𝗺𝗲𝗺𝗼𝗿𝘆 𝘂𝘀𝗮𝗴𝗲: React must store the previous value and the dependency array in memory. 2. 𝗔𝗱𝗱𝗶𝗻𝗴 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗼𝘃𝗲𝗿𝗵𝗲𝗮𝗱: On every render, React must run a shallow comparison on every dependency. If you are memoizing a simple .filter() on a 50-item list, the "optimization" overhead is often more expensive than the re-calculation itself. 𝗪𝗵𝗲𝗻 𝘁𝗵𝗲 𝘁𝗿𝗮𝗱𝗲-𝗼𝗳𝗳 𝗺𝗮𝗸𝗲𝘀 𝘀𝗲𝗻𝘀𝗲: ✅ 𝗛𝗲𝗮𝘃𝘆 𝗖𝗼𝗺𝗽𝘂𝘁𝗮𝘁𝗶𝗼𝗻: Expensive data processing (e.g., parsing large JSON or complex regex) that actually blocks the main thread. ✅ 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝘁𝗶𝗮𝗹 𝗜𝗻𝘁𝗲𝗴𝗿𝗶𝘁𝘆: When passing objects or functions to children wrapped in React.memo. Without it, the child re-renders on every parent update, defeating the purpose of React.memo. ✅ 𝗘𝗳𝗳𝗲𝗰𝘁 𝗦𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆: When the value is a dependency in a useEffect that triggers an API call or a heavy subscription. 𝗧𝗵𝗲 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆: Don't guess—measure. I’ve started using the 𝗥𝗲𝗮𝗰𝘁 𝗣𝗿𝗼𝗳𝗶𝗹𝗲𝗿 to identify "Wasted Renders" before reaching for a hook. Often, the better fix isn't memoization, but 𝘀𝘁𝗮𝘁𝗲 𝗰𝗼𝗹𝗹𝗼𝗰𝗮𝘁𝗶𝗼𝗻 or 𝗺𝗼𝘃𝗶𝗻𝗴 𝘁𝗵𝗲 𝘀𝘁𝗮𝘁𝗲 𝗱𝗼𝘄𝗻 the component tree. 𝗜𝗻 𝘆𝗼𝘂𝗿 𝗰𝘂𝗿𝗿𝗲𝗻𝘁 𝘀𝘁𝗮𝗰𝗸, 𝗮𝗿𝗲 𝘆𝗼𝘂 𝘀𝗲𝗲𝗶𝗻𝗴 𝗺𝗼𝗿𝗲 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗴𝗮𝗶𝗻𝘀 𝗳𝗿𝗼𝗺 𝗺𝗲𝗺𝗼𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗼𝗿 𝗳𝗿𝗼𝗺 𝗯𝗲𝘁𝘁𝗲𝗿 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 𝗰𝗼𝗺𝗽𝗼𝘀𝗶𝘁𝗶𝗼𝗻? 👇 #ReactJS #WebPerformance #FrontendEngineering #JavaScript #ProgrammingTips #SoftwareDevelopment

For 30 years, handling dates in JavaScript has been an absolute nightmare. Wait… what happens if we mutate the original 𝙳𝚊𝚝𝚎 object again? 😅 Or roll over to the next month… and land on March 2nd instead of February 28th? We’ve all been there. Instead of writing clean business logic, we were busy patching the 𝙳𝚊𝚝𝚎 API’s flaws with huge libraries. (Looking at you, Moment.js). While they saved us, they also bloated our bundles, adding megabytes of hard-to-tree-shake time zone data. We simply needed a better, built-in solution for the web. Enter 𝚃𝚎𝚖𝚙𝚘𝚛𝚊𝚕. After a massive 9-year journey across TC39, browsers, and developers (including heavy lifting by Bloomberg and Igalia), Temporal has reached Stage 4. 🚀 It’s the biggest addition to the ECMAScript spec since ES2015, and it finally gives us what we need: ✅ An immutable API (No more accidental object mutations!) ✅ First-class support for Time Zones & Calendars ✅ Distinct types for distinct needs: 𝚉𝚘𝚗𝚎𝚍𝙳𝚊𝚝𝚎𝚃𝚒𝚖𝚎, 𝙸𝚗𝚜𝚝𝚊𝚗𝚝, 𝙿𝚕𝚊𝚒𝚗𝙳𝚊𝚝𝚎, and 𝙳𝚞𝚛𝚊𝚝𝚒𝚘𝚗. ✅ Precision down to the nanosecond. As an engineer dealing with global microservices and highly available APIs, I can confidently say that 𝚃𝚎𝚖𝚙𝚘𝚛𝚊𝚕.𝚉𝚘𝚗𝚎𝚍𝙳𝚊𝚝𝚎𝚃𝚒𝚖𝚎 is going to make handling historical time zones and DST bugs a thing of the past. It is shipping in Firefox v139, Chrome v144, Edge v144, Node v26, and TS 6.0! If you want to understand why 𝙳𝚊𝚝𝚎 was so broken and the colossal engineering effort to fix it, this article from the Bloomberg JS team is a must-read. 🔗 Link in the comments! Have you played with the Temporal API yet? What legacy date-handling bug are you most excited to leave behind? #JavaScript #WebDevelopment #SoftwareEngineering #TemporalAPI #TechTrends #Frontend

Stop using headers() to force dynamic rendering in Next.js. 👇 Let’s be honest: we have all used the "dummy headers" hack. If you were building a component that fetched live database metrics, you didn't want Next.js to statically generate it at build time. But if you weren't actively reading a cookie or a URL parameter, Next.js would aggressively cache it anyway. To break the cache, we would drop headers() or cookies() at the top of our component just to trick the framework into Server-Side Rendering (SSR). It was a duct-tape solution that confused junior developers reading the codebase. Next.js 15 finally introduces the connection() API. ❌ The Legacy Hack: Calling request-specific APIs you don't actually need. Creates confusing, unreadable code intentions. Feels like fighting the framework. ✅ The Modern Standard: Just await connection(). • Explicit Intent: It clearly communicates to other developers (and the compiler) that this code must wait for an active user request to execute. • Zero Hacks: You no longer need to import unused cookies or headers. • Future Proof: It aligns perfectly with the new React Server Components asynchronous rendering model. The Shift: We are moving away from framework "hacks" and embracing explicit, native APIs to control our rendering boundaries. Learn how to use the Next.js 15 connection() API from next/server to explicitly opt into dynamic rendering. Discover how to replace the legacy headers() and cookies() hacks to force Server-Side Rendering (SSR) for real-time database queries in React Server Components. #NextJS #NextJS15 #ReactJS #WebDevelopment #Frontend #JavaScript #CleanCode #SoftwareEngineering #TechTips #WebArchitecture #WebDev

🧠 React Concept: Why Closures Cause “Stale State” Bugs Sometimes React code looks correct… but the behavior is confusing. Example 👇 function Counter() { const [count, setCount] = React.useState(0); function handleClick() { setTimeout(() => { console.log(count); }, 2000); } return ( <div> <button onClick={() => setCount(count + 1)}>Increment</button> <button onClick={handleClick}>Log Count</button> </div> ); } Now imagine this: 1️⃣ Click Increment → count becomes 1 2️⃣ Click Log Count 3️⃣ Click Increment again → count becomes 2 After 2 seconds… The console prints: 1 Not 2. 🤔 Why? Because of JavaScript closures. When handleClick runs, it captures the value of count at that moment. React updates state later, but the closure still remembers the old value. ✅ Correct Solution Use a ref to access the latest state. const countRef = useRef(count); useEffect(() => { countRef.current = count; }, [count]); setTimeout(() => { console.log(countRef.current); }, 2000); Now the value stays up-to-date. 🎯 Key Takeaway Many React bugs are not React problems. They are JavaScript closure problems. Understanding this saves hours of debugging. #ReactJS #JavaScript #FrontendDevelopment #ReactHooks #WebDevelopment #CodingTips #LearningInPublic