Building a Custom React Hook for Async Function Execution with Cancellation and Retry Support

🚀 Node.js Event Loop — Explained Like You're in an Interview Ever faced this question? 👉 “What is the Event Loop in Node.js?” Let’s make it super simple 👇 🧠 Think of Node.js like a smart manager Instead of doing everything itself, it: • Delegates tasks • Keeps moving forward • Comes back when tasks are done That’s the Event Loop in action ⚡ ⚙️ How it actually works 1️⃣ Code runs → Call Stack 2️⃣ Async tasks → handled by Web APIs / Node APIs 3️⃣ Completed tasks → move to Queue 4️⃣ Event Loop → checks & executes when stack is empty 👉 And this loop never stops 🔁 📌 Quick Example console.log("Start"); setTimeout(() => { console.log("Timeout"); }, 0); console.log("End"); 💡 Output Start End Timeout ❓ Why not “Start → Timeout → End”? Because: • setTimeout is async • It goes to the queue • Event Loop waits for stack to clear first 🎯 Interview One-Liners ✔ Node.js is single-threaded but handles concurrency ✔ Event Loop = heart of async behavior ✔ Non-blocking I/O = high performance 🔥 Real Developer Insight If you understand Event Loop, you can: • Fix weird async bugs • Improve performance • Write production-ready backend code #NodeJS #JavaScript #BackendDevelopment #EventLoop #AsyncProgramming #WebDevelopment #FullStackDeveloper #CodingInterview #TechInterview

Nobody expects to fail these 7 React questions. And then they do. The tricky part? None of them are about some lesser-known API. They test whether you actually understand how React works under the hood. Here's what catches people off guard: 🔴 setState batching — calling setCount(count + 1) three times doesn't give you 3. It gives you 1. Closures are sneaky. 🟡 useRef vs useState — mutating a ref updates the value, but the UI never knows. It just sits there. Stale. 🔵 Stale closures in useEffect — an empty dependency array + setInterval = a timer that's frozen in time. Forever stuck at 1. 🟢 React.memo shallow trap — you wrapped your component in memo, feeling smart. But you're passing a new object literal every render. Memo does nothing. 🟣 useEffect cleanup order — most devs think cleanup only runs on unmount. Wrong. It runs before every single re-render effect. Every. Time. 🟡 Index as key — it works until you sort, filter, or reorder. Then React maps the wrong DOM to the wrong data. Inputs keep stale values. Good luck debugging that. 🔴 State mutation — you pushed to the array and called setState. React compared references. Same ref = no update. Your UI is frozen and you have no idea why. I put all 7 into a carousel with code snippets, wrong answers, correct answers, and explanations. Swipe through and test yourself honestly. The pattern? The questions that trip people up aren't about syntax. They're about understanding how React actually thinks. Save this for your next interview — whether you're giving it or taking it. --- #react #javascript #frontend #interviewprep #webdevelopment #softwareengineering #reactjs

I noticed a pattern after clearing technical rounds at 𝟭𝟴+ 𝗰𝗼𝗺𝗽𝗮𝗻𝗶𝗲𝘀... A lot of interviews don’t test random knowledge. They test patterns. If you're preparing for frontend roles (especially JS + React), these are the areas I was repeatedly asked in machine coding + technical rounds: 🚀 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁  • Flatten array (with depth param)  • Flatten object  • Deep object comparison  • String problems (sequential count, unique count)  • Sorting without using sort()  • Recursion (comes up a LOT)  • Group by category  • reduce() based problems  • Two-pointer problems  • Function currying  • Promise-based questions  • Using apply() to solve real problems  • Polyfills: map, filter ⚛️ 𝗥𝗲𝗮𝗰𝘁  • Debounce & Throttle (and implementing useDebounce)  • Timer-based problems  • Custom hooks (useFetch)  • Filtering & sorting UI  • Infinite scrolling  • Virtual scrolling  • Pagination (basic but important)  • API fetching patterns  • Combining virtual + infinite scrolling  • Classic apps: Todo / Tic Tac Toe (with twists) 💡 𝗢𝗻𝗲 𝘁𝗵𝗶𝗻𝗴 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱: It’s not about knowing everything. It’s about recognizing patterns and thinking clearly under pressure. 𝗠𝗼𝘀𝘁 𝗿𝗼𝘂𝗻𝗱𝘀 𝗳𝗲𝗹𝘁 𝗹𝗶𝗸𝗲: “𝘓𝘦𝘵’𝘴 𝘴𝘦𝘦 𝘩𝘰𝘸 𝘺𝘰𝘶 𝘢𝘱𝘱𝘳𝘰𝘢𝘤𝘩 𝘵𝘩𝘪𝘴” 𝘳𝘢𝘵𝘩𝘦𝘳 𝘵𝘩𝘢𝘯 “𝘋𝘰 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘵𝘩𝘪𝘴 𝘦𝘹𝘢𝘤𝘵 𝘢𝘯𝘴𝘸𝘦𝘳?” If you're preparing right now, focus more on problem patterns + clarity of thought than memorizing solutions. Happy to share more from my prep journey if it helps someone 🙂 #Frontend #JavaScript #React #InterviewPrep #MachineCoding #WebDevelopment

🚀 Still writing boilerplate Redux code in 2026? Stop now. Redux Toolkit changed the game for React developers. Cleaner code ✅ Faster setup ✅ Better scalability ✅ Interview ready ✅ I used to think Redux was complicated… until I learned Redux Toolkit + Slice Pattern. Now state management feels simple and powerful. 💡 🔥 In this post you’ll learn: ✅ Why Redux Toolkit is better than classic Redux ✅ How createSlice() reduces boilerplate ✅ How to dispatch actions in seconds ✅ How to select state like a pro ✅ How to explain Redux confidently in interviews 💻 If you’re preparing for Frontend / React interviews, remember this one line: 👉 Redux Toolkit = Modern Redux with less code and better performance 📌 Pro Tip for Interviews: When asked “Explain Redux quickly” say this: Store stores global state, Slice manages features, Reducers update state, Dispatch triggers actions, Selector reads state. That single answer can impress interviewers instantly. 🎯 ⚡ Developers who know Redux Toolkit are already ahead of many React devs. Are you one of them? Comment “SLICE” and I’ll share more advanced Redux Toolkit interview questions & real projects. 👇 #ReactJS #Redux #ReduxToolkit #JavaScript #FrontendDeveloper #WebDevelopment #CodingInterview #ReactDeveloper #100DaysOfCode #Programming #SoftwareEngineer #TechCareers

👉 “Same data. Same values. Different render. Welcome to React’s reference equality.” You wrote the logic right. Your data didn’t change. But your component still re-renders… 🤯 Let’s break the illusion 👇 React doesn’t compare objects by value. It compares them by reference. So even if this looks identical: { value: 10 } !== { value: 10 } 👉 React sees it as changed 👉 Your useMemo runs again 👉 Your memoization breaks 👉 Performance takes a hit ⚠️ The Hidden Trap useMemo(() => { // runs every render 😬 }, [{ value: 10 }]); Every render = new object New object = new reference New reference = React thinks “changed” ✅ The Right Way ✔️ Use primitive dependencies ✔️ Extract specific fields 🧠 Golden Rule React is fast. But it trusts references, not intentions. 🎯 Final Thought Most React bugs aren’t in your logic… They’re in how React interprets your data. #ReactJS #JavaScript #FrontendDevelopment #WebDevelopment #SoftwareEngineering #ReactHooks #WebPerformance #CleanCode #Programming #Developers #TechCommunity #CodingLife #DevCommunity #LearnToCode #CodeNewbie #100DaysOfCode #DeveloperLife #TechTips #PerformanceOptimization #UIEngineering

🧠 The "Tricky Question" We All Fall For: A Deeper Look at JS Closures Have you ever faced THAT question in a technical interview? 👨💻 You know the one—the loop, the var, and the setTimeout that just refuses to print what you expect. It feels like a rite of passage for every JavaScript developer. But here’s the real kicker: Why do we keep falling for it, even when we know the answer? 🧐 The Core of the Mystery 🔍 This simple loop cuts to the heart of several advanced JavaScript concepts that even senior devs debate: 1️⃣ Function Scope vs. Block Scope: We know var is function-scoped and let is block-scoped. But visualizing that distinction while a loop is racing through your mind is tough! Our brains want each iteration to have its own "memory" 🧠, but var just doesn't work that way. 2️⃣ The Power of Closures: This is the real star. The function inside setTimeout creates a closure over the variable i. It remembers i... but it remembers the one, final value because that’s where the var reference leads. 🔗 3️⃣ The Event Loop (Concurrency): Our intuition says the timer should log "right now." But the Event Loop dictates that the logs can only happen after the loop is completely finished. By then, i has already hit its final form: 3. 🛑 Why It’s Still Tricky (Even for Pros) 💡 Even after fixing it with let, the cognitive dissonance remains. Our brains prefer linear execution, but JavaScript’s model is more of a synchronized dance. 💃 The Challenge: Next time you see this, don’t just "fix" it. Reflect on why your initial instinct was wrong. It’s the best exercise for mastering closures and scoping. What is the classic JS question YOU still have to think twice about? Let’s unpack them in the comments! 👇 #JavaScript #WebDevelopment #CodingLife #SoftwareEngineering #FrontendDeveloper #ProgrammingTips #TechInterview #JSClosures #CodeNewbie #WebDevTips

Using different frameworks and libraries, sometimes we forget about the basics. Even though we use these concepts daily in our code, we slowly lose grip on how things actually work behind the scenes. And then it happens… You’re sitting in an interview, and the interviewer asks something fundamental — closures, scope, Virtual DOM — and suddenly your mind goes blank. Not because you don’t know it… But because you haven’t revisited it. It’s easy to rely on modern tools like React, Next.js, and libraries that abstract away complexity. But those abstractions are built on core concepts — and that’s exactly what interviewers test. Lately, I’ve realized: Revisiting fundamentals isn’t going backward — it’s leveling up. Understanding things like: • How closures actually retain data • Why this behaves differently in arrow functions • How React optimizes rendering with its diffing algorithm • The real difference between Promises and async/await …makes you more confident, more clear, and less likely to freeze under pressure. Strong fundamentals don’t just help you crack interviews — they make you a better engineer. Currently focusing on strengthening my core concepts again. Because at the end of the day, frameworks evolve — fundamentals don’t. #JavaScript #ReactJS #FrontendDevelopment #WebDevelopment #CareerGrowth #Learning

Handling multiple asynchronous tasks using callbacks can quickly become messy. This problem is known as Callback Hell. In this video, I explain: • How async dependency flow works (login → profile → posts → comments) • Why callbacks create nested structures • Why this makes code hard to read and maintain • How promises simplify execution • Why async/await is the modern solution Key takeaway: 👉 Callbacks → complex & nested 👉 Promises → structured flow 👉 Async/Await → clean & readable Understanding this is critical for: • Frontend development • React applications • JavaScript interviews 🎓 Learn JavaScript & React: 👉 https://lnkd.in/gpc2mqcf 💬 Comment Link if you want full roadmap. #JavaScript #FrontendDevelopment #SoftwareEngineering #WebDevelopment #Programming #JSConcepts #DeveloperEducation

JSON.stringify for deep equality checks is one of those habits that silently kills performance. It works. Until it doesn't - and by then, you've already paid the cost a thousand times over in a hot render loop or a high-frequency event handler. The problem is simple: stringify serializes the entire object just to produce a string you immediately throw away. It's allocation-heavy, order-sensitive, and completely unaware of undefined or function values. Here's the pattern I see constantly: if (JSON.stringify(prevState) === JSON.stringify(nextState)) return; Instead, reach for a purpose-built solution: import { equals } from "fast-deep-equal"; if (equals(prevState, nextState)) return; fast-deep-equal benchmarks significantly faster, handles edge cases correctly, and doesn't allocate intermediate strings. For most use cases, it's a drop-in replacement. Practical takeaway - audit any equality check sitting inside a loop, React hook, or event listener. If stringify is there, it's costing you more than you think. Have you profiled stringify-based comparisons in your own codebase and actually measured the impact? #JavaScript #WebPerformance #FrontendDevelopment #ReactJS #WebDev #CodeQuality

📒 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 𝐡𝐚𝐬 𝐚 𝐜𝐥𝐞𝐚𝐧𝐞𝐫 𝐫𝐮𝐧𝐧𝐢𝐧𝐠 𝐢𝐧 𝐭𝐡𝐞 𝐛𝐚𝐜𝐤𝐠𝐫𝐨𝐮𝐧𝐝… 𝐚𝐧𝐝 𝐦𝐨𝐬𝐭 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫𝐬 𝐢𝐠𝐧𝐨𝐫𝐞 𝐢𝐭. 𝑌𝑒𝑠, 𝐼’𝑚 𝑡𝑎𝑙𝑘𝑖𝑛𝑔 𝑎𝑏𝑜𝑢𝑡 𝐺𝑎𝑟𝑏𝑎𝑔𝑒 𝐶𝑜𝑙𝑙𝑒𝑐𝑡𝑖𝑜𝑛 (𝐺𝐶) ♻️ Every time you create: ✅ objects ✅ arrays ✅ functions 𝐽𝑎𝑣𝑎𝑆𝑐𝑟𝑖𝑝𝑡 𝑎𝑙𝑙𝑜𝑐𝑎𝑡𝑒𝑠 𝑚𝑒𝑚𝑜𝑟𝑦. 𝐵𝑢𝑡 𝑡ℎ𝑒 𝑟𝑒𝑎𝑙 𝑞𝑢𝑒𝑠𝑡𝑖𝑜𝑛 𝑖𝑠… When does JS free that memory? ➡️ Only when the value becomes unreachable. 🔥 Reachable = Alive If something can be accessed from: 1️⃣ global variables 2️⃣ current function variables 3️⃣ call stack …it stays in memory. Example: 𝗹𝗲𝘁 𝘂𝘀𝗲𝗿 = { 𝗻𝗮𝗺𝗲: "𝗝𝗼𝗵𝗻" }; 𝘂𝘀𝗲𝗿 = 𝗻𝘂𝗹𝗹; Now no one can access it → GC removes it. ⚡ 𝐵𝑖𝑔𝑔𝑒𝑠𝑡 𝑚𝑖𝑠𝑐𝑜𝑛𝑐𝑒𝑝𝑡𝑖𝑜𝑛: “Objects are deleted when they have no references.” Not exactly. Because two objects can reference each other and STILL get deleted. 📌 If the main root reference is gone, the whole connected group becomes an unreachable island → GC clears everything. 🚀 𝑊ℎ𝑦 𝑠ℎ𝑜𝑢𝑙𝑑 𝑦𝑜𝑢 𝑐𝑎𝑟𝑒? Because this is how memory leaks happen: ❌ event listeners not removed ❌ unused variables still holding references ❌ large objects stored unnecessarily Result: 🐢 slow apps 💥 crashes 📉 poor performance 💡 Simple rule: If you don’t need it → remove the reference. Because JavaScript will clean it… only after you let go. #JavaScript #WebDevelopment #Frontend #ReactJS #Programming #Coding #SoftwareEngineering #Tech #Learning #interview