Avoid Using Index as Key in React

Nobody told me this when I started React. I learned props. I learned the state. I thought I understood both. I didn't. I was putting everything in state. User data. Config values. Things passed in from the parent. Didn't matter — if I needed it inside a component, it went into useState. It worked. Until it didn't. On a client project, I had a component receiving a userId from its parent. I was also storing that userId in local state. Then the parent updated. My local state didn't. Two different values. One component. Complete mess. The bug took me hours to find. The fix was deleting four lines of code. Here's what nobody told me: Props and state are not two ways to store data. They are two completely different things with two completely different jobs. Props are data that comes from outside. The parent owns it. The parent controls it. Your component just receives it and uses it. You don't store it. You don't copy it. You use it directly. State is data that lives inside. Your component owns it. Your component controls it. When it changes, the component re-renders. Nothing outside knows it exists unless you explicitly pass it down. One simple test I use now: Does this component own this data — or is it just receiving it from somewhere else? If it owns it → state. If it's receiving it → props. Use it directly. Never copy it into state. That one question has saved me from every props-vs-state bug I've ever faced. The bug I had on that client project? I was copying props into the state. The parent updated the prop. My state copy didn't follow. UI showed stale data. Classic mistake. Extremely common. Nobody warns you about it early enough. #React #JavaScript #Frontend #ReactJS #WebDevelopment #Programming #100DaysOfCode #SoftwareDevelopment

🚀 5 React Mistakes I Made as a Beginner (And How to Fix Them) When I first started building with React, I made a lot of mistakes that slowed me down and introduced bugs I couldn't explain. Here are 5 of the most common ones — and how to fix them: ❌ #1 — Not cleaning up useEffect Forget to return a cleanup function? Hello, memory leaks. ✅ Always return a cleanup for timers, event listeners, and subscriptions. ❌ #2 — Using index as a key in lists This breaks React's reconciliation and causes weird UI bugs. ✅ Always use a unique ID from your data as the key prop. ❌ #3 — Calling setState directly inside render This creates an infinite re-render loop. ✅ Keep state updates inside event handlers or useEffect only. ❌ #4 — Fetching data without handling loading and error states Your UI breaks or shows nothing while data loads. ✅ Always manage three states: loading, error, and success. ❌ #5 — Putting everything in one giant component Hard to read, hard to debug, impossible to reuse. ✅ Break your UI into small, focused, reusable components. These mistakes cost me hours of debugging. I hope sharing them saves you that time. If you found this helpful, feel free to repost ♻️ — it might help another developer on their journey. 💬 Which of these mistakes have you made? Drop a comment below! #React #JavaScript #WebDevelopment #Frontend #MERNStack #ReactJS #100DaysOfCode #CodingTips #Developer

🚨 Why is useEffect firing twice in React? (Every React developer hits this at least once 👀) You write a simple useEffect(): useEffect(() => { console.log("API Called"); }, []); Expected: ✅ Runs once when component mounts Reality in development: ❌ Runs twice At first, it feels like a bug. But it’s actually React helping you. Here’s why: In React 18, Strict Mode intentionally runs effects twice in development to detect: • Side effects that aren’t properly cleaned up • Unsafe component behavior • Bugs that may appear in production later Think of it like a stress test for your code. Example: Without cleanup: API calls may duplicate Event listeners may stack Timers may keep running Better approach: ✔ Add cleanup functions ✔ Make effects idempotent ✔ Avoid unnecessary side effects Example: useEffect(() => { const timer = setInterval(() => { console.log("Running..."); }, 1000); return () => clearInterval(timer); }, []); Important: This double execution happens only in development mode, not production. So next time useEffect fires twice, don’t panic. React is exposing hidden issues before users do. 📌 Part 1 of my React series Next: Dependency Array Explained Simply ⚛️ https://inhamtools.com/ https://lnkd.in/daSAPzAX #ReactJS #JavaScript #WebDevelopment #Frontend #Programming #SoftwareEngineering

I spent 3 months confused by React. Then I learned Hooks — and everything finally clicked. Most tutorials throw you into class components and lifecycle methods. It's overwhelming. But Hooks changed everything — they made React actually fun to write. Here's the complete mental map I wish I had on day one: ⚡ useState — add local state to any function component ⚡ useEffect — handle side effects (API calls, subscriptions) 🔵 useRef — access DOM elements & persist values without re-rendering 🔵 useContext — share data across the component tree 🟡 useMemo — cache expensive calculations 🟡 useCallback — memoize functions to prevent unnecessary re-renders 🟢 useReducer — manage complex state with reducer logic 🟢 useLayoutEffect — like useEffect, but fires before paint 5 tips to go from beginner → advanced: Master useState & useEffect DEEPLY before moving on Build custom hooks — extract logic you reuse (e.g. useWindowSize) Think in data flow — hooks work best when you understand how state moves Optimize wisely — reach for useMemo/useCallback only when you actually need them Keep building. Real projects teach what tutorials can't. Hooks aren't just syntax — they're a new way of thinking about UI logic. If you're just starting out: be patient with yourself. The mental model takes time. Once it lands, you'll wonder how you ever coded without them. Save this post — it'll make sense in ways it doesn't yet. 🔖 Which Hook was the hardest for you to wrap your head around? Drop it below 👇 #ReactJS #WebDevelopment #JavaScript #Frontend #ReactHooks #Coding #LearnToCode #SoftwareEngineering #100DaysOfCode

I’ve been go through React hooks lately, and I just finished building a fully functional Todo List that handles complex state updates. 💻 I know this isn't a "polished" UI yet, but through building this project, I’ve learned an immense amount—from the hair-pulling bugs I faced to the satisfaction of finally making the logic work. While a Todo list is a classic "beginner" project, the real architectural lessons happened under the hood: 🔹 Immutability with the Spread Operator: Learning why we never mutate state directly and instead use [...prevTodos] to create clean, predictable UI updates. 🔹 Unique Identifiers: Implementing uuidv4 for keys to ensure React's reconciliation process stays efficient and bug-free. 🔹 Functional State Updates: Using the callback pattern (prevTodos) => ... to ensure I'm always working with the most recent data, avoiding "stale state" traps. 🔹 Conditional Styling: Using ternary operators to toggle text-decoration for a "Mark as Done" feature. Every bug I fixed was a lesson in disguise. Next step: persisting this data with localStorage and then focusing on the CSS! 🏗️ #ReactJS #FrontendDevelopment #Coding #WebDev #StateManagement #LearningByDoing

Three useEffects, all anonymous. A production bug. Spent 40 minutes fixing what should have taken 5. Not again. useEffect(() => { ... }) will tell you nothing when it breaks. No stack trace, no clues in react devtools. Just anonymous in the profiler 15 times. This is what happened to us. Three effects in a single component - all of them anonymous. The error referred to the component, but didn’t specify the effect. Three senior engineers manually debugging the issue, staring at the same file. The tool wasn’t the solution, the tool was a naming convention: useEffect(function syncCartWithLocalStorage() { ... }) One small change. Then I set a rule for the team: → Every useEffect should be a named function. → The name should describe what the effect does, not when. → syncCart, fetchUserProfile, subscribeToSocket are preferred over onMount or handleChange. The results after 2 months were: - 30% reduction in time spent debugging. - Stack traces were self documenting. - New developers were onboarded quickly - effects read like a table of contents. - Code reviews were shorter. The name alone explained what was expected. Debuggability is not a feature you add later, it’s a habit you embed in every line. What’s your small syntax habit that saved you hours of debugging? #ReactJS #FrontendEngineering #WebDevelopment #CodeQuality #DeveloperProductivity

🚀 Crack the Code: The React Lifecycle (Core Level) Ever wondered how React actually manages the life of a component? Whether you’re prepping for a Senior Dev interview or just trying to squash that persistent memory leak, mastering the Lifecycle Phases is your secret weapon. 🛠️ React components are like living organisms: they are born, they grow, and they eventually pass away. 1️⃣ The Birth: Mounting Phase This is where it all begins. React initializes state and builds the initial Virtual DOM. The Hook: useEffect(() => { ... }, []) Pro Tip: Use this phase for initial API calls or setting up subscriptions. If you leave the dependency array empty, it runs exactly once—like a birth certificate! 2️⃣ The Growth: Updating Phase Whenever props or state change, React springs into action. This is where the magic of Diffing happens—React compares the old Virtual DOM with the new one to update only what’s necessary. The Hook: useEffect(() => { ... }, [dependency]) Pro Tip: Always be intentional with your dependency array. Missing a dependency can lead to stale data; adding too many can cause infinite loops! 🔄 3️⃣ The End: Unmounting Phase The most ignored phase, but arguably the most critical for performance. 🧹 The Hook: The Cleanup Function inside useEffect. Why it matters: If you don't clear your setInterval or unsubscribe from a socket here, you’re inviting memory leaks to crash your party. 💡 The "Core Level" Secret: Render vs. Commit To keep your apps buttery smooth, React splits work into two internal phases: Render Phase: Pure calculation. React figures out what changed. It can pause or restart this work if a higher-priority task comes in. Commit Phase: This is where React actually touches the Real DOM. It’s fast, synchronous, and happens in one go. 🧠 The Mental Model Shift In modern React, stop thinking about "methods" and start thinking about Synchronization. useEffect isn't just a lifecycle hook—it’s a tool to synchronize your component with an external system (the API, the DOM, or a Window event). Are you building for performance or just for functionality? Let's discuss in the comments! 👇 #ReactJS #WebDevelopment #FrontendEngineers #CodingTips #JavaScript #SoftwareArchitecture

🧠 Day 24 — Optional Chaining (?.) & Nullish Coalescing (??) Tired of errors like “Cannot read property of undefined”? 🤔 These two operators will save you 🚀 --- ⚡ 1. Optional Chaining ?. 👉 Safely access nested properties const user = { profile: { name: "John" } }; console.log(user.profile?.name); // John console.log(user.address?.city); // undefined (no error) 👉 Stops execution if value is null or undefined --- ⚡ 2. Nullish Coalescing ?? 👉 Provides a default value only if value is null or undefined const name = null; console.log(name ?? "Guest"); // Guest --- ⚠️ Difference from || console.log(0 || "Default"); // "Default" ❌ console.log(0 ?? "Default"); // 0 ✅ 👉 || treats falsy values (0, "", false) as false 👉 ?? only checks null or undefined --- 🚀 Why it matters ✔ Prevents runtime errors ✔ Cleaner and safer code ✔ Widely used in APIs & React apps --- 💡 One-line takeaway: 👉 “Use ?. to safely access, ?? to safely default.” --- Once you start using these, your code becomes much more robust. #JavaScript #ES6 #OptionalChaining #WebDevelopment #Frontend #100DaysOfCode 🚀

🚨 Most React performance issues are self-inflicted. Not because React is slow. But because we don’t realize how often our code runs. I learned this the hard way. Everything looked fine in development. But with real data → UI started lagging. No errors. No warnings. Just poor experience. 🔍 The issue? Unnecessary re-renders + recalculations happening on every render. 💡 Fix wasn’t complex: → Memoizing expensive calculations → Stabilizing function references → Avoiding derived state where possible ⚡ Result: Smooth UI. Better performance. Happier users. 🧠 Biggest shift for me: I stopped asking “Is my code correct?” and started asking 👉 “How many times is my code running?” That question alone changes how you write React. What’s one performance issue you’ve faced recently? #ReactJS #FrontendDeveloper #WebPerformance #JavaScript #TypeScript #SoftwareEngineering #Coding

𝗟𝗲𝘁’𝘀 𝘁𝗮𝗹𝗸 𝗮 𝗹𝗶𝘁𝘁𝗹𝗲 𝗯𝗶𝘁 𝗮𝗯𝗼𝘂𝘁 𝗡𝗼𝗱𝗲.𝗷𝘀! 𝐓𝐨𝐩𝐢𝐜 𝟏: 𝐓𝐡𝐞 𝐍𝐨𝐝𝐞.𝐣𝐬 𝐄𝐯𝐞𝐧𝐭 𝐋𝐨𝐨𝐩 It’s a meticulously ordered cycle of 6 steps - and most developers have never seen the part that goes between each one. ⚙️ 𝘛𝘩𝘦 6 𝘚𝘵𝘦𝘱𝘴: 1️⃣ 𝘛𝘪𝘮𝘦𝘳𝘴: Recalls setTimeout / setInterval whose delay has passed 2️⃣ 𝘈𝘸𝘢𝘪𝘵𝘪𝘯𝘨 callbacks: Recalls I/O errors that were rejected from the previous iteration 3️⃣ 𝘗𝘰𝘭𝘭𝘪𝘯𝘨: Retrieves new I/O events. This is where Node.js waits when idle. 4️⃣ 𝘊𝘩𝘦𝘤𝘬: setImmediate callbacks, always after Poll 5️⃣ 𝘊𝘭𝘰𝘴𝘦 𝘊𝘢𝘭𝘭𝘣𝘢𝘤𝘬𝘴: socket.on('close'), cleanup handlers 💠The hidden layer: microtasks Between each step, before the loop progresses, Node.js completely empties the microtask queue. Two subqueues, processed in exact order: ➡️ process.nextTick() callbacks - always first ➡️ Promise resolution callbacks - second This means that microtasks have a higher priority than any step of the Event Loop. 📌 𝘛𝘩𝘦 𝘳𝘶𝘭𝘦𝘴 𝘰𝘧 𝘵𝘩𝘶𝘮𝘣: ➡️ process.nextTick() is fired before Promises, even if Promise resolved first. ➡️ setImmediate() is always fired after I/O callbacks in the same iteration. ➡️ The order of setTimeout(fn, 0) and setImmediate() is not deterministic outside of I/O callbacks. ➡️ Never use nextTick() recursively in production code. The event loop is why Node.js can handle thousands of simultaneous connections on a single thread. Controlling its execution order is the difference between writing asynchronous code and understanding it. #nodejs #javascript #backend #eventloop #softwareengineering #webdevelopment