Stories by Rama Jha on Medium

useEffect Isn’t Magic: Side Effects, Dependencies, and Cleanup Explained

Rama Jha — Mon, 15 Dec 2025 12:02:24 GMT

Last month, I was debugging a partner’s React component and found useEffect firing the same API call three times on mount. Their response? "I don't know—it just does that." We spent ten minutes digging, and it turned out React 18's StrictMode was double-invoking their effect, plus they had no cleanup function. No magic there—just a misunderstanding waiting to happen.

Here’s the thing: useEffect gets blamed a lot. Developers call it confusing, unpredictable, even broken. But it's not the hook that's the problem—it's usually the mental model. Today, we're fixing that.

What You’ll Learn

After reading this post, you’ll be able to:

Explain what side effects are and recognize when you actually need useEffect (hint: not every time).
Write a proper effect with the right dependency array pattern and understand why dependencies matter.
Create and use cleanup functions to prevent memory leaks, infinite loops, and double-fetches.
Understand React 18’s StrictMode behavior and why your effect might run twice in development (and what to do about it).
Debug common gotchas like infinite loops, missing dependencies, and race conditions.

Prerequisites

You should already understand React functional components, basic hooks like useState, and how JavaScript closures work (especially if variables are captured "stale"). If you're shaky on that, skim the React docs on closures first—it'll make this much clearer.

What’s a Side Effect, Actually?

Think about what your component does. Usually, it renders JSX: it takes props and state, runs some logic, and returns UI. That’s pure — same inputs, same output every time. No surprises.

But real apps need to do messy things: fetch data from an API, listen to window resize events, update the document title, set up a timer. These things happen outside your component’s render function. They’re called side effects.

Here’s a bad way to handle them:

function Counter() {
  const [count, setCount] = useState(0);
  
  // DON'T do this
  document.title = `Count: ${count}`;
  
  return (
    
      Count: {count}

      
    

  );
}

Why is this bad? Because you’re updating the document title every single time the component renders. React can re-render for all kinds of reasons — a parent prop changed, another state variable shifted, whatever. Each render updates the title, which is wasteful and weird.

useEffect is React's way of saying: "Hey, do this side effect after rendering, and only when I tell you to."

The Syntax (It’s Simpler Than You Think)

useEffect(() => {
  // This code runs AFTER the component renders
  // Put your side effect here
  console.log('Component rendered!');
}, [/* dependency array */]);

That’s it. Two arguments: a function and an array.

The Three Patterns: When Does Your Effect Run?

This is where beginners get lost. Let’s be concrete.

Pattern 1: Empty Dependency Array []

useEffect(() => {
  console.log('This runs ONCE, after the first render');
  document.title = 'Welcome!';
}, []);

When it runs: Once, right after your component mounts. Never again, even if state or props change.

Real use: Fetch initial data, set up an event listener, initialize a timer that shouldn’t restart.

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  
  useEffect(() => {
    // Fetch the user once, on mount
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => setUser(data));
  }, []); // Only run on mount
  
  return user ? {user.name}
 : Loading...
;
}

The gotcha: If userId changes later, this effect won't re-run. Your component will keep showing the old user. This is actually a bug in the example above. We'll fix it in a moment.

Pattern 2: Dependency Array With Values [value]

useEffect(() => {
  console.log(`Dependency changed to: ${value}`);
}, [value]);

When it runs: After mount, and again whenever value changes.

Real use: When a prop or state change should trigger a side effect, like fetching new data.

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  
  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => setUser(data));
  }, [userId]); // Re-run when userId changes
  
  return user ? {user.name}
 : Loading...
;
}

Now if userId changes, the effect re-runs and fetches the new user. Problem solved.

You can include multiple dependencies:

useEffect(() => {
  console.log(`Search: ${query}, Page: ${page}`);
  // Fetch results based on query AND page
}, [query, page]); // Both are dependencies

Real talk: Missing a dependency is one of the top mistakes. The ESLint rule eslint-plugin-react-hooks will yell at you if you forget one. Listen to it.

Pattern 3: No Dependency Array (Don’t Do This)

useEffect(() => {
  console.log('This runs after EVERY render');
});

When it runs: After every render.

When you’d use it: Almost never. This is usually a mistake. It defeats the whole purpose of useEffect and can tank your app's performance.

Cleanup Functions: The Secret Weapon

Here’s where React 18 changes everything. In development (with StrictMode on), React deliberately unmounts and remounts your component to catch bugs. If your effect doesn’t clean up after itself, you’ll get problems: duplicate API calls, memory leaks, event listeners that never get removed.

A cleanup function is just a function you return from your effect:

useEffect(() => {
  console.log('Effect running');
  
  // Return a cleanup function
  return () => {
    console.log('Cleaning up!');
  };
}, []);

The cleanup function runs right before:

The component unmounts, or
The effect re-runs (on dependency changes)

Real example: Event listener

function WindowSize() {
  const [width, setWidth] = useState(window.innerWidth);
  
  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener('resize', handleResize);
    
    // Cleanup: remove the listener before the next effect or unmount
    return () => {
      window.removeEventListener('resize', handleResize);
    };
  }, []);
  
  return Window width: {width}px
;
}

If you don’t clean up, every time the component re-mounts (happens a lot in StrictMode), you add another event listener. Soon you’ve got 10 listeners firing on every resize. Ouch.

Real example: Timer

function Countdown() {
  const [seconds, setSeconds] = useState(10);
  
  useEffect(() => {
    const interval = setInterval(() => {
      setSeconds(s => s - 1);
    }, 1000);
    
    // Clean up the interval
    return () => clearInterval(interval);
  }, []);
  
  return {seconds}s left
;
}

Without the cleanup, old intervals keep running even after unmount, and new ones pile up.

The Hands-On Task: Update the Page Title

Let’s tie this together with the task from the schedule. Create a component that updates document.title based on a counter:

import { useState, useEffect } from 'react';

function PageTitle() {
  const [count, setCount] = useState(0);
  
  useEffect(() => {
    // This side effect runs whenever count changes
    document.title = `Count: ${count}`;
  }, [count]); // Dependency: count
  
  return (
    
      Current count: {count}

      
    

  );
}
export default PageTitle;

Try it:

Click the button a few times.
Watch the browser tab title change.
Open React DevTools, go to the Profiler, and trigger a re-render. See how document.title updates without extra renders.

Gotcha moment: What if you accidentally leave out the dependency array?

useEffect(() => {
  document.title = `Count: ${count}`;
}); // No dependency array

Now the effect runs every render. Click once, title updates. Great. Click again, renders again, title updates again. Seems fine until you realize React might trigger re-renders for other reasons (parent changes, other state shifts), and every single time, you’re re-setting the title. Wasteful. Include the dependency array.

React 18 StrictMode: Why Your Effect Runs Twice (And It’s Okay)

In development, if you wrap your app with , React intentionally mounts, unmounts, and remounts your component. It looks like this:

Component mounts → effect runs
Effect cleanup runs
Component unmounts
Component remounts → effect runs again
Effect cleanup runs

This happens only in development and only in StrictMode. It’s React’s way of forcing you to write proper cleanup functions. If your app breaks during this double-invoke, you’ve got a bug.

Example of a broken effect in StrictMode:

useEffect(() => {
  let count = 0;
  const interval = setInterval(() => {
    count++;
    console.log(count); // Logs 1, then on the next cycle, logs 1 again
  }, 1000);
  
  // Oops, no cleanup!
}, []);

In StrictMode:

First mount: interval starts, logs 1, 2, 3…
Unmount (cleanup didn’t run, so interval still exists)
Remount: another interval starts
Now two intervals are running, and logs get weird

Fix: Add the cleanup function.

useEffect(() => {
  let count = 0;
  const interval = setInterval(() => {
    count++;
    console.log(count);
  }, 1000);
  
  return () => clearInterval(interval); // Cleanup!
}, []);

Now:

Mount: interval starts
Unmount: cleanup clears it
Remount: fresh interval starts
Clean, predictable behavior

Here’s my honest take: StrictMode feels annoying at first. “Why is my effect running twice?” But it catches real bugs that would otherwise only show up after deploy. Embrace it.

Common Gotcha: The Infinite Loop

One of the scariest bugs with useEffect is the infinite re-render loop. Here's how it happens:

function BadExample() {
  const [data, setData] = useState([]);
  
  useEffect(() => {
    setData([1, 2, 3]); // Sets state
    // But data is a dependency...?
  }, [data]); // When state updates, effect re-runs, calls setData again, ...
}

Effect runs → sets data → data changes → effect runs again → infinite loop → browser slows to a crawl.

The fix: Don’t include state variables in the dependency array if you’re updating them in the effect.

useEffect(() => {
  setData([1, 2, 3]);
}, []); // Empty array: run once, that's it

Another common cause:

function DetailsPage({ user }) {
  useEffect(() => {
    fetch(`/api/users/${user}`);
  }, [user]); // Fine so far
}

// Called from parent like this:
 // DANGER: new object every render!

Each render, a new user object gets created, React sees it as "changed" (different reference), and the effect re-runs. If the parent re-renders often, the effect runs constantly.

Fix: Memoize the object or pass just the ID.

// Better: pass just the ID


// Or memoize the object
const user = useMemo(() => ({ id: 123 }), []);

Fetching Data: The Right Way

Data fetching is where useEffect really shines—and where it breaks if you're not careful.

Here’s a solid pattern using AbortController for cleanup:

function UserList() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);
  
  useEffect(() => {
    // Create a controller to cancel the fetch if needed
    const controller = new AbortController();
    
    (async () => {
      try {
        const response = await fetch('/api/users', {
          signal: controller.signal, // Attach the signal
        });
        if (!response.ok) throw new Error('Failed to fetch');
        const data = await response.json();
        setUsers(data);
      } catch (err) {
        // Only update state if it wasn't aborted
        if (err.name !== 'AbortError') {
          setError(err.message);
        }
      } finally {
        setLoading(false);
      }
    })();
    
    // Cleanup: abort the fetch if component unmounts
    return () => controller.abort();
  }, []);
  
  if (loading) return Loading...
;
  if (error) return Error: {error}
;
  return (
    
      {users.map(user => (
        {user.name}

      ))}
    

  );
}

Why AbortController? If the user navigates away before the fetch completes, you want to cancel the request and avoid updating unmounted state (which causes a memory leak warning).

Why check for AbortError? When you abort, the fetch throws an error. We catch it but don't show an error message to the user—they left the page anyway.

One More Thing: When NOT to Use useEffect

React’s official docs have a section called “You Might Not Need an Effect,” and it’s worth reading. Here are some cases where beginners use useEffect but shouldn't:

1. Deriving state from props

// Don't do this
function User({ firstName, lastName }) {
  const [fullName, setFullName] = useState('');
  
  useEffect(() => {
    setFullName(`${firstName} ${lastName}`);
  }, [firstName, lastName]);
  
  return {fullName}
;
}

// Do this instead
function User({ firstName, lastName }) {
  const fullName = `${firstName} ${lastName}`;
  return {fullName}
;
}

If you can calculate a value from props or state, just calculate it during render. No effect needed.

2. Transforming props for event handlers

// Don't do this
function SearchBox({ onSearch }) {
  const [handler, setHandler] = useState(null);
  
  useEffect(() => {
    setHandler(() => (query) => onSearch(query.trim()));
  }, [onSearch]);
  
  return ;
}

// Do this instead
function SearchBox({ onSearch }) {
  return (
     onSearch(e.target.value.trim())} />
  );
}

No effect needed. Just handle it in the event handler.

The rule: If you can do it during render or in an event handler, do that instead of an effect. Effects are for syncing with external systems (APIs, timers, DOM listeners), not for transforming data.

Next Steps: What You Can Build

Spend the next hour building a weather widget that ties everything together:

Create a component that fetches weather data based on a city name.
Let the user type a city name in an input field.
On submit, update the dependency array and fetch new data.
Show loading and error states.
Add a cleanup function with AbortController.
Wrap your app in and verify the effect runs twice in development (it should, and everything should still work).

This will give you real practice with dependencies, cleanup, state updates, and debugging.

Wrapping Up

useEffect isn't magic—it's a tool for syncing your component with the outside world. The three key things to remember:

Dependency array matters. [] means "run once." [value] means "run when value changes." No array means "run every render" (almost always wrong).
Always clean up. Return a function that cancels timers, removes listeners, or aborts requests. React 18 will call it, and your app will thank you.
React 18’s double-invoke isn’t a bug; it’s a feature. It forces you to write correct code.

If you enjoyed this, check out my previous post on Moving State Up: Why Your Components Need a Common Parent — it connects directly to today’s lesson, because managing side effects often means thinking about where your state lives.

About the Author

I’m a React developer who spends way too much time thinking about why things work the way they do. I’ve written this handbook because I remember when ES6 syntax felt like a wall, and I want to save you that confusion. You can find me on X/Twitter, or GitHub. Drop a question anytime; I read every reply.

Mutating Arrays in React State Breaks Your UI (Here’s the Fix)

Rama Jha — Thu, 11 Dec 2025 12:02:26 GMT

Last month, I watched a junior developer debug a todo app for 20 minutes. Items added just fine, but when they edited an existing todo, the UI didn’t refresh. They’d updated the object in the array, called setState, and waited for React to re-render. Nothing happened. The culprit? A shallow mutation hiding in plain sight.

This is the exact moment immutability clicks for most React developers. Let’s dig into why arrays in state need special handling and how to avoid the bugs that come from mutating them.

Why React Doesn’t See Your Array Changes

React compares the old state object to the new one to decide whether to re-render. It does this efficiently with a shallow check: if the reference to the state variable didn’t change, React assumes nothing changed inside it.

Here’s the trap. JavaScript arrays are objects, and objects are mutable. You can do this:

const myArray = [1, 2, 3];

myArray[0] = 99;  // Changed the array, but didn't change the reference

The array still exists at the same memory address. React sees setState(myArray) and thinks, "That's the same array I already have. Nothing to re-render." But you changed the contents, so your UI lies to the user.

Let me show you the broken version:

import { useState } from 'react';

export default function TodoList() {
  const [todos, setTodos] = useState([]);
  function handleAddTodo(text) {
    // ❌ MUTATION: This modifies the existing array
    todos.push({ id: Date.now(), text, done: false });
    setTodos(todos);  // React doesn't notice-same reference
  }
  function handleToggleTodo(id) {
    // ❌ MUTATION: This modifies an object inside the array
    const todo = todos.find(t => t.id === id);
    todo.done = !todo.done;
    setTodos(todos);  // React still doesn't notice
  }
  return (
    
      
      
        {todos.map(todo => (
          
             handleToggleTodo(todo.id)} />
            {todo.text}
          

        ))}
      

    

  );
}

Run this and you’ll experience the bug: the UI won’t update even though the data changed. Sometimes it’ll update after a second action (the visual lag feels broken), or it won’t update at all. The state changed, but React never knew to look.

The Fix: Create a New Array, Every Time

The solution is simple in principle but easy to mess up in practice: always pass a new array reference to setState. React uses that new reference to know something changed and runs a re-render.

For adding items, use the spread operator:

function handleAddTodo(text) {
  // ✅ CORRECT: Create a new array with spread operator
  setTodos([
    ...todos,
    { id: Date.now(), text, done: false }
  ]);
}

This creates a brand-new array in memory with the old items plus the new one. React sees a different reference and knows to re-render.

For removing items, use filter():

function handleDeleteTodo(id) {
  // ✅ CORRECT: filter() returns a new array
  setTodos(todos.filter(t => t.id !== id));
}

filter() doesn't mutate the original—it returns a fresh array containing only the items that pass the test.

For updating an item in the array, use map():

function handleToggleTodo(id) {
  // ✅ CORRECT: map() returns a new array with transformed items
  setTodos(todos.map(todo =>
    todo.id === id
      ? { ...todo, done: !todo.done }  // Create a new object for this item
      : todo  // Keep other items unchanged
  ));
}

Here’s the gotcha: map() gives you a new array, but if you mutate the objects inside it, you still break state. That's why we use the object spread operator { ...todo, done: ... } to create a fresh object, not mutate the original.

The Complete, Fixed Example

import { useState } from 'react';

export default function TodoList() {
  const [todos, setTodos] = useState([]);
  function handleAddTodo(text) {
    if (text.trim()) {
      setTodos([
        ...todos,
        { id: Date.now(), text, done: false }
      ]);
    }
  }
  function handleToggleTodo(id) {
    setTodos(todos.map(todo =>
      todo.id === id
        ? { ...todo, done: !todo.done }
        : todo
    ));
  }
  function handleDeleteTodo(id) {
    setTodos(todos.filter(t => t.id !== id));
  }
  return (
    
       {
        if (e.key === 'Enter') {
          handleAddTodo(e.target.value);
          e.target.value = '';
        }
      }} placeholder="Add a todo..." />
      
        {todos.map(todo => (
          
                          type="checkbox"
              checked={todo.done}
              onChange={() => handleToggleTodo(todo.id)}
            />
            {todo.text}
            
          

        ))}
      

    

  );
}

Run this version and you’ll see updates happen instantly. Every action — add, toggle, delete — creates a new array, React catches it, and the UI reflects the truth.

A Common Trap: Shallow Copy Isn’t Always Enough

Here’s where people stumble next. You might copy an array but mutate its contents:

function handleBadUpdate(id) {
  // ❌ NEW ARRAY, but same objects inside
  const newTodos = [...todos];
  const todo = newTodos.find(t => t.id === id);
  todo.done = !todo.done;  // Mutating an object that's still in the original state
  setTodos(newTodos);
}

The spread operator is shallow — it copies the array structure, not the objects it contains. Both the old todos and the new newTodos point to the same todo objects in memory. You've created a new array, but you're mutating shared objects. React will re-render (because the array reference changed), but you've polluted the old state, which breaks features like undo/redo and can cause nasty bugs in concurrent rendering.

That’s why we use map() with object spread for updates: it ensures a fresh object exists in the new array.

When Arrays Get Complex: Meet Immer

If your arrays contain deeply nested objects or you’re doing a lot of updates, the spread syntax can get repetitive:

function handleUpdateNested(id, newArtwork) {
  setTodos(todos.map(todo =>
    todo.id === id
      ? { ...todo, details: { ...todo.details, artwork: { ...newArtwork } } }
      : todo
  ));
}

This is verbose and error-prone. The Immer library lets you write mutating code, and it figures out the immutable updates for you:

import { useImmer } from 'use-immer';

function handleUpdateNested(id, newArtwork) {
  updateTodos(draft => {
    const todo = draft.find(t => t.id === id);
    if (todo) {
      todo.details.artwork = newArtwork;  // Looks like mutation, but Immer handles it
    }
  });
}

With Immer, you write the convenient syntax, and it produces the immutable updates behind the scenes. For beginners, I’d stick with map() and spread—it teaches you the mental model. But Immer's worth knowing for larger projects.

Try This Now: Build a Mini Todo App

Open your React sandbox and create this challenge in under 5 minutes:

Build a list that displays three hardcoded todos.
Add a button for each that toggles done on click—watch the UI update.
Add a button that removes a todo from the list.

Use only map() and filter(). No Immer. This forces you to feel the pattern in your hands, not just read about it.

Learning Objectives

After reading this, you should be able to:

Explain why mutating array state breaks React re-renders and how spread/map/filter create new references.
Write add, remove, and update operations on arrays in state without mutations.
Identify shallow copy bugs and fix them by creating new objects within new arrays.
Recognize when Immer makes sense and know how to install it.
Debug “update doesn’t show” problems by checking whether you’re mutating vs. creating new arrays.

Prerequisites

You should have React installed (via create-react-app or Vite) and be comfortable with useState basics. If you need a refresher on why state exists, check The useState Rabbit Hole.

What’s Next

Build a form-based todo app that lets users edit todo text. You’ll need to update an object inside an array — this teaches you map() with object spread in one shot. It should take under an hour and cement the pattern.

If you enjoyed this, check out my previous post on Moving State Up: Why Your Components Need a Common Parent — it connects directly to today’s lesson and shows you the foundation that makes immutability necessary.

About Me

Moving State Up: Why Your Components Need a Common Parent

Rama Jha — Sun, 07 Dec 2025 12:02:13 GMT

I remember the exact moment my temperature converter broke. Two inputs, one supposed to update the other — Celsius to Fahrenheit and back. But they’d both change, they’d both have different values, and I had no idea why. Turns out I’d built them as independent components with separate state. They were like two people trying to dance to the same song from different rooms, never quite in sync.

That’s the moment I learned about lifting state.

In React, lifting state up is one of those patterns that doesn’t sound like much until you realize how often you need it. It’s the antidote to components talking past each other, and it’s the bridge between scattered local state and needing a full state management library. Let’s dig into why your components sometimes need a common parent, and how to build that relationship without making things more complicated than they need to be.

Learning Objectives

After reading this post, you’ll be able to:

Identify when two or more components need to share state and recognize when lifting is the right pattern
Move state from child components to a common parent and wire up props correctly
Write handler functions that encapsulate state updates, rather than passing setState directly
Understand the difference between controlled components and independent state
Recognize the limits of lifting and know when to reach for Context API instead

Prerequisites

You should already be comfortable with:

The basics of useState in functional components
Passing and receiving props
How React re-renders when state changes

No external libraries needed for this pattern — just React’s built-in useState and basic JavaScript.

What’s Actually Happening When You Lift State?

Here’s the honest truth: lifting state is just moving where your state lives. That’s it. Instead of each component managing its own piece of truth, you push that state up to a parent component, and the children read from and write to that shared parent state through props.

The pattern solves a real problem. When two or more components need to stay in sync — like those temperature inputs, or a todo list where the counter and the task display both need the same data — keeping state in separate places means they’ll inevitably drift out of sync. The parent becomes the single source of truth. Child components don’t store their own copy; they just reflect what the parent tells them to show.

React enforces unidirectional data flow. Data flows down as props; updates flow up through callback functions. This isn’t a limitation — it’s the whole point. It makes your app predictable. You always know where state lives, and you always know how to change it.

The Pattern: State, Props, and Handlers

Let’s build the temperature converter and actually see this work. I’ll show you the right way to pass update functions, not the anti-pattern you’ll sometimes see online.

Parent Component (TemperatureConverter.jsx):

import { useState } from 'react';
import CelsiusInput from './CelsiusInput';
import FahrenheitInput from './FahrenheitInput';

export default function TemperatureConverter() {
  const [celsius, setCelsius] = useState('');
  const fahrenheit = celsius ? (celsius * 9) / 5 + 32 : '';
  const handleCelsiusChange = (e) => {
    setCelsius(e.target.value);
  };
  const handleFahrenheitChange = (e) => {
    const f = parseFloat(e.target.value);
    setCelsius((f - 32) * 5) / 9);
  };
  return (
    
      Temperature Converter

      
      
    

  );
}

Child Component (CelsiusInput.jsx):

export default function CelsiusInput({ value, onChange }) {
  return (
    
      Celsius
              type="number" 
        value={value} 
        onChange={onChange} 
        placeholder="Enter temperature"
      />
    

  );
}

Child Component (FahrenheitInput.jsx):

export default function FahrenheitInput({ value, onChange }) {
  return (
    
      Fahrenheit
              type="number" 
        value={value} 
        onChange={onChange} 
        placeholder="Enter temperature"
      />
    

  );
}

See what’s happening here? The parent owns the state. The children receive value and onChange as props. When a child's input changes, it calls the onChange handler passed from the parent. The parent updates its state, recalculates the other temperature, and both children re-render with fresh values. They're always in sync because there's only one source of truth.

The children don’t care how the state updates. They just call the callback. This is crucial — it decouples the child from the parent’s internal logic.

The Gotcha: Don’t Pass setState Directly

Here’s where people stumble. You might think: “Why not just pass setCelsius directly to the child?" Technically, you can, but you shouldn't.

// ❌ Don't do this

The problem? Your child component now knows it’s writing to the parent’s state. It’s tightly coupled. More importantly, setState is asynchronous and batched. If you pass it directly, your child loses the ability to wrap the update in any logic—error checking, validation, side effects, or coordinating multiple state updates. You've handed all control to the child.

Instead, pass a handler function that you’ve written:

// ✅ Do this
const handleCelsiusChange = (e) => {
  const value = e.target.value;
  if (value === '' || !isNaN(value)) {
    setCelsius(value);
  }
};

Now validation lives in the parent, where all your temperature logic lives. The child is a dumb input — it just renders and calls what you gave it. This separation makes your code easier to test, debug, and extend.

When Lifting State Gets Messy (and What to Do About It)

Here’s my honest opinion: lifting state is great until you’re passing props through five levels of components to reach the one that actually needs them. This is called prop drilling, and it’s the moment you’re supposed to reach for Context API or a state management library like Zustand.

But here’s the catch — you’ll reach for those tools too early if you don’t understand lifting state first. Why? Because those solutions solve a different problem than just two or three components sharing data. If you have a parent and two children that need to sync, lifting state is the right answer. It’s simple, explicit, and you don’t need any extra dependencies.

Try this now: Open your code editor and build a simple form with two related inputs — maybe a password field and a “confirm password” field. Put them in separate child components, lift the state to a parent, and sync them with a handler function. See how they stay in lockstep? That’s the pattern working.

One More Thing: Performance and useCallback

If your parent component is re-rendering frequently and you’re passing handler functions to memoized children, those functions get recreated on every render. It’s not a disaster for simple apps, but if you want to optimize, wrap your handlers in useCallback:

const handleCelsiusChange = useCallback((e) => {
  setCelsius(e.target.value);
}, []);

const handleFahrenheitChange = useCallback((e) => {
  const f = parseFloat(e.target.value);
  setCelsius((f - 32) * 5) / 9);
}, []);

Now the handler reference stays the same across renders, so a memoized child won’t re-render unnecessarily. But honestly? Don’t over-optimize here. If you’re building a form with a few inputs, this level of tuning is premature. Get it working first, then profile if performance is actually slow.

What You Can Do Now

After reading this, you’re ready to:

Identify shared state between sibling components and move it to their nearest common parent
Write handler functions in the parent and pass them down as props (not setState directly)
Build controlled components where the parent owns the value and the child just renders and calls callbacks
Recognize when lifting stops making sense — when you’re passing props through too many layers, it’s time for Context API
Debug synchronization issues by tracing state to its owner — if two components are out of sync, their shared state is probably still scattered

Next Steps

Pick a feature you’ve built where multiple components show or edit the same data. Refactor it to lift state to their common parent, moving all the logic and update handlers up there. You’ll probably finish this in under an hour, and you’ll feel the simplicity click. Once you’ve done it once, the pattern becomes automatic.

If you enjoyed this, check out my previous post on Stop Overthinking Props vs. State: 3 Tiny Rules That Work in Every Project — it connects directly to today’s lesson and lays the groundwork for understanding why lifting state even matters.

About the Author

Controlled Inputs and Boolean Toggles: The 80% of React State You Need to Know

Rama Jha — Tue, 25 Nov 2025 12:02:13 GMT

Last Tuesday, I watched a junior dev spend twenty minutes debugging why their shopping cart’s “Remove Item” button was removing two items instead of one. The problem? They’d chained two state updates in a click handler without understanding how React 18’s batching actually works. By lunchtime, one tiny prev arrow function fixed it. That moment stuck with me because it's where theory collides with practice—and it's exactly what today's about.

Most React apps live in two simple state patterns: booleans for toggling visibility or features, and strings for capturing what users type. Master these, understand how functional updates work, and you’ve solved probably 80% of the state problems you’ll actually hit in production. Let’s go there.

Learning Objectives

After reading this post, you’ll be able to:

Build toggle components that switch visibility or features on and off using boolean state
Create controlled inputs that sync their value with React state and display live updates
Understand the difference between setValue(newValue) and setValue(prev => ...), and know when each matters
Recognize and fix the batching gotchas that trip up beginners in React 18
Handle multiple rapid state updates without losing information to stale closures

Prerequisites

You should have worked through Day 15’s intro to useState and understand that state variables trigger re-renders when you call their setter function. If useState syntax feels new, spend 10 minutes reviewing the basics before diving in.

The Boolean Toggle: Your First State Pattern

Let’s start with something you’ve probably seen a hundred times: a button that shows or hides content.

import { useState } from 'react';

export default function ToggleVisibility() {
  const [isVisible, setIsVisible] = useState(false);
  return (
    
      
      {isVisible && (
        Here's something you can toggle on and off.

      )}
    

  );
}

This is straightforward: isVisible is false initially, we flip it with !isVisible in the click handler, and conditional rendering shows or hides the paragraph. React re-renders when state changes, so the button text and the paragraph update instantly.

The gotcha most people miss? Try clicking that button rapidly. You’re fine. But if you had called setIsVisible(!isVisible) twice inside the same handler before batching was introduced, you'd see unexpected behavior. We'll circle back to why—React 18 fixed it—but for now, the mental model is simple: each toggle call inverts the state.

Here’s Where Beginners Stumble: The Batching Problem

Before React 18, if you did this:

function handleClick() {
  setIsVisible(!isVisible);
  setIsVisible(!isVisible);
  // After the click, isVisible is still the same—both calls saw the old value
}

Both calls would read isVisible as, say, false, and both would set it to true. You'd only get one update instead of two flips. The state value didn't change mid-handler because React batches state updates.

React 18 made this more predictable by batching updates everywhere (not just in event handlers), but it also means you can’t rely on the latest state mid-execution. This is where the updater function pattern saves you.

The Updater Function Pattern: prev => ...

Instead of reading the state directly, you pass a function that receives the current pending state:

export default function Counter() {
  const [count, setCount] = useState(0);

function handleTripleClick() {
    setCount(c => c + 1); // Receives 0, returns 1
    setCount(c => c + 1); // Receives 1, returns 2
    setCount(c => c + 1); // Receives 2, returns 3
  }
  return (
    
      Count: {count}

      
    

  );
}

React queues each updater function and runs them in order. The first call sees 0 and returns 1. The second sees 1 and returns 2. The third sees 2 and returns 3. No stale closures, no surprise duplicates.

When should you use this pattern? Any time you’re calculating the next state from the previous state. If you’re just setting a new fixed value — like setName('Alice')—the direct approach is fine. But the moment you're incrementing, toggling, or transforming based on what came before, use the updater function.

Controlled Inputs: Strings and Live Updates

Now let’s talk about capturing user input. A controlled input is one where React “owns” its value through state.

import { useState } from 'react';

export default function NameInput() {
  const [name, setName] = useState('');
  return (
    
              type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
        placeholder="Type your name"
      />
      Hello, {name || 'stranger'}!

    

  );
}

Here’s the flow: the input’s value prop is tied to the name state. When the user types, the onChange handler fires, reads the new value from the event object (e.target.value), and calls setName to update state. React re-renders, the input's value updates, and your greeting updates in sync. It feels instant to the user.

The key insight: the input value is never your source of truth — state is. If you tried to set the input’s value directly with JavaScript (inputElement.value = '...'), React would get out of sync and weird bugs would surface. Always funnel through state.

A Real-World Application: A Live-Updating Form

Let’s combine what we’ve learned. Here’s a component that demonstrates both toggles and controlled inputs working together:

import { useState } from 'react';
import styles from './Form.module.css';

export default function SignupForm() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [showPassword, setShowPassword] = useState(false);
  function handleSubmit(e) {
    e.preventDefault();
    if (!email || !password) {
      alert('Please fill in all fields');
      return;
    }
    console.log('Submitting:', { email, password });
  }
  return (
    
      
        Email:
                  type="email"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
          placeholder="you@example.com"
        />
      
      
        Password:
                  type={showPassword ? 'text' : 'password'}
          value={password}
          onChange={(e) => setPassword(e.target.value)}
          placeholder="••••••"
        />
      
              type="button"
        onClick={() => setShowPassword(!showPassword)}
        className={styles.toggleBtn}
      >
        {showPassword ? '👁️ Hide' : '👁️ Show'}
      
      
      
        Email: {email || '(empty)'}
      

    
  );
}

Notice a few things:

Email and password are controlled strings — they update as the user types.
showPassword is a boolean toggle that changes the input type between 'password' and 'text'.
The form’s onSubmit handler runs validation before logging data (in a real app, you'd send this to a server).
The preview paragraph shows the current email value live — this is React’s reactivity in action.

Try this now: Copy this component and add another toggle for “Remember me” that stores a boolean in state. Use the updater function pattern to add a button that clears both the email and password at once (with two updates in one handler).

Understanding React 18’s Batching and State Updates

React 18 introduced automatic batching outside event handlers too. This means if you call state setters inside an async callback or a Promise, they’ll still batch together.

export default function AsyncExample() {
  const [count, setCount] = useState(0);
  const [loading, setLoading] = useState(false);

function handleFetch() {
    setLoading(true); // Batched with the next update
    fetch('/api/data').then(() => {
      setCount(c => c + 1);
      setLoading(false); // Both of these batch together
    });
  }
  return (
    
      
      Count: {count}, Loading: {String(loading)}

    

  );
}

In older React versions, those two then callbacks would cause separate re-renders. Now they batch—only one re-render happens after both updates. This is faster and more predictable.

The trade-off: Sometimes you genuinely need to force a re-render between updates, like if you’re accessing the DOM for measurements. React exports a flushSync function for rare cases, but you'll rarely need it. Batch updates are good. Trust the batching.

One More Gotcha: Functional vs. Direct Updates

Here’s a question that confuses lots of developers: should I always use the updater function? The answer is no, not always — but it’s worth understanding the trade-off.

// Direct update—simple, clear when state is independent
setName('Alice');

// Updater function-safer when the new state depends on the old one
setCount(c => c + 1);


// You could technically use updater for everything, but it's overkill
setName(prev => 'Alice'); // ← Unnecessary, because 'Alice' doesn't depend on prev

A practical heuristic: If you’re reading the current state value to calculate the next value, use the updater function. Otherwise, set the value directly. The updater function is insurance against batching bugs and stale closures — it’s worth the extra parentheses.

Debugging Moment: Why Isn’t My Input Updating?

You’ll inevitably hit this: you type in an input and nothing happens.

// 🚩 Common mistake: forgetting the value prop
 setEmail(e.target.value)} />



// ✅ The input must be controlled (value prop tied to state)
 setEmail(e.target.value)} />

If your input is missing the value prop, React can't control it. It becomes "uncontrolled"—the browser manages its own value, and your state sits unused. The fix is always to add value={stateVariable}.

Another common one: the handler runs, but state doesn’t update.

// 🚩 Mistake: setState is called with a function, but React treats it as an initializer
const [fn, setFn] = useState(someFunction);


// ✅ Wrap it to store a function as state
const [fn, setFn] = useState(() => someFunction);

This only comes up if you’re storing functions in state (rare), but it’s worth knowing because the error message is cryptic.

What’s Next?

Pick one piece of functionality you’ve sketched but haven’t built: a password visibility toggle, a search box that filters a list, a form with multiple fields. Build it with these patterns — boolean state for toggles, string state for inputs, and updater functions for multi-step updates. Spend an hour on it. You’ll own this stuff by muscle memory.

Looking Further

We’ve covered the most common state patterns. Tomorrow (Day 17), we’ll step into arrays and objects in state — where immutability becomes critical. The principles you’re learning now scale directly to more complex state shapes, so cement these ideas first.

If you enjoyed this, check out my previous post on Stop Overthinking Props vs. State: 3 Tiny Rules That Work in Every Project — it connects directly to today’s lesson and covers the fundamentals that make everything here click.

About the Author

I’m a React developer documenting my 30-day React journey on Medium, sharing the lessons, gotchas, and “oh no” moments that beginners actually face. Follow along for practical tutorials, real code, and no buzzword fluff. Let’s connect on [X/Twitter] and [GitHub] — I’d love to hear about your own list-rendering disasters (we’ve all been there). Got questions? Drop a comment or message me anytime.

The useState Rabbit Hole: Functional Updates, Stale Closures, and Your First Counter

Rama Jha — Sat, 22 Nov 2025 12:02:06 GMT

Learning Objectives

After reading this post, you’ll be able to:

Declare and use useState with correct array destructuring syntax
Understand state as a snapshot and why calling setState doesn't change the value immediately
Implement functional (updater) patterns to reliably handle multiple state updates
Recognize the stale closure gotcha when state updates depend on previous values
Debug React 18 StrictMode double-invocations and understand why they’re actually your friend

Prerequisites

You should have a basic understanding of React functional components and know how to create a simple component. Familiarity with JavaScript array destructuring (const [a, b] = arr) is helpful. All examples use React 18+; if you're on an older version, some behavior (especially StrictMode) may differ.

Why useState Exists (And Why You Probably Got It “Wrong” at First)

I still remember the first time I tried to build a counter without looking at docs. I did something like this:

let count = 0;

function Counter() {
  function handleClick() {
    count += 1;
    console.log(count); // Works!
  }
  
  return ;
}

It printed the right number. The button just never updated on screen. I spent twenty minutes confused before I realized: React didn’t know the value changed. There’s no magic observer watching my count variable.

That’s what useState solves. It tells React: "Hey, this value can change, and when it does, please re-render my component."

The Basics: useState Syntax and Array Destructuring

Here’s how you declare state in a functional component:

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);
  return (
    
      Count: {count}

      
    

  );
}

Let’s break this down:

useState(0): You pass the initial value. React stores this and ignores it on every render after the first one.
const [count, setCount]: useState returns an array with two items. We use destructuring to unpack them. The naming convention is [value, setValue].
count: The current state value.
setCount: The function you call to update state and trigger a re-render.

React 18+ has been around long enough that this pattern is rock-solid. You’ll see it everywhere.

The Gotcha: State Updates Don’t Change the Current Value

Here’s where things get weird. Try this:

function Counter() {
  const [count, setCount] = useState(0);

function handleClick() {
    setCount(count + 1);
    console.log(count); // What will this print?
  }
  return ;
}

You’d think console.log(count) prints the new value, right? Nope. It still prints the old value. If count was 5 and you clicked the button, the console logs 5, not 6.

This trips up beginners all the time. Here’s why it happens:

State is a snapshot. When your component renders, count is frozen at a particular value for that render. Calling setCount() doesn't mutate that frozen value. It requests a new render with a new frozen value. The old value stays frozen in the current function execution.

// Think of it like this mentally:
function handleClick() {
  setCount(count + 1); // Request a re-render with count = 6
  console.log(count); // But *this* render still sees count = 5
}

This is actually a feature, not a bug. It prevents race conditions and makes your code more predictable. But it catches everyone off guard.

Re-renders and Why They Matter

When you call setCount(), React doesn't update the button instantly. Here's what actually happens:

You call setCount(count + 1)
React queues up this state update
React re-renders the Counter component with the new state
Your function runs again from the top with count now equal to the new value
The button JSX re-evaluates and React updates the DOM

This is why the mental model of “state is a snapshot” matters. Each render gets its own frozen version of state. The next render gets a different frozen version.

The Problem with Multiple Updates: Meet the Stale Closure

Let’s say you want a button that increments the counter by 3:

function tripleIncrement() {
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
}

What do you think happens? If count starts at 0, you'd expect it to end at 3.

It ends at 1.

All three calls happen within the same render. They all see the same frozen value of count (0 in this case). So you end up with:

setCount(0 + 1) → sets to 1
setCount(0 + 1) → sets to 1 (overwrites the previous one)
setCount(0 + 1) → sets to 1 (overwrites again)

Result: count is 1, not 3. This is called a stale closure — your function is “closed over” an old value of state.

The fix? Use a functional update (also called an updater function):

function tripleIncrement() {
  setCount(c => c + 1); // Updater receives the pending state
  setCount(c => c + 1); // Updater receives the result of the previous update
  setCount(c => c + 1); // Updater receives the result of that update
}

Now React queues these updates and applies them in order, each one receiving the result of the last:

setCount(c => c + 1) → 0 becomes 1
setCount(c => c + 1) → 1 becomes 2
setCount(c => c + 1) → 2 becomes 3

Result: count is 3. Correct.

The updater function gives you access to the pending state — the result of all previously queued updates in this batch. That’s the key difference.

When to Use Direct Updates vs. Updaters

Direct update (just pass the new value):

setCount(count + 1);

Use this when you’re updating based on user interaction in a single moment. React guarantees that the latest value is available in event handlers. One click = one update, no stale closure risk.

Functional update (pass a function):

setCount(c => c + 1);

Use this when:

You’re calling setState multiple times in the same handler
You’re unsure whether the state you’re reading is fresh
You want to update based on the previous state, not the state you’re holding

Here’s where people stumble: functional updates feel verbose, so beginners avoid them. Then their counter mysteriously skips numbers or their form data doesn’t save correctly. They debug for an hour before realizing they needed the updater pattern all along.

A good rule of thumb: if your update calculation depends on the current state, use the updater. If not, the direct approach is fine.

Object State and Immutability

State can hold objects, too:

const [form, setForm] = useState({ name: '', age: '' });

Here’s a critical rule: treat state as read-only. Don’t do this:

// 🚩 Don't mutate:
form.name = 'Alice';
setForm(form); // React won't know anything changed

React compares the old and new state objects. If you mutate the object in place, the object reference is the same, so React thinks nothing changed. No re-render.

Instead, create a new object:

// ✅ Correct:
setForm({
  ...form, // Spread the old values
  name: 'Alice' // Override just this field
});

The spread operator (...) creates a shallow copy. React sees a new object, so it knows to re-render.

React 18 StrictMode: Why Your Component Renders Twice (And It’s Okay)

If you’ve ever opened the console and seen your component render twice, you’ve met StrictMode.

In development, React 18 wraps your app in by default:

root.render(
  
    
  
);

StrictMode intentionally calls your component function twice during render. And it calls your initializer and updater functions twice. It looks buggy in the console, but it’s actually genius.

Why? React is checking: “Is my component pure?” A pure function returns the same output given the same input. If you’re doing side effects (like Math.random() or fetching data inside the component body), StrictMode will expose it by calling things twice.

Here’s the thing: this only happens in development. Your production build runs normally. It’s a safety net.

If you’re using correct patterns — pure functions, proper immutability — StrictMode won’t break anything. Those double calls will produce identical results, and React discards one of them.

If you are doing something impure and one of the calls behaves differently, that’s the bug StrictMode is catching for you. You fix it now instead of shipping a production bug.

// 🚩 Impure—StrictMode will catch this:
function Counter() {
  const [items, setItems] = useState([]);
  
  items.push('new item'); // Mutating! This will happen twice in StrictMode.
  
  return {items.length}
;
}

// ✅ Pure-StrictMode won't complain:
function Counter() {
  const [items, setItems] = useState([]);
  
  const withNewItem = [...items, 'new item']; // New array, never mutating
  
  return {withNewItem.length}
;
}

I used to find the double-render confusing. Now I see it as React saying, “I’m watching to make sure you’re keeping things pure.”

Your First Counter: Putting It All Together

Let’s build a proper counter component that handles all these concepts:

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);
  const handleIncrement = () => setCount(c => c + 1);
  const handleDecrement = () => setCount(c => c - 1);
  const handleReset = () => setCount(0);
  return (
    
      Count: {count}

      
        
        
        
      

    

  );
}

Notice:

Increment and decrement use the updater pattern (c => c + 1) because they depend on the previous state
Reset uses a direct update (setCount(0)) because it doesn't depend on the current value
Each button has a clear, named handler function

This is production-ready. It handles edge cases, works with StrictMode, and scales if you add more features.

Try This Now: Multi-Click Challenge

Create a button that increments the counter by 2 every click. Use both approaches — first try the naive way with direct updates, see what happens. Then refactor to use the updater pattern. Notice the difference?

// Try this:
function doubleIncrement() {
  setCount(count + 1);
  setCount(count + 1);
}


// Then try this:
function doubleIncrement() {
  setCount(c => c + 1);
  setCount(c => c + 1);
}

The second one should give you the behavior you expect. This tiny experiment teaches the stale closure concept better than any explanation.

What’s Next?

The natural next step is to extract this counter into a custom Hook. If you find yourself managing the same state in multiple components, wrapping the logic in a custom Hook keeps things DRY. Build a useCounter hook that encapsulates the increment, decrement, and reset logic—then use it in different components. You can finish this in under an hour and it'll make the real power of Hooks click.

If you enjoyed this, check out my previous post on Building a Product Catalog: The Real Test of Your Week 2 React Skills — it connects directly to today’s lesson.

About the Author

Building a Product Catalog: The Real Test of Your Week 2 React Skills

Rama Jha — Thu, 20 Nov 2025 12:02:04 GMT

I remember the moment I first tried to build a product list. I had learned props, mapping, and conditional rendering separately, and I felt confident about each one. Then I sat down to combine them, and nothing worked the way I expected. My component rendered correctly, then broke when I added the key prop. I’d pass a function as a prop and wonder why my event handler didn’t fire. That’s when I realized: Week 2 concepts aren’t hard individually — they’re hard together. This project will show you exactly what I mean.

What You’ll Build

Over the next two weeks, you’ve absorbed a lot: passing data with props, composing components, rendering lists with .map(), showing and hiding content with conditional logic, and handling user events. A static product catalog pulls all of these together in a real e-commerce scenario. You'll build a component tree that mirrors how actual apps work. By the end, you'll have a working product list with inventory badges, and you'll understand why each piece matters.

Learning Objectives

By the time you finish this post and build the project, you’ll be able to:

Plan a component architecture by breaking a UI into reusable pieces and deciding what data each needs
Structure product data as an array of objects and pass it through your component tree
Render lists efficiently with .map() and proper keys, avoiding reconciliation bugs
Show conditional content like “Out of Stock” badges based on product state
Handle click events on list items and buttons in preparation for next week’s state management

Prerequisites

You should have completed Days 1–13 of the 30-day schedule. Specifically:

You’re comfortable writing functional components with props
You’ve used .map() to render arrays in JSX
You understand ternary operators and logical AND for conditional rendering
You have a Vite React project running locally (from Day 2 setup)

If you need a quick refresher, revisit the Passing Props guide or Rendering Lists.

Where People Stumble: The Data Flow Gap

Here’s what I see beginners struggle with most: they understand props individually but freeze when structuring data for a real feature. They’ll pass a single prop perfectly, then panic when they need to pass an entire object, an array, or a function. The mental jump from “I pass name="John"" to "I pass an array of products, each with 10 properties" feels bigger than it should.

The other gotcha? Keys. Beginners often add key={index} and everything looks fine until they add sorting or filtering. Then React's virtual DOM reconciliation gets confused, and you end up with weird bugs where animations fire twice or input focus gets lost. The fix is one line—use a stable, unique identifier—but the why takes explaining.

Step 1: Plan Your Component Architecture

Before you write any code, think about your UI. A product catalog typically has:

A header showing the catalog title
A product list container that holds all items
Individual product card components for each item
An optional filter or sort area (we’ll keep it simple this week)

Here’s a tiny sketch in React thinking:


  └── 
      ├── 
      ├── 
      │   ├── 
      │   ├── 
      │   └── 
      └──  (optional)

Notice the data flow: holds the product array, passes it to , which passes it to , which loops and passes individual items to . This is a real-world data flow—not trivial, not overly complex.

Why structure it this way? Because later, when you add state management (Week 3), you’ll need to modify that product array. Having it defined in one place makes that change straightforward.

Step 2: Design Your Data Structure

Your product data matters. Here’s what a real product looks like in an e-commerce system:

const products = [
  {
    id: 1,
    name: "Wireless Headphones",
    price: 79.99,
    category: "Audio",
    inStock: true,
    image: "headphones.jpg",
  },
  {
    id: 2,
    name: "USB-C Cable",
    price: 12.99,
    category: "Cables",
    inStock: false,
    image: "cable.jpg",
  },
  {
    id: 3,
    name: "Phone Stand",
    price: 25.00,
    category: "Accessories",
    inStock: true,
    image: "stand.jpg",
  },
];

Each product has:

id: A stable, unique value (use this for keys, not array index)
name and price: Display content
inStock: Controls conditional rendering of the “Out of Stock” badge
category and image: Future-proofing for filtering or image display

This structure mirrors real APIs you’ll fetch from next week.

Step 3: Build the ProductCard Component

Let’s start small. A single product card should display the product name, price, and a conditional badge if it’s out of stock.

// ProductCard.jsx
export default function ProductCard({ product }) {
  return (
    
      {product.name}

      ${product.price.toFixed(2)}

      {!product.inStock && Out of Stock}
    

  );
}

Breaking this down:

{ product } destructures the prop so you access product.name instead of props.product.name
${product.price.toFixed(2)} ensures prices always show two decimal places
{!product.inStock && Out of Stock} is the logical AND pattern for conditional rendering—render the badge only if inStock is false

Gotcha: Don’t write {product.inStock ? null : ...}. It works, but the logical AND is cleaner for simple "show or hide" logic.

Step 4: Build the ProductList Component

Now render multiple products. This is where .map() and keys come into play.

// ProductList.jsx
export default function ProductList({ products }) {
  return (
    
      {products.map((product) => (
        
      ))}
    

  );
}

What’s happening:

products.map() loops through each item and returns JSX for each one
key={product.id} tells React this item is uniquely identified by its ID
product={product} passes the entire product object as a prop to ProductCard

Why id not index? If you reorder your products array later, or delete an item, array indexes shift. React uses keys to track which item is which. A stable ID (like a database ID) survives reordering. If you use key={index} and sort your products, React gets confused about which component instance belongs to which data—animations glitch, form inputs lose focus, and performance tanks.

Try this now: Replace key={product.id} with key={products.indexOf(product)} (which is basically the array index). Your catalog still renders. Then add a sort button that reverses the products array. With index keys, things break subtly. With stable IDs, they work fine. That's the difference.

Step 5: Assemble Everything in App

Pull it together at the top level:

// App.jsx
import ProductList from './ProductList';

const products = [
  {
    id: 1,
    name: "Wireless Headphones",
    price: 79.99,
    category: "Audio",
    inStock: true,
    image: "headphones.jpg",
  },
  {
    id: 2,
    name: "USB-C Cable",
    price: 12.99,
    category: "Cables",
    inStock: false,
    image: "cable.jpg",
  },
  {
    id: 3,
    name: "Phone Stand",
    price: 25.00,
    category: "Accessories",
    inStock: true,
    image: "stand.jpg",
  },
];
export default function App() {
  return (
    
      Our Store

      
    

  );

This is your first real multi-level data flow. App owns the products data, passes it to ProductList, which maps over it and passes each item to ProductCard. If you later move this data to state (which you'll do next week), you only change it in one place.

Add a Little Polish: Click Handlers Ready

Here’s where we prep for next week. Add a click handler that doesn’t do much yet, but shows you the pattern:

// ProductCard.jsx (updated)
export default function ProductCard({ product, onSelectProduct }) {
  return (
     onSelectProduct(product)}>
      {product.name}

      ${product.price.toFixed(2)}

      {!product.inStock && Out of Stock}
    

  );
}

And in your ProductList:

// ProductList.jsx (updated)
export default function ProductList({ products }) {
  const handleSelectProduct = (product) => {
    console.log('Selected:', product.name);
  };

return (
    
      {products.map((product) => (
                  key={product.id} 
          product={product} 
          onSelectProduct={handleSelectProduct}
        />
      ))}
    

  );
}

You’re passing a function onSelectProduct as a prop. When you click a card, it logs the product. Next week, you'll swap console.log for something that updates state—maybe storing the selected product or adding it to a cart. The structure is already there.

Basic Styling to Make It Look Real

Add this to your index.css or a module to give your catalog some shape:

.product-card {
  border: 1px solid #e0e0e0;
  border-radius: 8px;
  padding: 16px;
  margin: 8px;
  min-width: 200px;
  cursor: pointer;
  transition: transform 0.2s, box-shadow 0.2s;
}

.product-card:hover {
  transform: translateY(-4px);
  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
}
.price {
  font-size: 18px;
  font-weight: bold;
  color: #2c5282;
  margin: 8px 0;
}
.badge {
  display: inline-block;
  background-color: #fc8181;
  color: white;
  padding: 4px 8px;
  border-radius: 4px;
  font-size: 12px;
  font-weight: bold;
  margin-top: 8px;
}
.product-list {
  display: flex;
  flex-wrap: wrap;
  justify-content: flex-start;
}

Nothing fancy, but it’s enough to see your components layout correctly.

One More Debugging Moment

Here’s a real mistake I made repeatedly: forgetting to pass a required prop and watching React silently fail to render anything. In ProductCard, if I wrote {product.price} but never received the product prop, the component crashes silently in development (you'll see an error in the console). The fix is always the same: check your prop names match between parent and child.

Quick checklist:

Parent passes:
Child receives: function ProductCard({ product })
Child uses: {product.name}

If any of those three don’t line up, nothing works.

Your Next Mini-Challenge

Take the code from this post and do this: add a fourth product to the array where inStock is false. Make sure the "Out of Stock" badge shows. Then, in your ProductList, add a console.log that prints the product ID when you click a card. Don't overthink it—if you get the click firing and the ID logging, you've understood the data flow and events are ready for state management.

What You’ve Accomplished

You now have a product catalog that:

Renders a list of products from an array
Uses stable keys to track each item properly
Shows conditional content (the “Out of Stock” badge)
Responds to user clicks
Has a clear component hierarchy and data flow

This is the foundation. Next week, you’ll make it interactive: add items to a cart, toggle stock status, filter by category — all with state. But the skeleton is perfect.

Next Steps

Build a simple product filter: create an array of categories and add buttons that filter the product list by selected category. No state needed yet — just use Array.filter() to create a new filtered array and pass it to ProductList. This reinforces the data flow pattern and prepares you for dynamic state updates next week.

If you enjoyed this, check out my previous post on Stop Overthinking Props vs. State: 3 Tiny Rules That Work in Every Project — it connects directly to today’s lesson by showing you exactly which data should live where before we introduce state management.

About the Author

Stop Overthinking Props vs. State: 3 Tiny Rules That Work in Every Project

Rama Jha — Mon, 17 Nov 2025 10:28:00 GMT

Last week, I spent two hours debugging why a form wouldn’t update properly. Turns out, I’d accidentally “mirrored” the user’s email from a prop into component state — so when the parent updated, my local state didn’t get the memo. The input showed stale data. Classic beginner trap.

The truth? Props vs. state isn’t complicated. There’s just a pattern most tutorials skip: a simple mental test that tells you which one to reach for before you write a single line of code.

Let me walk you through it.

What Actually Are Props and State?

Props are data from the outside — passed down from a parent component. Think of them like function parameters. A parent says, “Hey, here’s a user’s name,” and the child receives it. The child can’t change it; it can only read and use it.

State is data a component owns and controls. It’s internal. When state changes, the component notices and updates the UI to match. Only that component can modify its own state.

Here’s a concrete example. Imagine a UserCard component:

function UserCard(props) {
  // props.name comes from the parent—immutable here
  return {props.name}
;
}


// Parent passes it:

If Alice’s name needs to change later, the parent updates it and passes a new prop. The child doesn’t decide to change it on its own.

Now, what if we have a toggle button that switches between “view” and “edit” mode?

function UserCard(props) {
  const [isEditing, setIsEditing] = useState(false);
  
  return (
    
      {props.name}

      
    

  );
}

Here, isEditing is state because this component manages it. Nobody outside cares if we're in edit mode—it's internal UI logic. The parent never passes it; the component decides and updates it.

Rule 1: “Is It Information Only This Component Needs?”

If data is private to one component — like a modal’s “open/closed” state or the current value in a text input before submission — make it state.

I’ve seen developers pass UI toggles down as props from a parent. “Does your modal show?” becomes a prop. Then another sibling component wants to toggle it too, so now the parent manages it, and suddenly you have props drilling through five layers. Stop there.

Quick test: Could this component do its job if nobody else cared about this data? If yes, it’s state.

Example: A filter dropdown that expands and collapses. The parent doesn’t care whether it’s open or closed — only this dropdown cares.

function FilterDropdown() {
  const [isOpen, setIsOpen] = useState(false);
  
  return (
    
      
      {isOpen && Filter options...
}
    

  );
}

Rule 2: “Can This Data Change? And Who Decides?”

This is where things get weird for beginners. The mistake I made (mirroring props in state) happens here.

Here’s the anti-pattern:

function UserProfile(props) {
  // ❌ Don't do this
  const [name, setName] = useState(props.name);
  
  return {name}
;
}

Why’s this bad? Because if the parent updates props.name later, name in state won't notice. Your component's now "out of sync"—React calls this "derived state," and it's a footgun.

If data comes from the parent and you’re not modifying it locally, just use the prop directly. Seriously. No state wrapper needed.

function UserProfile(props) {
  // ✅ Do this instead
  return {props.name}
;
}

The exception? If you need to modify it locally before sending it back up. Example: a controlled form input.

function EditUserForm(props) {
  const [name, setName] = useState(props.name);
  
  const handleSave = () => {
    props.onSave(name); // Send updated value to parent
  };
  
  return (
    <>
       setName(e.target.value)} />
      
    
  );
}

Notice: you initialize state from the prop (for the initial value), but you also call a callback (props.onSave) to tell the parent what changed. The parent then decides whether to update and re-render. Unidirectional data flow.

Quick test: If the parent changes this data, should my copy update automatically? If yes, use a prop. If no — only if the user modifies it locally — use state and a callback.

Rule 3: “Does More Than One Component Care About This?”

This one’s about sharing state between siblings or distant cousins.

Imagine a todo app. You’ve got a form that adds todos and a list that shows them.

function App() {
  const [todos, setTodos] = useState([]);
  
  const addTodo = (newTodo) => {
    setTodos([...todos, newTodo]);
  };
  
  return (
    <>
      
      
    
  );
}

The todos state lives in the parent (App) because both children need it. The form updates it (via callback), the list displays it (via prop). This is called "lifting state up," and it's the backbone of React data flow.

But here’s where people stumble: they put state in the wrong place. A junior dev once put the todos array in the form component, then tried to access it from the list. Doesn't work—sibling components can't see each other's state. You have to lift it to their common ancestor.

Quick test: Could two or more components need this data? Move it to the lowest common parent. Pass it down as props. Pass callbacks back up for updates.

The catch? If you go deep — like 5+ layers of prop drilling — you hit “prop drilling hell.” That’s when Context API or a small state library like Zustand starts looking good. But for your first 30 days of React, master lifting state first. That’s the foundation.

Where People Actually Stumble

Here’s the gotcha nobody mentions in tutorials: defaulting the wrong way.

Beginners tend to make everything state “just in case.” “What if I need to change this?” Then they inherit a prop, mirror it into state, and the component breaks when the parent updates. Or they lift state way too high, and now pass a prop through 5 components that don’t even use it.

The better instinct? Start by asking: “Does this come from outside?” → Use props. “Does this component decide and change it?” → Use state. Don’t pre-optimize. Don’t “just in case.” Answer honestly, write the code, and refactor when you actually need to.

I learned this the hard way. My first projects had state everywhere. Data wasn’t syncing. Callbacks got lost. Now? I default to props, use state only when the component truly owns something, and I avoid derived state like it owes me money.

Let’s Apply the Rules: A Real Scenario

Say you’re building a product card for an e-commerce site.

function ProductCard(props) {
  // props.product comes from parent (the list)
  // props.onAddToCart is a callback from parent
  
  const [quantity, setQuantity] = useState(1);
  const [showDetails, setShowDetails] = useState(false);
  
  return (
    
      {props.product.name}

      ${props.product.price}

      
      
      {showDetails && {props.product.description}
}
      
              type="number"
        value={quantity}
        onChange={(e) => setQuantity(Number(e.target.value))}
      />
      
      
    

  );
}

Let’s break it down:

props.product and props.onAddToCart? Props. The parent (the product list) owns this data and decides when to update it.
quantity and showDetails? State. Only this card cares. The parent never needs to know; it's just UI logic.

This keeps things simple and composable. Want to reuse ProductCard elsewhere? It works. It doesn't depend on specific parent logic—it just takes a product and a callback.

One Mini-Challenge for Right Now

Grab a component you’ve written recently (or write a quick one). List every piece of data it uses. For each one, ask yourself: “Who owns this? Can it change? Who decides?”

Data from parent → Prop.
Data this component controls → State.
Data two siblings need → Lift it up to the parent.

Rewrite using only those rules. Notice how much clearer the component gets. That clarity? That’s when you know you’re thinking like a React developer.

Your Next Move

Now that you’ve got these three rules, the next big step is learning useState and how to update state correctly without accidentally mutating it. That's Day 15 in your schedule—and it builds directly on everything you've just learned. You're not starting from scratch; you're ready.

Try this: build a simple form with a name input, an email input, and a submit button. Use props to pass the form configuration (labels, placeholders) and state to manage what the user types. When the user submits, call a callback function that the parent passes. Get comfortable with that loop: parent passes props and callbacks, component manages local state, component calls callbacks to tell the parent about changes.

If you enjoyed this, check out my previous post on ES6 Essentials for React: A Developer’s Handbook (Not a Tutorial) — it covers destructuring and the spread operator, which you’ll lean on every single day when working with props and state.

About the Author

onClick and onChange: The Event Handler Patterns Beginners Get Wrong

Rama Jha — Mon, 10 Nov 2025 09:58:16 GMT

Last week, I was pair-programming with a dev who’d been building React for about three weeks. He had a form with an input field, and when the user typed, nothing happened. He’d written the onChange handler, passed the event object correctly, but he was trying to access event.target.value after the state update, in the same function. His code looked clean—no errors in the console. But nothing worked.

After five minutes, he said: “Wait, is the event object gone?” Bingo.

This is one of the biggest gotchas when you’re learning event handling in React, and it’s not your fault if it catches you. The docs don’t emphasize it enough, and beginners usually figure it out through frustration. Today, we’re going to walk through the actual patterns that work, the ones that break, and the weird edge case that’ll save you hours of debugging.

Why This Matters

React doesn’t use browser events directly. It uses something called synthetic events — a cross-browser wrapper around the native event system. That’s great for consistency, but it also means some of the old tricks you might know from vanilla JavaScript don’t work the same way. And the patterns you choose for handling onClick and onChange shape how you think about state, forms, and interactivity for the next three weeks of learning.

Get this right now, and everything that comes next feels natural. Get it wrong, and you’ll spend next week fighting with form inputs that won’t update or buttons that don’t respond.

The Big Pattern: Controlled Components

Here’s the core idea: in React, form inputs are usually “controlled,” meaning React owns their value. You don’t let the browser manage the input’s state. You manage it with React state, and the input renders whatever value you tell it to render.

This sounds like extra work — and it is, a little — but it gives you total control over what the user sees, when it updates, and how you validate it.

Here’s the minimal version:

import { useState } from 'react';
export default function LoginForm() {
  const [email, setEmail] = useState('');
  const handleEmailChange = (event) => {
    setEmail(event.target.value);
  };
  return (
    
      Email:
              id="email"
        type="email"
        value={email}
        onChange={handleEmailChange}
      />
      You typed: {email}

    
  );
}

Three things are happening:

The input has a value prop set to email state. This means React controls what appears in the field.
The onChange handler fires whenever the user types. It receives an event object, extracts the new value from event.target.value, and updates state.
React re-renders, the input gets the new email value, and the
tag shows what you typed in real time.

Try this now: create a new component, paste this code, and type in the input. You’ll see the live update. That’s the pattern working.

Where Beginners Stumble: The Event Object Disappor

Here’s the gotcha I mentioned. When you need the event value and want to do async work (like calling an API), people write this:

const handleChange = (event) => {
  const value = event.target.value;
  setEmail(value);
  
  // ❌ This doesn't work as expected
  setTimeout(() => {
    console.log(event.target.value); // undefined or stale value
  }, 0);
};

If you run this, the setTimeout will probably log an empty string or the old value, not the new one. Why? In React 16 and earlier, synthetic events were pooled for performance—React reused event objects. Once the handler finished, React cleared the event object's properties. Since React 17, that pooling is gone in modern browsers, but the pattern of not relying on the event object after state updates is still safer and clearer.

Here’s the fix: grab the value you need right away, then use it:

const handleChange = (event) => {
  const value = event.target.value;
  setEmail(value);
  
  // ✅ Correct: use the variable, not the event
  setTimeout(() => {
    console.log(value); // works as expected
  }, 0);
};

Or, even cleaner: extract the value first, then update state with it:

const handleChange = (event) => {
  const newEmail = event.target.value;
  setEmail(newEmail);
  
  // If you need to react to the state change, use useEffect (more on that later)
};

This pattern isn’t just about avoiding a bug — it’s about thinking clearly. The event is a snapshot in time. The value is what you care about. Treat them as separate things, and your code stays understandable.

onClick: Simpler, But Patterns Still Matter

Buttons are straightforward, but there’s an easy wrong turn. Here’s a button that deletes a task when clicked:

export default function TaskItem({ taskId, onDelete }) {
  const handleDelete = () => {
    onDelete(taskId);
  };

return ;
}

This works. The function is defined once, and React calls it whenever someone clicks. No event object complications (you don’t need it, most of the time).

But here’s where beginners go wrong: they try to pass parameters inline:

// ❌ This re-creates the function on every render


// ✅ This is fine too, but less obvious why

Neither is wrong, actually. The inline arrow function is recreated every render, but for a single button, React’s so fast it doesn’t matter in practice. However, if you’re rendering a list of items with inline functions, React has to re-create hundreds of functions every render. That’s wasteful.

Here’s my opinion: define the handler outside the JSX, and pass parameters through a wrapper function or closure. It’s clearer, and it scales better:

export default function TaskList({ tasks, onDelete }) {
  const handleDeleteClick = (taskId) => {
    onDelete(taskId);
  };

return (
    
      {tasks.map((task) => (
        
          {task.name}
          
        

      ))}
    

  );
}

This way, handleDeleteClick is defined once. The inline arrow function passes the specific taskId. It's a small thing, but it becomes habit, and habits matter when you write bigger apps.

onChange vs. onInput: Subtle But Real

I’d be remiss not to mention this: React normalizes onChange so it fires on every keystroke, just like onInput does in vanilla JavaScript. Technically, they're the same in React.

But here’s the catch: if you reach for vanilla JavaScript or third-party libraries, onChange on native inputs doesn't fire on every keystroke—it only fires when focus leaves the input. onInput does fire on every keystroke.

In React, use onChange on inputs. React handles the normalization. You don't need onInput. But if you're reading code from 2015, or if you're mixing React with non-React parts, this might bite you. Just be aware.

Preventing Default: The Small But Important Piece

When you submit a form or click a link, the browser has a default behavior: it reloads the page or navigates away. In React, you almost always want to prevent that and handle it in JavaScript instead.

export default function LoginForm() {
  const [email, setEmail] = useState('');
  const handleSubmit = (event) => {
    event.preventDefault(); // Stops the page reload
    console.log('Submitting email:', email);
    // Now send it to your backend
  };
  return (
    
              value={email}
        onChange={(event) => setEmail(event.target.value)}
      />
      
    
  );
}

The event.preventDefault() is essential. Without it, clicking "Log In" refreshes the page, and your React state gets wiped. Very annoying. Very easy to forget. I still check for it when something "isn't working."

Try This Now: Build a Comment Counter

Here’s a real challenge to cement this stuff:

Create a component with a text input (controlled).
Add a button below it labeled “Add Comment.”
When you click the button, display the comment in a list below and clear the input.
Add a “Delete” button next to each comment.

You’ll use onChange to manage the input, onClick on "Add Comment" to read the current input value, onClick on delete to remove items, and preventDefault logic if you put it in a form. This is approximately what a real app does, just smaller.

Here’s a scaffold to get you started:

import { useState } from 'react';
export default function CommentBoard() {
  const [comments, setComments] = useState([]);
  const [input, setInput] = useState('');
  // You fill in the handlers below
  const handleAddComment = () => {
    // Extract input, add to comments, clear input
  };
  const handleDelete = (index) => {
    // Remove comment at index
  };
  return (
    
              value={input}
        onChange={(event) => setInput(event.target.value)}
        placeholder="Write a comment..."
      />
      
      
        {comments.map((comment, index) => (
          
            {comment}
            
          

        ))}
      

    

  );
}

(Yes, using array index as a key is fine here for a simple list. We’ll talk about better keys later.)

What You Can Do Now

After reading this, you should be able to:

Build a controlled input with onChange that updates state in real time.
Handle button clicks with onClick and pass parameters without recreating functions unnecessarily.
Prevent default form behavior and manage submission in React instead of letting the browser reload.
Spot the gotcha when the event object isn’t available and know to extract values upfront.
Choose between inline and separate handler functions based on what makes sense for your use case.

What’s Next

Next, you’ll use these event handlers to build actual forms, and you’ll learn how React state flows down and events flow up. If you want to level up right now, try the comment board challenge above. It’ll take you 20 minutes, and you’ll have hit all five of those objectives.

But here’s a heads-up: Next time, we’ll talk about props vs. state — the mental model that makes all of this click. Because events are just half the story. The other half is knowing where to put your state so that events bubble up the way you expect.

If you enjoyed this, check out my previous post on Conditional Rendering: Showing and Hiding Components — it connects directly to today’s lesson, since you’ll often use events to toggle visibility or change what’s displayed based on user interaction.

About the Author

The One Conditional Rendering Mistake That’ll Crash Your React App

Rama Jha — Mon, 03 Nov 2025 09:42:06 GMT

Photo by Lautaro Andreani on Unsplash

Last week, a developer in a code review pointed out something that made me pause: they’d written {items.length && } in a component. At first glance, looks fine. Then their first test run hit an edge case—empty array—and suddenly the page rendered the number 0 where nothing should appear. Not catastrophic, but sloppy. And it gets worse in production codebases where state changes are unpredictable.

That 0 appearing on screen is the classic gotcha with conditional rendering in React. It's the mistake that teaches you something fundamental about how React actually works—not what you assume it does. Let me show you exactly why this happens, how to fix it, and more importantly, how to think about conditional rendering so you never second-guess yourself.

What You’ll Learn

After reading this, you’ll be able to:

Spot the 0 rendering bug before it ships
Choose the right conditional rendering pattern for your use case
Understand why React renders numbers but not booleans
Handle complex UI logic without writing messy nested ternaries
Debug conditional rendering issues in production

Prerequisites: Familiarity with React hooks (useState, basic props), JSX syntax, and how JavaScript falsy/truthy values work.

The Problem: Why That Sneaky Zero Shows Up

Here’s the scenario. You want to show a list of notifications only if there are notifications to display. So you write:

function NotificationCenter({ notifications }) {
  return (
    
      {notifications.length && }
    

  );
}

Seems right. If notifications.length is truthy (like 5), render the component. If it's falsy (like 0), render nothing. That's the expectation.

But this is where most people trip up: React doesn’t render booleans, but it does render numbers.

When notifications.length equals 0, JavaScript evaluates 0 && and returns 0 (the left operand, since it's falsy). React then goes: "Okay, I got a number. I'll render that on the DOM." Result? The digit 0 appears on screen.

Here’s what actually happens under the hood:

// ❌ When notifications is empty:
0 && 
// JavaScript returns: 0 (left side, because it's falsy)
// React renders: 0
// What you see: The number 0 on the page

// ❌ For comparison, with booleans:
false && 
// JavaScript returns: false
// React renders: nothing (booleans are ignored)
// What you see: Empty DOM

The difference feels academic until it breaks your UI at 2 AM on a Friday.

Why React Designed It This Way

Here’s where understanding the design decision actually helps: if React ignored all falsy values including 0, you couldn't render numbers in your JSX at all. Imagine an email app:


  You have {emailCount} unread messages

If emailCount is 0 and React refuses to render 0, that person with an empty inbox would see blank text. That's broken. So React made a choice: render numbers (including 0), ignore booleans and null. It makes sense in isolation, but creates this trap.

The Fix: Four Patterns That Actually Work

Pattern 1: Use the Ternary Operator (Safest for Most Cases)

The most straightforward fix is the ternary operator. Show one thing if true, something else if false:

function NotificationCenter({ notifications }) {
  return (
    
      {notifications.length > 0 ? (
        
      ) : null}
    

  );
}

This is explicit and clear. notifications.length > 0 is always a boolean. No numbers, no ambiguity. React knows: true = render, false = render nothing.

When to use this: Simple binary decisions. One thing or nothing. You’ll use this constantly, and it’s fine to use it even in small cases.

Pattern 2: Coerce the Condition to Boolean (Quick Fix)

If you love the brevity of &&, you can convert the left side to a boolean using the !! operator:

function NotificationCenter({ notifications }) {
  return (
    
      {!!notifications.length && }
    

  );
}

The !! converts any truthy/falsy value to explicit true or false. !!0 becomes false. !!5 becomes true. It's a bit terse, though—your future self reading this code might not remember why you added the extra exclamation marks.

When to use this: When you’re confident in the code’s intent and want the && shorthand. Fair warning: it looks quirky to newcomers on your team.

Pattern 3: Explicit Boolean Check (Clearest Intent)

function NotificationCenter({ notifications }) {
  const hasNotifications = notifications.length > 0;
  
  return (
    
      {hasNotifications && }
    

  );
}

By naming the variable hasNotifications, the code says what it means. Someone reading this six months from now (maybe not you) understands immediately what's being checked. This scales well to complex logic too.

When to use this: Always, if performance isn’t a barrier (and for UI logic, it rarely is). This is professional, maintainable, and kind to your team.

Pattern 4: Returning null from the Component (Hide Don’t Show)

Sometimes, instead of conditionally rendering at the parent level, you flip it: the component itself decides whether to render anything:

function NotificationList({ items }) {
  if (items.length === 0) {
    return null;
  }
  
  return {/* render items */}
;
}

// Parent component:
function NotificationCenter({ notifications }) {
  return (
    
      
    

  );
}

This encapsulates the logic inside the component that understands its own data best. The parent doesn’t need to know or care about the empty state.

When to use this: When the component has full control over its visibility. Common with feature toggles, auth checks, or modals.

A Real-World Scenario: The Tricky Bits

Here’s where things get complicated in practice. Say you’re building a dashboard with different sections that can be loading, empty, or populated:

function UserDashboard({ users, isLoading, error }) {
  return (
    
      {/* Here's where people stumble: */}
      {users.length && }
      {error && }
      {isLoading && }
    

  );
}

This looks clean until:

users.length is 0 → renders 0
error is an empty string "" → renders nothing (strings are rendered, but empty ones look empty, so... accidentally works)
isLoading is false → correctly renders nothing

The inconsistency is the real problem. Your team has to remember which pattern prevents the bug and which doesn’t.

Better approach:

function UserDashboard({ users, isLoading, error }) {
  return (
    
      {users.length > 0 && }
      {error && }
      {isLoading && }
    

  );
}

Now every conditional is consistent: an explicit boolean check on the left, component on the right.

When Conditional Rendering Gets Complex

If you find yourself nesting ternaries or chaining multiple && operators, that's a sign to refactor. Here's when things get ugly:

// ❌ Nested ternaries are hard to follow:
{isLoggedIn ? (
  isPremium ? (
    
  ) : (
    
  )
) : (
  
)}

Introduce a separate state management hook or derive a single variable:

// ✅ Extract the logic:
const dashboardContent = getDashboardContent(isLoggedIn, isPremium);

return {dashboardContent}
;

// Elsewhere:
function getDashboardContent(isLoggedIn, isPremium) {
  if (!isLoggedIn) return ;
  if (isPremium) return ;
  return ;
}

This reads like prose and scales when you have five conditions instead of three.

The Debugging Moment: Your Checklist

When conditional rendering misbehaves, run through this:

Does a number appear where nothing should? → Check if you used count && pattern. Use count > 0 && instead.
Is the component always rendering? → Check if your condition is actually falsy. Log it: console.log(condition) in the JSX before your &&.
Is the component never rendering when it should? → Flip your logic. If !isOpen && looks wrong, it probably is. Use a ternary for clarity.
Multiple conditions not working as expected? → Build them separately. Don’t chain three && in a row; assign each to a variable first.

Try This Now: Your 5-Minute Challenge

Create a TaskList component that:

Shows a list of tasks if tasks exist
Shows “No tasks yet!” if the array is empty
Shows a loading spinner while fetching
Shows an error message if something broke

Here’s the skeleton:

function TaskList({ tasks = [], isLoading, error }) {
  // Your job: fill in the returns
  
  if (isLoading) {
    return ;
  }
  
  if (error) {
    return ;
  }
  
  // The tricky part:
  if (tasks.length > 0) {
    return {tasks.map(t => {t.name}
)}
;
  }
  
  return No tasks yet!
;
}

This covers every state your app can enter. Notice how we handle each case before rendering, rather than wrapping JSX in conditions. This reads like a decision tree, which is exactly what it is.

What’s Next

Build a small auth-gated component this week: a Dashboard that shows different content based on isLoggedIn and userRole (like admin, user, guest). Practice writing the conditional logic in different ways—ternary, &&, and extracted functions—and see which feels most natural for your brain and your team's style.

If you enjoyed this, check out my previous post on Keys, Chaos, and the .map() Method: Handling Dynamic Lists in 2025 React — it connects directly to today’s lesson, especially how useState updates trigger re-renders that re-evaluate your conditionals.

About the Author

Keys, Chaos, and the .map() Method: Handling Dynamic Lists in 2025 React

Rama Jha — Thu, 30 Oct 2025 10:01:54 GMT

Keys, Chaos, and the .map() Method: Handling Dynamic Lists in 2025 React

Last week I spent three hours debugging a form where checkbox values kept disappearing after users sorted the list. The weird part? Everything worked fine until someone clicked “Sort by Name.” Then boom — checked boxes randomly jumped to different items, and the one they’d just selected was blank. Turns out, I’d been using array indexes as keys. That single mistake broke React’s reconciliation, and suddenly my “simple” feature list looked like a crime scene.

If you’ve ever rendered a list in React, you’ve probably used .map() and slapped on a key prop without thinking twice. But there's a universe of chaos hiding behind that innocent little attribute, and in 2025, with React 19's smarter reconciliation, understanding keys isn't optional—it's what separates working code from UI nightmares.

What You’ll Learn

After reading this, you’ll be able to:

Use .map() to transform arrays into JSX components cleanly and correctly.
Understand why the key prop matters for React's reconciliation algorithm and what breaks when you get it wrong.
Avoid the array-index-as-key trap and recognize when it’s actually safe (spoiler: almost never for dynamic lists).
Generate stable, unique keys using IDs, UUIDs, or crypto APIs depending on your data source.
Filter and sort arrays before rendering them without mutating state or breaking your UI.

Prerequisites

You’ll need a basic React setup (Vite is the 2025 standard), comfort with JSX syntax, and a working knowledge of JavaScript array methods like .map(), .filter(), and .sort(). I'll provide runnable snippets, but you can also spin up a quick project with npm create vite@latest if you want to follow along in code.

Why .map() is Your Best Friend (and Worst Enemy)

In React, you can’t just loop over an array with a for loop and push JSX into a variable—well, you can, but it's ugly and un-React-like. Instead, you use .map() to transform data arrays into component arrays. Here's the simplest version:

const users = ['Alice', 'Bob', 'Charlie'];

function UserList() {
  return (
    
      {users.map((name) => (
        {name}

      ))}
    

  );
}

This works, but open your console and you’ll see React screaming at you: “Warning: Each child in a list should have a unique ‘key’ prop.” React needs keys to track which items are which during re-renders. Without them, it falls back to positional matching, which is basically guessing.

The key Prop: React's Memory System

Think of keys like nametags at a conference. If everyone’s wearing one, React knows exactly who moved, who left, and who’s new. If people just line up by position, React has no idea if the person in slot 2 is the same person or a replacement, so it re-renders everything just to be safe.

Here’s what happens under the hood. React builds a virtual DOM tree and compares it to the previous one. For each element in an array, it checks: “Does this key match something I saw before?” If yes, it updates that component. If no, it mounts a new one or unmounts the missing one. When you use indexes as keys, React thinks the key didn’t change — even though the data did — so it updates the wrong components.

The Classic Gotcha: Index Keys

Let me show you the bug that cost me three hours. Suppose you have a list of users with input fields:

const [users, setUsers] = useState([
  { name: 'Alice', email: 'alice@example.com' },
  { name: 'Bob', email: 'bob@example.com' },
  { name: 'Charlie', email: 'charlie@example.com' }
]);

return (
  
    {users.map((user, index) => (
      
        
      

    ))}
  

);

Looks fine, right? But when you delete the first item (Alice), here’s what React sees:

Key 0: Was Alice, now Bob → Update the component (DOM stays, but data swaps).
Key 1: Was Bob, now Charlie → Update the component.
Key 2: Missing → Delete the last component.

So instead of removing Alice’s input, React keeps all the DOM nodes, updates their data, and deletes Charlie’s. If those inputs had state (like a typed value or a checkbox), that state sticks to the DOM node, not the data. Bob’s input now shows Alice’s old value. Users see their data jump around like a shell game.

Here’s the proof in plain JavaScript (simulating React’s reconciliation):

=== Using Array Indexes as Keys (PROBLEMATIC) ===

Initial state:
  Key: 0 -> Alice (alice@email.com)
  Key: 1 -> Bob (bob@email.com)
  Key: 2 -> Charlie (charlie@email.com)

After deleting first item (Alice):
  Key: 0 -> Bob (bob@email.com)
  Key: 1 -> Charlie (charlie@email.com)

⚠️  React sees:
  - Key 0: Was 'Alice', now 'Bob' → UPDATE component
  - Key 1: Was 'Bob', now 'Charlie' → UPDATE component
  - Key 2: Missing → DELETE component

Result: React updates Bob and Charlie instead of just removing Alice!

The Fix: Stable, Unique IDs

Always use an ID that travels with the data. If your data comes from a database, use the row ID. If you’re generating it locally (like a to-do list), use crypto.randomUUID() or the uuid npm package:

import { v4 as uuidv4 } from 'uuid';

const [users, setUsers] = useState([
  { id: uuidv4(), name: 'Alice', email: 'alice@example.com' },
  { id: uuidv4(), name: 'Bob', email: 'bob@example.com' },
  { id: uuidv4(), name: 'Charlie', email: 'charlie@example.com' }
]);
return (
  
    {users.map((user) => (
      
        
      

    ))}
  

);

Now when you delete Alice, React sees:

✅ React sees:
  - Key usr_001: Missing → DELETE component (Alice)
  - Key usr_002: No change → KEEP component (Bob)
  - Key usr_003: No change → KEEP component (Charlie)

Result: React only removes Alice's component. Bob and Charlie stay intact!

Perfect. No shuffling, no lost state.

Important: Don’t call uuidv4() inside the .map() itself—that regenerates the key on every render, which defeats the whole point. Generate the ID once when you create the data, then reuse it.

Filtering and Sorting Before You Map

Real apps don’t just render static lists. You filter search results, sort by date, toggle categories. The golden rule: manipulate the array first, then map over the result. React doesn’t care what you do to the data before JSX; it only sees the final array.

Filtering Example

Show only users whose email domain is example.com:

function FilteredUserList({ users }) {
  const exampleUsers = users.filter(user => user.email.endsWith('@example.com'));

return (
    
      {exampleUsers.map((user) => (
        {user.name}

      ))}
    

  );
}

Sorting Example

Sort users alphabetically by name. Warning: .sort() mutates the original array, which is a no-no in React because state should be immutable. Clone first:

function SortedUserList({ users }) {
  const sortedUsers = [...users].sort((a, b) => a.name.localeCompare(b.name));

return (
    
      {sortedUsers.map((user) => (
        {user.name}

      ))}
    

  );
}

Alternatively, use .toSorted() (a newer method that returns a sorted copy without mutating). Either way, clone before you sort, or you'll get weird side effects.

Chaining Filter, Sort, and Map

You can chain them in one expression, but keep it readable:

const activeUsers = users
  .filter(user => user.active)
  .sort((a, b) => a.name.localeCompare(b.name))
  .map(user => );

This is clean, but if the logic gets complex, break it into variables. Debugging a five-method chain is no fun.

Handling Edge Cases and Performance

Duplicate Keys

If your data has duplicate IDs (or you accidentally use the same key twice), React will throw a warning: “Encountered two children with the same key”. This usually means bad data. Track down the source, because duplicate keys cause orphaned DOM nodes and phantom components that refuse to unmount.

Large Lists and Memoization

In React 19, automatic memoization handles many cases where you’d previously reach for React.memo or useMemo. But if you're rendering thousands of items, you might still need to memoize the list itself or use windowing libraries like react-window. Don't prematurely optimize—profile first, then fix bottlenecks.

When Index Keys Are Actually Okay

There’s one exception: static lists that never reorder, filter, or change. If you’re rendering a hardcoded array of strings that’ll never update, using indexes won’t hurt you. But honestly, why risk it? Just add an ID to your data and sleep better at night.

A Quick Debugging Story

Here’s where people stumble: You build a todo list. You map over todos with indexes as keys. Everything works. Then you add a “Mark Complete” button that reorders completed items to the bottom. Suddenly, clicking “Complete” on the second todo makes the third one vanish, and the checkboxes jump around like they’re haunted.

What happened? React compared the old and new arrays by index. When you moved item 2 to the end, React saw:

Index 0: Same
Index 1: Different data → update
Index 2: Different data → update
Index 3: New → mount

So it updated items 1 and 2 in place (keeping their DOM state), then mounted a new component for item 3. If item 1 had a checked checkbox, that state stuck to the DOM node, which now shows item 2’s data. Chaos.

The fix: Use stable IDs. React sees item 2 moved, so it moves the actual component (with its state intact) instead of updating a different component’s data.

Try This Now: The Mini-Challenge

Create a component that renders an array of user objects (at least three users, each with an id, name, and email). Add two buttons: one to sort by name, one to delete the first user. Use proper keys. Then intentionally break it—switch to index keys and watch the chaos unfold. Swap back to unique IDs and confirm it works. This hands-on moment will cement the lesson way better than reading.

Here’s starter code:

import { useState } from 'react';
import { v4 as uuidv4 } from 'uuid';

function UserManager() {
  const [users, setUsers] = useState([
    { id: uuidv4(), name: 'Charlie', email: 'charlie@test.com' },
    { id: uuidv4(), name: 'Alice', email: 'alice@test.com' },
    { id: uuidv4(), name: 'Bob', email: 'bob@test.com' }
  ]);
  const sortByName = () => {
    setUsers([...users].sort((a, b) => a.name.localeCompare(b.name)));
  };
  const deleteFirst = () => {
    setUsers(users.slice(1));
  };
  return (
    
      
      
      
        {users.map((user) => (
          
            {user.name} - {user.email}
          

        ))}
      

    

  );
}

What’s Next: Build a Searchable Product List

Take what you learned and build a mini product catalog. Create an array of at least five products (each with id, name, price, category). Add:

A search input that filters by name.
Buttons to filter by category (e.g., “Electronics,” “Clothing”).
A toggle to sort by price (low to high, high to low).

Use .filter(), .sort(), and .map() with proper keys. Bonus: Add a "Delete" button for each product and confirm the right item gets removed. You should finish in under an hour, and it'll reinforce filtering, sorting, and reconciliation in one project.

Wrapping Up

The .map() method is how you bring data to life in React, but without the right keys, your lists will betray you at the worst possible moment. Indexes work until they don't, and by then you're debugging phantom state and disappearing inputs at 2 a.m. In 2025, with React 19's improved reconciliation and automatic memoization, getting keys right is even more important—because React's optimizations assume you're playing by the rules.

Use stable, unique IDs. Filter and sort before you map. Clone arrays before mutating. And when something breaks, check your keys first. Nine times out of ten, that’s the culprit.

If you enjoyed this, check out my previous post on The Children Prop: React’s Secret to Reusable Wrapper Components — it connects directly to today’s lesson and will help you build on what you’ve learned here.

About the Author