Stop Using Index as React Key: Risks and Best Practices

You call setState. You immediately log the value. It prints the old state. React is broken? No. Most developers misunderstand how React state updates actually work. React state isn’t truly asynchronous. It’s batched. It’s scheduled. And it re-renders after your function finishes. That’s why it feels async. I broke it down visually — step by step 👇 (With diagrams + interview explanation) https://lnkd.in/eHbnJ63p React Confusion Series — Part 1 #react #javascript #frontend #webdevelopment

59 tests. 0 failures. There’s no feeling quite like watching a terminal turn green after weeks of architectural heavy lifting. I just wrapped up my final React project for The Odin Project, and it was a deep dive into what "production-ready" actually looks like. It wasn’t just about making a shopping cart that works. It was about building a system that is predictable and scalable. A few things I prioritized: • 𝗦𝘁𝗮𝘁𝗲 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁: Using Reducers and Context to keep data flowing without the "prop-drilling" headache. • 𝗥𝗲𝘀𝗶𝗹𝗶𝗲𝗻𝘁 𝗙𝗲𝘁𝗰𝗵𝗶𝗻𝗴: Implementing custom logic for data fetching to mimic TanStack Query using vanilla fetch. • 𝗧𝗲𝘀𝘁𝗶𝗻𝗴: Using Vitest and React Testing Library (RTL) to ensure every component, from the quantity input to the checkout logic, actually does what it’s supposed to. The UI is heavily inspired by Google’s Material You theme. I wanted something that felt modern, fluid, and accessible. Building this reminded me that while the "fun" part is the UI, the "pro" part is the logic that sits underneath it. Huge thanks to the TOP community for the push. On to the next challenge. #ReactJS #TheOdinProject #WebDevelopment #SoftwareTesting #Javascript

In React, I keep seeing this idea: “replace state with refs for better performance.” Refs don’t solve performance problems. ✅ useRef updates do not trigger a re-render. So the moment you need to display that value or react to it in the UI, you end up adding extra code to force a re-render (proxy state, events, hacks…). Result: more complexity, harder debugging, and often worse performance. Real React performance comes from: 1. Use selectors to subscribe to only what you need Redux / Zustand / Jotai / React Query / Context… doesn’t matter. The goal is the same: each component should read the smallest slice of data it needs. → fewer unnecessary re-renders, more predictable UI. 2. Minimize heavy components on the page Classic example: a list with edit modals. ❌ Bad: one modal per row 100 rows = 100 modals mounted More memory, more listeners, more props updates → performance pain. ✅ Better: a single modal Keep a selectedItemId (or selected item) and update the modal content based on selection. Cleaner code, scalable, and much faster. Performance isn’t about avoiding renders at all costs. It’s about controlling what re-renders, when, and why. #react #frontend #performance #javascript #webdev

React patterns that often cause subtle bugs Some React code looks completely fine at first glance. But over time, certain patterns can cause confusing bugs or make the UI harder to reason about. Here are a few I try to watch out for 👇 1️⃣ Copying props into state const [user, setUser] = useState(props.user) This creates two sources of truth. If the parent updates props.user, the state inside the component may not update the way you expect. That’s how UI gets out of sync. 2️⃣ Storing values that can be derived Instead of storing: const [fullName, setFullName] = useState("") Sometimes you can simply calculate: const fullName = `${firstName} ${lastName}` Derived state often adds extra logic and unnecessary re-renders. 3️⃣ Lifting state higher than necessary Lifting state up is helpful when multiple components need the same data. But lifting it too high can lead to: • unnecessary re-renders • harder state management • tightly coupled components Sometimes the better answer is to keep state closer to where it is used. 4️⃣ Large components that do too many things When one component handles too much, it becomes harder to: • understand • test • debug Smaller, focused components are usually easier to work with. 5️⃣ Overusing useEffect A lot of logic ends up in useEffect when it does not need to be there. If something can be calculated directly from props or state, it often does not need an effect. None of these patterns are always wrong. But I’ve noticed many React bugs come from state being: • duplicated • misplaced • harder to reason about Keeping one clear source of truth usually makes the UI much easier to understand. What React pattern do you see most often that leads to bugs? #reactjs #frontend #javascript #webdevelopment #softwareengineering #reactdeveloper #reacthooks #frontendengineering

A small React bug taught me a big lesson. 👇 Recently, I was working on a feature that had filters with Autocomplete using React Hook Form. At first, everything seemed to work perfectly. But there was one problem. Whenever users changed the page in the pagination, the selected filter kept resetting. From the user's point of view, it looked like the system was forgetting their input, which can be pretty frustrating. So I started digging into the issue. After some debugging, I realized the problem wasn’t really the UI component. The real issue was how the state was being synchronized between the form, the component, and the pagination updates. Every time the component re-rendered during pagination, the form state wasn’t restoring the selected value properly. Here’s what fixed it: ✅ Synced the filter values with URL query parameters ✅ Restored the values using React Hook Form’s setValue ✅ Made sure pagination updates didn’t overwrite the existing form state After that, the filters stayed consistent across navigation and pagination. One small bug, but a good reminder: Most frontend bugs are not actually UI problems. They’re state management problems. #ReactJS #FrontendDevelopment #WebDevelopment #Debugging

Zustand vs Redux vs Context After using all three in production, here is the honest breakdown. -> Context API Built into React. Zero bundle size. No library to install. Use it for: theme, authentication state, and simple global state that rarely changes. Avoid it for: frequently updating state or large state trees. Context re-renders every consumer when the value changes. In complex UIs this becomes a performance problem fast. Reality check: re-render issues are real and will bite you in production. -> Redux with Redux Toolkit The industry standard for complex state management. About 11KB with RTK. Use it for: large teams, complex state logic, applications where time-travel debugging and strict unidirectional data flow provide genuine value. Avoid it for: small to medium apps and rapid prototyping. The structure Redux enforces is valuable at scale but is overhead for simpler applications. Reality check: Redux Toolkit removed most of the original boilerplate pain. But it is still Redux. The mental model and conventions are non-trivial. -> Zustand Minimal. About 1KB. Simple API that just works. Use it for: most React applications honestly. It handles global state with almost no setup, no boilerplate, and no re-render traps. Avoid it for: teams already deeply invested in Redux with established patterns that work. Reality check: the API is genuinely simple. Store creation, state access, state updates — all in a few lines. The conclusion from using all three in production: Context for state that rarely changes. Redux when you need time-travel debugging and team-scale conventions. Zustand as the default for new projects. Not because Redux is bad. Because Zustand is usually enough. The best state management solution is always the simplest one that solves your actual problem. What is your current default state management choice and why? #React #Zustand #Redux #StateManagement #FrontendDevelopment #JavaScript #WebDevelopment

⚛️ Preserving vs Resetting State in React - Case 1 : You hide the form. You show it again. And… the input value is gone. Why? Because React didn’t 'hide' the component. It removed it from the tree. And when a component disappears from the tree, => its state disappears with it. Now compare with - Case 2: This time, the state is preserved. Why?? Because the component never left the tree. Same position → same identity → same state. The rule is simple: React preserves state as long as the component stays at the same position in the tree. Change the position? → Reset. Change the key? → Reset. Remove it? → Reset. Same element, same spot? → Preserved. Most bugs around forms, modals, tabs, and conditionals are not about hooks. They’re about identity !! If you understand how React matches elements during reconciliation, you control when state lives — and when it dies. If you build complex UIs, mastering this changes everything ⚛️ #react #hooks #reconciliation #FrontendDevelopment #SoftwareEngineering #JavaScript

🚀 Day 4/30 — Lists & Keys in React Continuing my 30 Days × 30 React Projects series, today’s focus was on understanding how React efficiently renders lists using keys. This project emphasizes how dynamic data is rendered in UI and why proper key usage is critical for performance and correctness. Key concepts covered: ➡️ Rendering lists using map() ➡️ Assigning unique keys to elements ➡️ Understanding React’s reconciliation process ➡️ Preventing unnecessary re-renders ➡️ Maintaining stable component identity Keys are not just a syntax requirement — they directly influence how React tracks and updates components in the Virtual DOM. Using improper keys (like array indices in unstable lists) can introduce subtle UI bugs and performance issues. Getting this right early prevents bigger problems later. 🔗 GitHub Repository: https://lnkd.in/duerXpu4 Why this matters long term: ➡️ Strengthens understanding of React reconciliation ➡️ Improves performance-aware thinking ➡️ Encourages clean dynamic rendering practices ➡️ Builds production-ready habits from the start Still focusing on fundamentals. Still building daily. ✅ More projects coming. ✅ Consistency over complexity. #ReactJS #FrontendDevelopment #WebDevelopment #LearningInPublic #JavaScript #ReactBasics #30DaysOfCode #FrontendEngineer

🚀 My component rendered 17 times… for a single click. Do you know why? Was debugging a product listing page recently. Changed one filter… and React decided to re-render the list 17 times. UI wasn’t broken, but it felt slightly off. ~200–300ms delay on interaction. Not huge… but noticeable. Checked profiler → turns out a lot of unnecessary work. Main issues: • Parent state change → whole list re-render • Inline onClick → new function every time • Some data transformations running again and again • No memoization anywhere One example 👇 <ProductCard onClick={() => handleClick(id)} /> This looks harmless, but it creates a new function on every render. So React thinks props changed → re-render. ✅ Fixed it with useCallback. Another thing I noticed: Even though filtering was handled by API, we were still doing small stuff on frontend like: const enriched = products.map(...) Individually cheap… but with multiple re-renders, it adds up. ✅ Wrapped it in useMemo. ✅ Also wrapped list items with React.memo ✅ After fixes: • 17 renders → 3 • ~150ms → ~35ms UI feels much smoother now (especially on slower devices) Takeaway: Most of the time, performance issues are not “big problems” It’s small things… happening multiple times. If you haven’t checked your components in React Profiler yet, do it once. You might be surprised 😄 #reactjs #javascript #frontend #webperformance #optimization

Why I stopped putting API calls inside my React components (and what I do instead) Let’s be real: when you’re first learning React, it’s tempting to just throw a fetch() inside a useEffect and call it a day. It works! But then your app grows.📈 Suddenly, you’re prop-drilling data five levels deep, your components are 500 lines long, and fixing one small bug feels like playing Jenga. I’ve started moving toward a 4-Layer Architecture, and honestly, it’s like giving your codebase a deep breath of fresh air. Here’s how I break it down: 1️⃣ The UI Layer: This is the "face." It only cares about JSX and CSS. No complex logic, no fetching. Just: "Here is a button, tell me what to show." 2️⃣ The Hook Layer: This is the "brain." It handles the logic. It talks to the state and the API and gives the UI exactly what it needs (like isLoading or data). 3️⃣ The Context Layer: The "memory." This is our single source of truth for things like Auth or Themes, so we don't have to pass props through 10 components. 4️⃣ The API Layer: The "messenger." It handles the dirty work—headers, base URLs, and error handling. If the backend changes, I only change code here. The result? ✅ Faster debugging (you know exactly where to look). ✅ Easier testing. ✅ A UI that doesn't break just because a backend dev changed a key name. It’s about building something that’s easy to maintain six months from now, not just something that works today. Detailed Tech Notes : https://lnkd.in/gSDP2h8f How are you guys structuring your frontend lately? Any patterns you're loving? Let's chat in the comments! 👇 #ReactJS #WebDevelopment #CleanCode #SoftwareArchitecture #Frontend #ProgrammingTips