Event Loop Bottlenecks in JS Development

Using index as a key is dangerous Every React developer has written this at least once. items.map((item, index) => (  <li key={index}>{item}</li> )) Looks fine. Works fine. But it isn't This is Post 5 of the series: 𝗥𝗲𝗮𝗰𝘁 𝗨𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗛𝗼𝗼𝗱 Where I explain what React is actually doing behind the scenes. Here's what actually happens when you use index as key: You delete one item from a list. React doesn't know which item was removed. It just looks at positions. So it re-renders everything from that index downward. Input states get mismatched. Animations break. Bugs appear that you can't even reproduce consistently. And... No error. Just... wrong behavior. 🔑 Here's what React actually needs: A key isn't just something unique. It needs to be stable, unique, AND tied to the data — not the position. ❌ key={index} → breaks on delete, sort, filter  ❌ key={Math.random()} → new key every render = React destroys and recreates the node  ✅ key={item.id} → stable, reliable, React knows exactly who is who The rule is simple: If your list can ever be reordered, filtered, or deleted from... index as key will silently break your UI. Use your data's ID.  If it doesn't have one, generate it at creation — not during render. const newItem = { id: crypto.randomUUID(),   name: "New Task" } One tiny prop.  Massive impact on how React tracks your entire list. In Post 6 of React Under the Hood: What Happens When You Call setState Follow Farhaan Shaikh if you want to understand react more deeply. 👉 Read the previous post - Understanding diffing algorithm: https://lnkd.in/dzW3NP_V #SoftwareEngineering #ReactJS #WebDevelopment #JavaScript #FrontendDevelopment #BuildInPublic #LearnInPublic #ReactUnderTheHood

How I Understood Memory Leak in JavaScript One day I wrote this small code: let user = { name: "Siddharth" }; let map = new Map(); map.set(user, "Developer"); user = null; console.log(map); And I thought: 👉 “I removed the user… so memory should be free now.” But I was wrong. 🧠 What actually happened? Even after: user = null; The object was still in memory. Why? Because Map was still holding a reference to it. 👉 JavaScript says: “As long as something is pointing to this object, I won’t delete it.” That’s called a memory leak. 💡 Human way to understand this Imagine: You throw something in the dustbin 🗑️ But someone secretly keeps a copy of it. So it’s not really gone. That’s exactly what Map does here. ⚠️ The problem If this keeps happening in a real app: • Memory keeps increasing 📈 • App becomes slow 🐢 • Eventually crashes 💥 ✅ The fix (cleanup) let user = { name: "Siddharth" }; let map = new Map(); map.set(user, "Developer"); user = null; // Cleanup map.clear(); console.log(map); // Map(0) {} Now: 👉 No reference → memory gets freed 🚀 The lesson I learned 📌 Memory leaks happen when references are not removed 📌 Map keeps strong references 📌 Always clean up unused data Now whenever I use Map, I ask: 👉 Am I removing things I no longer need? Still learning JavaScript the human way. 🚀 #JavaScript #MemoryLeak #WebDevelopment #LearningInPublic #CleanCode #ReactJS #FrontendDevelopment #DeveloperJourney #Performance

🚀 Custom Hooks in React — Write Once, Reuse Everywhere As your React app grows… 👉 Logic starts repeating 👉 Components become messy 👉 Code becomes harder to maintain That’s where Custom Hooks come in. 💡 What are Custom Hooks? Custom Hooks are reusable functions that let you extract and share logic between components. 👉 Just like built-in hooks—but created by you ⚙️ Basic Example function useCounter() { const [count, setCount] = useState(0); const increment = () => setCount(c => c + 1); return { count, increment }; } 👉 Use it anywhere: const { count, increment } = useCounter(); 🧠 How it works ✔ Uses existing hooks (useState, useEffect, etc.) ✔ Encapsulates logic ✔ Returns reusable values/functions 🧩 Real-world use cases ✔ API fetching logic (useFetch) ✔ Form handling (useForm) ✔ Debouncing inputs (useDebounce) ✔ Authentication logic (useAuth) 🔥 Why Custom Hooks Matter 👉 Without them: ❌ Duplicate logic across components ❌ Hard to maintain code 👉 With them: ✅ Clean components ✅ Reusable logic ✅ Better scalability 🔥 Best Practices (Most developers miss this!) ✅ Prefix with “use” (important for React rules) ✅ Keep hooks focused on one responsibility ✅ Avoid tightly coupling with UI ❌ Don’t over-abstract too early ⚠️ Common Mistake // ❌ Mixing UI + logic function useData() { return <div>Data</div>; } 👉 Hooks should return data/logic—not JSX 💬 Pro Insight (Senior Thinking) 👉 Components = UI 👉 Hooks = Logic 👉 Clean separation = scalable architecture 📌 Save this post & follow for more deep frontend insights! 📅 Day 18/100 #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #CodeQuality #SoftwareEngineering #100DaysOfCode 🚀

If you’re writing 5 files just to toggle a boolean... 🛑 You’re not scaling. You’re over-engineering. For a long time, I used Redux for almost everything in React. And honestly? It felt powerful... but also unnecessarily complex for 90% of my use cases. Recently, I switched to Zustand — and the difference is 🔥 Why Zustand just makes sense: ✅ Zero Boilerplate No Providers. No massive folder structures. Just create and use. ✅ Hook-Based If you know useState, you already understand Zustand. It feels like native React. ✅ Performance First It handles selective re-renders out of the box. Only the components that need the data will update. 💻 The "Store" is this simple: JavaScript import { create } from 'zustand' const useStore = create((set) => ({ count: 0, inc: () => set((state) => ({ count: state.count + 1 })), })) Use it anywhere: JavaScript function Counter() { const { count, inc } = useStore() return <button onClick={inc}>{count}</button> } ⚡ 𝗣𝗥𝗢 𝗠𝗢𝗩𝗘 (Most developers miss this): Use selectors to grab only what you need: const count = useStore((state) => state.count) This keeps your app lightning-fast even as your state grows massive. 📈 Since switching, my code is: → Simpler → Cleaner → Easier to maintain 🟣 Team Redux (The tried and true) 🐻 Team Zustand (The minimalist) #ReactJS #Zustand #JavaScript #WebDevelopment #Frontend #CodingTips #SoftwareEngineering

🧠 Why map() in React Needs a key (Beyond Just a Warning) Most developers know this warning: “Each child in a list should have a unique key” So they do this 👇 {items.map((item, index) => ( <li key={index}>{item}</li> ))} Warning gone ✅ Problem solved ❌ 🔍 What actually happens? React uses key to track elements between renders. If you use index: 👉 React assumes position = identity ⚠️ The hidden bug const items = ["A", "B", "C"]; Now remove "A". New list: ["B", "C"] With index as key: "B" becomes index 0 React thinks it’s still "A" 👉 UI can behave incorrectly 👉 State can get mixed up ✅ Correct approach {items.map(item => ( <li key={item.id}>{item.name}</li> ))} 👉 Use a stable, unique key 🎯 Real Insight key is not for React warnings. It’s for correct UI behavior. 💥 Senior-level understanding Bad keys don’t always break immediately. They break when: Items reorder Items are removed State is attached to elements That’s why bugs feel random. #ReactJS #FrontendDevelopment #JavaScript #CleanCode #WebDevelopment #CodingTips #LearningInPublic

🚨 Infinite API Calls: The Silent Killer of Your App Everything looks fine… until your API starts getting hammered with requests nonstop 😬 If you’ve worked with React (or any frontend framework), chances are you’ve faced this at least once. 🔴 The Problem: Your component keeps calling an API again… and again… and again. ➡️ Backend gets overloaded ➡️ UI becomes sluggish ➡️ Rate limits get hit ➡️ Users suffer Most of the time, it comes down to a simple mistake. ⚠️ Common Causes: Missing dependency array in useEffect: Runs on every render Incorrect dependencies: State updates trigger the effect repeatedly Updating state inside the same effect that depends on it: Creates a loop Functions recreated on every render: Triggers effect again ⚡ How to fix it: ✅ 1. Use Dependency Array Correctly useEffect(() => { fetchData(); }, []); // runs only once ✅ 2. Be Careful with State Updates Avoid updating a state that is also in your dependency array unless necessary. ✅ 3. Memoize Functions const fetchData = useCallback(() => { // API call }, []); ✅ 4. Use Flags / Conditions if (!data) { fetchData(); } ✅ 5. Use Libraries Tools like React Query or SWR handle caching, refetching, and prevent unnecessary calls. 💡 Pro Tip: If your API tab in DevTools looks like a machine gun 🔫, you’ve got an infinite loop. Small mistake. Big impact. Debugging this once will make you a better developer forever. Have you ever run into infinite API calls? How did you fix it? 👇 #ReactJS #WebDevelopment #FrontendDevelopment #JavaScript #SoftwareEngineering #Debugging #ProgrammingTips #CleanCode #DevCommunity #ReactDeveloper #WebDevTips #API #PerformanceOptimization #CodeQuality #TechTips

🧠 Day 26 — Rest vs Spread Operator in JavaScript (Simplified) Both use ... — but they do very different things 👀 --- 🔍 The Idea 👉 Spread → Expands values 👉 Rest → Collects values --- ⚡ 1. Spread Operator ... 👉 Expands elements const arr = [1, 2, 3]; const newArr = [...arr, 4]; console.log(newArr); // [1, 2, 3, 4] 👉 Also used in objects const user = { name: "John" }; const newUser = { ...user, age: 25 }; --- ⚡ 2. Rest Operator ... 👉 Collects remaining values function sum(...nums) { return nums.reduce((a, b) => a + b, 0); } sum(1, 2, 3); // 6 --- 🧠 Key Difference Spread → Expands data Rest → Gathers data --- ⚠️ Important Rule 👉 Rest must be last parameter function test(a, ...rest) {} // ✅ --- 🚀 Why it matters ✔ Cleaner code ✔ Flexible functions ✔ Used heavily in React & modern JS --- 💡 One-line takeaway: 👉 “Spread expands, Rest collects.” --- Once you understand this, working with arrays & functions becomes much easier. #JavaScript #ES6 #SpreadOperator #RestOperator #WebDevelopment #Frontend #100DaysOfCode 🚀

𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗺𝗼𝗱𝘂𝗹𝗲 𝗳𝗼𝗿𝗺𝗮𝘁𝘀 𝗰𝗮𝗻 𝗯𝗲 𝗰𝗼𝗻𝗳𝘂𝘀𝗶𝗻𝗴 — 𝗲𝘀𝗽𝗲𝗰𝗶𝗮𝗹𝗹𝘆 𝘄𝗵𝗲𝗻 𝘆𝗼𝘂 𝗿𝘂𝗻 𝗶𝗻𝘁𝗼 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗼𝗻𝗲𝘀 𝗮𝗰𝗿𝗼𝘀𝘀 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀. Here’s a quick mental model 👇 𝗖𝗼𝗺𝗺𝗼𝗻𝗝𝗦 Used in classic Node.js backends const lib = require('lib'); Simple and synchronous. Still widely used, but gradually being replaced. 𝗘𝗦 𝗠𝗼𝗱𝘂𝗹𝗲𝘀 (𝗘𝗦𝟮𝟬𝟭𝟱+) Modern standard for browsers and Node.js import lib from 'lib'; Tree-shakable, static, and the future of JavaScript. 𝗔𝗠𝗗 Designed for browsers before native modules existed (RequireJS era) define(['dep'], function(dep) { ... }); Now mostly legacy. SystemJS Dynamic module loader System.register([...], function(...) { ... }); Used in specific cases like plugin systems or legacy apps. 𝗨𝗠𝗗 "Write once, run anywhere" format Works in both browser and Node.js if (typeof define === 'function') { ... } Common in older libraries that needed maximum compatibility. 💡 Key takeaway: Use 𝗘𝗦 𝗠𝗼𝗱𝘂𝗹𝗲𝘀 for modern apps Expect 𝗖𝗼𝗺𝗺𝗼𝗻𝗝𝗦 in backend or legacy code Treat 𝗔𝗠𝗗 / 𝗦𝘆𝘀𝘁𝗲𝗺𝗝𝗦 / 𝗨𝗠𝗗 as historical or niche Understanding these formats makes debugging build issues much easier. #JavaScript #Frontend #WebDevelopment #NodeJS #SoftwareEngineering #DevTips #Programming

The event loop is one of the most explained and most misunderstood topics in JavaScript. Most resources treat Browser and Node.js as similar — they're not. Wrote my humble contribution covering the actual differences: correct libuv phase order, microtask timing, the setTimeout vs setImmediate race condition, and browser equivalents of Node.js APIs. https://lnkd.in/ddkw39d2 #JavaScript #NodeJS #EventLoop #WebDevelopment

Why is my code running "out of order"? (Eager vs. Lazy Evaluation) Ever passed a function as an argument and wondered why it executed before the function it was passed into? Look at this common "gotcha": javascript const main = (fn) => {  console.log("start");  fn();  console.log("end"); }; const createLogger = (msg) => {  console.log("start logger");  return () => console.log(msg); }; // ❌ Unexpected Order: "start logger" -> "start" -> "success" -> "end" main(createLogger("success")); Use code with caution. What’s happening? This is Eager Evaluation. In JavaScript, arguments are evaluated immediately before the outer function runs. Because we used parentheses () on createLogger, JS executes it first to find out what value to give to main. It’s like cooking a 5-course meal before your guests even knock on the door! 🥘 The Fix: Lazy Evaluation 💤 If we want main to control the timing, we need to wrap our logic in a "thunk" (a wrapper function). This tells JS: "Don't run this yet; run it only when I call it." javascript // ✅ Correct Order: "start" -> "start logger" -> "success" -> "end" main(() => createLogger("success")()); Use code with caution. Why does this matter in Node.js? Understanding this distinction is huge for: ✅ Middleware: Deciding when a request starts/ends. ✅ Performance: Avoiding expensive calculations unless they are actually needed. ✅ Closures: Controlling scope and execution timing. Stop executing, start referencing! 🚀 #JavaScript #WebDevelopment #NodeJS #CodingTips #SoftwareEngineering