Prevent 'Too Many Rerenders' with Arrow Functions in React

🔥 Stale Closure in React — A Common Bug You Must Know Ever faced a situation where your state is not updating correctly inside setTimeout / setInterval / useEffect? 🤯 👉 That’s called a Stale Closure --- 💡 What is happening? A function captures the old value of state and keeps using it even after updates. --- ❌ Example (Buggy Code): import { useState, useEffect } from "react"; function Counter() { const [count, setCount] = useState(0); useEffect(() => { setInterval(() => { console.log(count); // ❌ Always logs 0 (stale value) }, 1000); }, []); return ( <button onClick={() => setCount(count + 1)}> Count: {count} </button> ); } 👉 Why? Because the closure captured "count = 0" when the effect first ran. --- ✅ Fix (Correct Approach): useEffect(() => { const id = setInterval(() => { setCount(prev => prev + 1); // ✅ always latest value }, 1000); return () => clearInterval(id); }, []); --- 🎯 Key Takeaway: Closures + async code (setTimeout, setInterval, event listeners) = ⚠️ potential stale state bugs --- 💬 Interview One-liner: “Stale closure happens when a function uses outdated state due to how closures capture variables.” --- 🚀 Mastering this concept = fewer bugs + stronger React fundamentals #ReactJS #JavaScript #Frontend #InterviewPrep #Closures #WebDevelopment

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 do we need to call 'super(props)' in the constructor of a React component? JavaScript classes aren't magic. They are just syntactic sugar over prototypes. If you are still using (or have used) Class Components in React, you have likely typed 'super(props)' a thousand times. But do you actually know what happens if you forget it? In JavaScript, you cannot use the keyword 'this' in a constructor until you have called the parent constructor. Since your component extends 'React.Component', calling 'super()' is what actually initializes the 'this' object. If you try to access 'this.state' or 'this.props' before that call, JavaScript will throw a ReferenceError and crash your app. But why pass 'props' into it? React sets 'this.props' for you automatically after the constructor runs. However, if you want to access 'this.props' inside the constructor itself, you must pass them to 'super(props)'. If you just call 'super()', 'this.props' will be undefined until the constructor finishes execution. Most of us have moved to Functional Components where this isn't an issue. But understanding these fundamentals is what separates a developer who just writes code from one who understands the runtime. #ReactJS #Javascript #SoftwareEngineering #WebDevelopment #Coding #ProgrammingTips

🧠 𝗗𝗲𝗺𝘆𝘀𝘁𝗶𝗳𝘆𝗶𝗻𝗴 𝗼𝗻𝗲 𝗼𝗳 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁’𝘀 𝗺𝗼𝘀𝘁 𝗺𝗶𝘀𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗼𝗼𝗱 𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘀 In the JavaScript ecosystem, the `this` keyword consistently trips up developers—whether you're just starting out or already building production-grade apps. Instead of treating it as a “gotcha,” I decided to break it down into a structured, practical guide. ✍️ New Blog Published: 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 `𝘁𝗵𝗶𝘀` 𝗞𝗲𝘆𝘄𝗼𝗿𝗱 𝗶𝗻 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 LINK: https://lnkd.in/g2USDC2Z In this article, I’ve covered: 🔹 How this behaves in different execution contexts 🔹 Differences between regular functions and arrow functions 🔹 Common pitfalls and how to avoid them 🔹 Real-world examples to make the concept stick Hitesh Choudhary Piyush Garg Chai Aur Code Anirudh J. Akash Kadlag Suraj Kumar Jha Jay Kadlag Nikhil Rathore DEV Community #JavaScript #WebDevelopment #TechnicalWriting #LearningInPublic #Chaicode

Just shared a new article on Medium about React Custom Hooks! 🚀 As React developers, we often struggle with bloated components. Custom Hooks are a game-changer for extracting reusable logic and keeping our codebase DRY (Don't Repeat Yourself). In this article, I cover: ✅ What Custom Hooks are ✅ Building a reusable useFetch hook ✅ Best practices for clean code Check it out here: https://lnkd.in/g2Pp46As #ReactJS #WebDevelopment #JavaScript #Programming #Frontend #CodingTips

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

𝐈𝐬 𝐲𝐨𝐮𝐫 `𝐮𝐬𝐞𝐄𝐟𝐟𝐞𝐜𝐭` 𝐫𝐮𝐧𝐧𝐢𝐧𝐠 𝐰𝐡𝐞𝐧 𝐢𝐭 𝐬𝐡𝐨𝐮𝐥𝐝𝐧'𝐭? 𝐓𝐡𝐞 𝐜𝐮𝐥𝐩𝐫𝐢𝐭 𝐦𝐢𝐠𝐡𝐭 𝐛𝐞 𝐦𝐨𝐫𝐞 𝐬𝐮𝐛𝐭𝐥𝐞 𝐭𝐡𝐚𝐧 𝐲𝐨𝐮 𝐭𝐡𝐢𝐧𝐤. I just spent a frustrating hour debugging a seemingly random data refetch in a React component, only to trace it back to a non-primitive dependency in my `useEffect` array. When you pass an object or a function created inside your component directly into `useEffect`'s dependency array, React performs a reference equality check. Even if the contents of your object or the logic of your function haven't changed, its reference is new on every render. This forces your effect to re-run unnecessarily. Here's the common trap: ```javascript // 🚨 Problematic: 'config' object reference changes on every render const MyComponent = ({ id }) => { const config = { userId: id, status: 'active' }; useEffect(() => { fetchData(config); }, [config]); // 💥 Effect re-runs even if 'id' hasn't changed // ... }; ``` A cleaner, more performant way is to stabilize those references. For configuration objects, `useMemo` is your friend: ```javascript // ✅ Solution: 'memoizedConfig' reference is stable as long as 'id' is const MyComponent = ({ id }) => { const memoizedConfig = useMemo(() => ({ userId: id, status: 'active' }), [id]); useEffect(() => { fetchData(memoizedConfig); }, [memoizedConfig]); // ... }; ``` This prevents wasted renders and unnecessary side effects, keeping your app snappier and less buggy. It's often the small details in `useEffect` that lead to the biggest headaches! Have you ever battled a similar `useEffect` dependency bug? What was your fix? #ReactJS #FrontendDevelopment #JavaScript #WebDev #ReactHooks

I stopped writing messy React code… and my projects became 10x easier to maintain. Here’s what changed 👇 Most developers focus on “making it work.” But clean code is what makes it scalable. One simple habit I adopted: 👉 Extract logic into reusable hooks Instead of this 👇 useEffect(() => { fetch("/api/users") .then(res => res.json()) .then(data => setUsers(data)) .catch(err => console.error(err)); }, []); I now do this 👇 // useFetch.js import { useState, useEffect } from "react"; export function useFetch(url) { const [data, setData] = useState(null); useEffect(() => { fetch(url) .then(res => res.json()) .then(setData) .catch(console.error); }, [url]); return data; } Then use it anywhere 👇 const users = useFetch("/api/users"); 💡 Why this matters: Cleaner components Reusable logic Easier debugging Better scalability Small improvements like this separate average developers from great ones. What’s one coding habit that improved your workflow? #React #JavaScript #CleanCode #WebDevelopment #Frontend

Stop writing anonymous useEffect functions. Name them. This is one of the smallest changes you can make in React — and one of the most underrated. Most of us write this: useEffect(() => { fetchUser(id); }, [id]); But you can do this: useEffect(function fetchUserOnIdChange() { fetchUser(id); }, [id]); Same behavior. Completely different debugging experience. Here's why it matters: 🔍 Stack traces become readable When something goes wrong inside an effect, your browser's stack trace will show fetchUserOnIdChange instead of just useEffect. You'll know exactly which effect blew up — no more hunting through 8 anonymous functions. 🧠 Self-documenting code A named function is a contract. It tells the next developer (or future you at 11pm) why this effect exists, not just what it does. syncFormWithLocalStorage communicates more than any comment ever could. ⚡ React DevTools clarity The React profiler and DevTools display effect names. When you're profiling performance, named effects let you immediately identify what's running, when, and how often. 🤝 Easier code reviews Reviewers can scan for useEffect(function loadDashboardMetrics and instantly understand intent. No need to read the entire body just to grasp the purpose. The rule of thumb I follow: If an effect is longer than 3 lines or runs conditionally, it gets a name. No exceptions. It takes 2 seconds to type. It saves 20 minutes of debugging. Small habits compound. This is one worth picking up. 🚀 What's a small React habit that's made a big difference for your team? Drop it in the comments 👇 #React #JavaScript #WebDevelopment #FrontendEngineering #CleanCode #ReactJS #SoftwareEngineering

A lot of people constantly ask me what React Hooks actually are, and the best way to think about Hooks and JavaScript concepts in general is to look at what problem they were trying to fix. For example, before React Hooks, people would create a Container Component and a Presentational Component. The Container Component would retrieve data, like making a fetch request, and then pass that data down to the Presentational Component, which was usually a pure function that returned some UI, like a div with styling, and accepted that data as props. This pattern helped create a standard for how data was retrieved in React and enforced separation of concerns, but it ended up being too boilerplate heavy for most people. So Hooks were introduced to let us hook into components directly, allowing us to load data as a side effect inside a function while still maintaining separation of concerns without needing extra components. #ReactJs #JavaScript #JavaScriptHooks