Common React Mistake: Using Index as Key

A Common React Mistake We Make as React/JS Developers. I have found that one small mistake in React can create very weird UI bugs while working on using Index as Key in a List. Let me explain with an example. Check this code for displaying a list - {items.map((item, index) => ( <div key={index}>{item.name}</div> ))} The above piece of code is something we commonly use. It looks fine, but sometimes it can be dangerous - and we often ignore it. Let me explain why. At first, everything looks fine. No errors. But the real problem starts when the list changes - during insertion or deletion. Imagine the list is: 0 - React 1 - Node 2 - Next Now suppose we delete "React" (index 0). Hence, the new list becomes: 0 - Node 1 - Next But here is the problem. React thinks: Item with key 0 still exists. Item with key 1 still exists. Because the keys (0 and 1) are still there. So instead of understanding: "React was removed" React thinks: "React became Node" "Node became Next" It reuses the old components and just changes the data. Result: Wrong component updates. How can we fix it? Using a stable id as the key. {items.map((item) => ( <div key={item.id}>{item.name}</div> ))} Now imagine: id: 101 - React id: 102 - Node id: 103 - Next We delete React (101). React sees: 101 is gone 102 still exists 103 still exists So, it removes that exact component. Share your thoughts in the comment box. hashtag #ReactJS hashtag #JavaScript hashtag #WebDevelopment hashtag #FrontendDevelopment hashtag #ReactDeveloper hashtag #CodingMistakes hashtag #SoftwareDevelopment hashtag #LearnToCode hashtag #Programming

💡 Small React/Next.js Tip I Learned Today While working on a Next.js project, I needed to create a reusable configCreator utility. Example: const configCreator = () => ({ id: "id", label: "Option 1", icon: <Info size={12} /> }); Since I wanted to store it inside a utility file and reuse it across multiple places, I ran into an interesting problem. Because I was using a JSX component (<Info />) inside the util file, I had to change the file extension from .ts → .tsx. The issue was that this file already contained many other utility functions, so just to add one function using JSX, the whole file needed to become .tsx. The Better Approach I Found Instead of JSX, I used React.createElement. const configCreator = () => ({ id: "id", label: "Option 1", icon: React.createElement(Info, { size: 12 }) }); This allowed me to keep the file as .ts, since React.createElement doesn't require JSX. Why This Is Useful ✔ Keeps utility files clean and framework-agnostic ✔ Avoids unnecessary .tsx conversions ✔ Makes configs easier to reuse across the codebase Curious to hear from other React developers 👇 How would you tackle this in your React codebase? Keep it .tsx? Use React.createElement? Or structure the config differently? #React #NextJS #FrontendDevelopment #JavaScript #WebDevelopment

📌 JavaScript works… until it doesn’t. That’s the moment I truly understood the value of TypeScript in React. If you’re building React apps and want fewer bugs, better readability, and safer refactoring, here’s how TypeScript fits into everyday React development 👇  1.Functional Components type Props = {  title: string;  isActive?: boolean; }; const Header: React.FC<Props> = ({ title, isActive = false }) => {  return <h1>{isActive ? title : "Inactive"}</h1>; }; 2.Props with Strong Typing type ButtonProps = {  label: string;  onClick: () => void; }; const Button = ({ label, onClick }: ButtonProps) => (  <button onClick={onClick}>{label}</button> ); 3.State with Type Safety const [count, setCount] = useState<number>(0); const [user, setUser] = useState<{ name: string; age: number } | null>(null); 4. Event Handlers  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {  console.log(e.target.value); }; For more Understanding watch following videos: -FreeCode Camp : https://lnkd.in/dhBQnVsD -PedroTech : https://lnkd.in/dbnKP-vD #React #TypeScript #FrontendDevelopment #JavaScript #WebDevelopment #ReactJS #LearningInPublic

How I Understood React State Updates One day I wrote this small React code: import { useState } from "react"; export default function App() { const [count, setCount] = useState(0);   const handleClick = () => {    setCount(count + 1);    setCount(count + 1);    setCount(count + 1);    console.log(count);   };   console.log(count);   return (    <div>     <h1>{count}</h1>     <button onClick={handleClick}>Increment</button>    </div>   ); } And I thought something very simple would happen. I clicked the button and expected: 0 → 3 Because I increased the count three times. But React surprised me. The value became: 0 → 1 And I asked myself: 👉 Why didn't it increase to 3? So I stopped thinking like a JavaScript developer… and started thinking like React. What React actually sees React batches state updates. All three lines read the same old value. setCount(count + 1); setCount(count + 1); setCount(count + 1); • For React, this becomes: setCount(1) setCount(1) setCount(1) • So the final result is simply: 1 Not 3. • The correct way When the new state depends on the previous state, React gives us a better pattern: setCount(prev => prev + 1); setCount(prev => prev + 1); setCount(prev => prev + 1); Now React updates step by step. Result: 0 → 3 The lesson I learned State updates in React are not immediate. React schedules them and processes them together. So whenever state depends on the previous value, I now ask myself: 👉 Should I use the functional update? Small detail. Big difference. Still learning React the human way. 🚀 #JavaScript #FrontendDevelopment #LearningInPublic #CleanCode #ReactJS #useState #FrontendDevelopment #LearningInPublic #JavaScript #WebDevelopment #DeveloperJourney #ReactHook

How I Understood ActivityHook in React(Activity Hook) One day I built a simple toggle in React: 👉 Switch between Home and User Form At first, I wrote it the usual way: </>Jsx {showHome ? <Home /> : <UserForm />} And it worked. But there was a problem. Every time I switched: • Form inputs got cleared 😩 • State was lost • Everything reset 🧠 Before (without Activity) React thinks like this: 👉 “Remove one component, mount the other.” So switching means: • Destroy → Create again • State = gone 💡 Then I discovered Activity </>Jsx import { useState, Activity } from "react"; export default function App() { const [showHome, setShowHome] = useState(true);   return (    <>     <button onClick={() => setShowHome(true)}>Home</button>     <button onClick={() => setShowHome(false)}>User Form</button>     <Activity mode={showHome ? "visible" : "hidden"}>      <Home />     </Activity> <Activity mode={!showHome ? "visible" : "hidden"}>      <UserForm />     </Activity>   </>  ); } 🧠 After (with Activity) React now thinks like this: 👉 “Keep both components alive… just hide one.” So switching means: • No unmount • No reset • State stays intact ✅ 🔥 Real-life example It’s like switching tabs on your phone: • App doesn’t close • It just goes to background 💡 The lesson I learned Before: 👉 Render vs Unmount After: 👉 Visible vs Hidden That small shift changed everything. Now I don’t ask: 👉 “Should I render this?” I ask: 👉 “Should I keep it alive?” Still learning React the human way. 🚀 #JavaScript #FrontendDevelopment #LearningInPublic #CleanCode #ReactJS #useEffect #useMemo #useCallback #FrontendDevelopment #LearningInPublic #JavaScript #WebDevelopment #DeveloperJourney #ReactHook #React19  #ActivityHook

Closures in React: powerful concept, subtle bugs Closures are a fundamental concept in JavaScript. They also explain some of the most confusing bugs that appear in React applications. A closure happens when a function captures variables from the scope where it was created. Those variables remain accessible even after the outer function has finished executing. In React, every render creates a new scope. When a function is defined inside a component, it closes over the values from that specific render. This becomes important when using hooks like useMemo and useCallback. If the dependency array is incomplete, the function may keep referencing outdated values from a previous render. Common situations where this appears: • useCallback capturing an old state value • useMemo computing something with stale props • event handlers referencing outdated variables The result is what developers often call a stale closure. The UI updates, but the function is still working with old data. This is why dependency arrays matter. They are not only about performance. They ensure the function is recreated when its captured values change. A good rule of thumb is simple. If a value is used inside useMemo or useCallback, it usually belongs in the dependency array. I added a small example in the comments showing how a stale closure happens in practice and how to fix it.

🚀 Stop Using "Index" as a Key in Your Lists! Here’s Why. Ever wondered why React (or any modern UI framework) screams at you when you forget to add a key to a list? It’s not just a "coding rule"—it’s the secret sauce for performance and bug-free apps. Let’s break it down. 🧵 🔑 What is a "Key" anyway? Think of a list of items in your code like a coat check at a party. Without a tag (key), the attendant (React) has to look at every single coat to find yours. With a tag, they know exactly which one is yours instantly. A key is a unique identity. It helps the framework track which item was added, changed, or removed without re-rendering the entire list. 🚫 The "Index" Trap: Why key={index} is a bad idea We’ve all done it: items.map((item, index) => <li key={index}>...</li>). It stops the warning, but it creates a hidden bug. Here is the problem: Imagine you have a list of names: [0: "Alice", 1: "Bob", 2: "Charlie"]. If you delete "Alice," the list becomes: [0: "Bob", 1: "Charlie"]. Wait, what happened? "Bob" used to be index 1, but now he is index 0. React thinks index 0 just changed its text from "Alice" to "Bob." If you had a checkbox or a text input next to Alice, it might stay at index 0 and suddenly look like it belongs to Bob! Using an index is like identifying your friends by their "spot in line" rather than their "name." If someone leaves the line, everyone’s identity changes! ✅ The Golden Rule Always use a stable, unique ID from your data (like user.id or product.uuid). Better Performance: React only updates what actually changed. No UI Glitches: Your checkboxes, inputs, and animations stay attached to the right item. Happier Users: Smooth, fast, and bug-free interfaces. Keep your keys unique, keep your UI stable! 💻✨ #WebDevelopment #ReactJS #NextJS #Frontend #CodingTips #CleanCode #JavaScript

Most React developers have written this at some point: ```js useEffect(() => { fetchUserData(userId); }, []); ``` It works — until it doesn't. The problem? You're telling React "run this once" but your effect actually depends on userId. When userId changes, your UI goes stale and you get bugs that are incredibly hard to trace. The fix is simple: ```js useEffect(() => { fetchUserData(userId); }, [userId]); ``` Always ask yourself: "What values does this effect read from the component scope?" Every one of them belongs in the dependency array. ESLint's exhaustive-deps rule will catch these automatically. If you're not using it, turn it on today. Small habits like this are what separate good developers from great ones. #ReactJS #JavaScript #WebDevelopment #Frontend

🔁 useCallback in React.js – Small Hook, Big Performance Impact When building React applications, unnecessary re-renders can silently affect performance. One hook that helps control this is useCallback. What is useCallback? useCallback is a React hook that memoizes a function, meaning React will reuse the same function reference between renders unless its dependencies change. This is especially useful when passing functions to child components, because React normally creates a new function on every render. That can cause child components to re-render even when nothing actually changed. Example: import { useState, useCallback } from "react"; function Counter() { const [count, setCount] = useState(0); const handleClick = useCallback(() => { console.log("Button clicked"); }, []); return ( <div> <button onClick={handleClick}>Click Me</button> <p>{count}</p> </div> ); } In this example, handleClick keeps the same function reference across renders because of useCallback. Why it matters: ✔ Prevents unnecessary re-renders ✔ Improves performance in optimized components ✔ Useful with React.memo When to use it? Use useCallback when: Passing functions to memoized components Working with expensive re-renders Optimizing large React applications ⚠️ But remember: Not every function needs useCallback. Overusing it can actually make code harder to maintain without real performance benefits. 💡 Understanding hooks like useCallback helps in writing cleaner and more optimized React applications. #ReactJS #WebDevelopment #JavaScript #FrontendDevelopment #ReactHooks #Coding

React developers: stop mutating state. Use the spread operator instead. Wrong (mutates): user.role = 'admin' setUser(user) // React won't re-render! Right (creates new object): setUser({ ...user, role: 'admin' }) More React patterns: Add to array: setItems([...items, newItem]) Remove from array: setItems(items.filter(item => item.id !== removeId)) Update array item: setItems(items.map(item =>   item.id === targetId    ? { ...item, completed: true }   : item )) Merge state: setForm({ ...form, ...updates }) Nested state update: setUser({  ...user,  settings: {   ...user.settings,   theme: 'dark'  } }) Why spread over mutation: → React detects changes properly → Prevents stale closure bugs → Enables time-travel debugging → Makes state updates predictable → Follows immutability principles In React, immutability isn't optional. The spread operator makes it easy. #React #JavaScript #WebDevelopment #FrontendDev #ReactJS