DEV Community: ReactChallenges

🚀 New React Challenge: Invoker modal

ReactChallenges — Tue, 14 Jul 2026 16:40:48 +0000

Tired of writing useState(false) and onClick handlers every time you need a modal? The browser already has a declarative API for that.

🧩 Overview

Learn how to open and close a <dialog> using only HTML attributes — no React state, no useState, no event handlers at all. The Invoker Commands API lets buttons control dialogs natively.

👉 https://www.reactchallenges.com/challenges/invoker-modal

✅ Requirements

Wire the "Contact Us" button to open the dialog using command and commandfor attributes
Wire the "Close" button to close the dialog
The dialog must start closed
Keep the existing form fields and data-testid attributes intact
Do not remove the TypeScript module augmentation block

💡 Notes

A button uses command and commandfor to tell the browser to call showModal() or close() — no JavaScript needed.
useId() from React is the idiomatic way to generate a unique id for linking button to dialog.
The declare module "react" block already adds command and commandfor to React's button types.

🧪 Tests

Renders the app title
Renders the open button with command attributes
Matches the button commandfor with the dialog id
Dialog does not have the open attribute initially
Close button has command close with matching commandfor

This challenge is perfect for developers who want to rely more on the platform and write less JavaScript. You'll learn a native browser API that makes modals simpler, more accessible, and more resilient.

🔥 Start the Challenge Now

🚀 New React Challenge: Tier List

ReactChallenges — Mon, 06 Jul 2026 11:44:05 +0000

Ever built a drag-and-drop UI with just the native browser API? No react-beautiful-dnd, no dnd-kit — just dragStart, dragOver, and drop events. In this challenge, you'll build a Tier List app where users upload images and rank them A through F by dragging, mastering the HTML5 Drag and Drop API along the way.

https://www.reactchallenges.com/challenges/tier-list

🧩 Overview

Build a tier maker app where users upload images and drag them into ranked tiers (A through F) — practicing HTML5 Drag and Drop and file uploads in React.

✅ Requirements

Render a "Tier List" title at the top of the page
Render six tier rows labeled A, B, C, D, E, F with the correct background colors
Include two action buttons: Add (file picker) and Reset (moves all images back)
Provide a selector area at the bottom where unassigned images appear
Start with an empty selector and empty tier rows
File upload: selecting images via file picker adds them to the selector; dragging files from desktop onto the selector also works
Drag and drop: drag images from selector to tiers, between tiers, and back to the selector
Highlight the drop zone while dragging over it
Reset moves all images from tier rows back into the selector area

If you've never worked with the native Drag and Drop API before, this is the perfect challenge to get comfortable with it. You'll walk away knowing how to handle file uploads, drag events, and complex UI state — all inside a custom hook.

🔥 Start the Challenge Now

Cognitive Surrender and Why You Should Still Write Code by Hand

ReactChallenges — Mon, 22 Jun 2026 08:47:32 +0000

A study from the University of Pennsylvania introduced a term that should make every developer pause: cognitive surrender. Across 9,500 trials with over 1,300 participants, researchers found that when an AI provided an answer — even a wrong one — people accepted it without scrutiny 73.2% of the time. Not because the answers were convincing. Because the mere presence of a confident AI response was enough to shut down the part of the brain that says "wait, let me think about this."

If you write code for a living, you already know where this is going.

👉 Try it in practice: Simple pagination

The shortcut that becomes the habit

The researchers describe a shift from two systems of thinking to a third: artificial cognition. Instead of reasoning through a problem, you ask the machine. Instead of verifying, you paste and move on.

For developers, this is now routine. You need a pagination component. You type a prompt. You get a fetch inside a useEffect, some useState, a loading skeleton. It works. You ship it. You don't think about it again.

But the study found something revealing: participants with higher fluid IQ — the ability to solve novel problems — were far less likely to be misled by faulty AI. The skill that protected them wasn't knowing more. It was the habit of reasoning things through.

Where AI belongs (and where it doesn't)

None of this means you should ditch AI. It means you should be intentional about where you deploy it.

AI is great for mechanical, repetitive work that requires zero reasoning. Generating Storybook stories for every component variant. Writing boilerplate unit tests that follow a predictable pattern. Scaffolding a folder structure. Tasks where the thinking is already done and what's left is typing.

But when the task involves a decision — how should this state be structured? what does the user need when this errors? should this be optimistic or not? — that's where you want the friction. That's the muscle you don't want to atrophy.

Use it or lose it

Writing a pagination component is not hard. Fetch data, track the page, handle loading, surface errors. An LLM can do it in three seconds.

But the point of writing it yourself is not the result. It's the friction.

When you write a fetch call manually, you remember how AbortController works. When you toggle loading and error states by hand, you internalize async UI patterns. When you decide what the retry button looks like, you think about the user. None of that happens when you accept a generated block and move on.

The experiment design was telling: participants used a modified LLM that gave wrong answers half the time. When the AI was accurate, 93% accepted it. When it was faulty, that only dropped to 80%. Even when the machine was demonstrably wrong, four out of five went along with it. The AI didn't just provide answers — it lowered the threshold for scrutiny.

This is not about rejecting AI tools. It's about recognizing that reasoning ability — like any other skill — atrophies without use.

Keep the muscle alive

The fix is mechanically simple: practice without the net. Not every day, not for every task. But regularly enough that the mental pathways stay warm.

Pick a problem you could solve with a prompt and solve it manually. Write the pagination from an empty file. Handle the errors. Wire up the loading states. The value is not the code — it's staying fluent enough to know when the AI is wrong, and sharp enough to fix it without asking the AI again.

Delegate the boilerplate. Protect the thinking.

👉 Try it in practice: Simple pagination

🚀 New React Challenge: Simple Pagination

ReactChallenges — Sun, 21 Jun 2026 10:35:57 +0000

In a time where AI writes most of our boilerplate, manually wiring a fetch with loading, error, and pagination states is exactly the kind of thing that slips through the cracks — and exactly what keeps coming up in job interviews.

🧩 Overview

A plain fetch with pagination and manual loading and error handling. No libraries, no abstractions — just useState, useEffect, and a mock API that delays, paginates, and randomly fails. The kind of challenge that keeps your fundamentals sharp.

👉 https://www.reactchallenges.com/challenges/simple-pagination

✅ Requirements

Fetch users from https://example/users?page={page} and display them in a table (ID, Name, Last name). The API returns up to 10 users per page.
Show a loading skeleton while fetching.
Display page info: Page {page} of {totalPages} ({count} users).
Pagination buttons:
- First: goes to page 0. Disabled when on page 0.
- Previous: goes to the previous page. Disabled when on page 0.
- Next: goes to the next page. Disabled when on the last page.
- Last: goes to the last page. Disabled when on the last page.
All buttons disabled when count is 0 or while loading.
Display an error message when the request fails.

If you've been leaning on AI for the boilerplate lately, this one will remind you how much muscle memory matters. Simple fetch, clean state, solid edge cases — exactly what separates a working prototype from interview-ready code.

🔥 Start the Challenge Now

🚀 New React Challenge: Build a Spreadsheet with Formula Evaluation

ReactChallenges — Thu, 11 Jun 2026 09:55:42 +0000

You've built todo apps, counters, and forms. But can you handle a grid of 50 cells that reference each other through formulas? This challenge pushes your state management skills into real spreadsheet territory — formula evaluation, two-way cell bindings, and an interface that juggles editing, selection, and keyboard shortcuts all at once.

🔥 Start the Challenge Now

🧩 Overview

Build a spreadsheet with real-time formula evaluation. You'll wire up a 10-row × 5-column grid where cells support basic values and Excel-style formulas (like =A1+B2), column and row selection, and a formula bar that mirrors what you're typing.

✅ Requirements

Render a spreadsheet with column headers A through E and rows 1 through 10
Each cell uses an <output> element for the computed value and an <input> overlaid for editing
Click a cell to edit; press Enter or blur to commit the change
Formulas starting with = must be evaluated:
- Arithmetic: =1+1 → 2
- Cell references: A1=5 and B1==A1+3 → 8
Click a column header to select/deselect that column
Click a row number to select/deselect that row
Selecting a column deselects any row and vice-versa
Backspace clears the selected column or row
Click outside the table deselects everything
A formula bar (fx) mirrors the editing cell's value
Cells must start empty — no default values

💡 Notes

Use useState for cells, selected column, and selected row. No need for useReducer here.
Each cell uses two overlapping layers: a visible <output> for the computed value and an invisible <input> for the raw formula. Toggle with opacity-0 / opacity-100 so the input stays mounted.
Evaluate formulas with eval: generate JS const declarations from all cell values, wrap them in an IIFE, and evaluate. Recompute every cell on any change — cells can reference each other.

🧪 Tests

renders the app title
renders the spreadsheet with column headers A-E and rows 1-10
renders cells with initial empty values
allows editing a cell and displays the new computed value
evaluates a simple formula
evaluates a formula with cell references
re-evaluates formulas when a referenced cell is cleared
selects a column when clicking the column header
deselects column when clicking the same header again
selects a row when clicking the row number
deselects row when clicking the same row number again
deselects column when selecting a row and vice-versa
clears the column when Backspace is pressed with a column selected
clears the row when Backspace is pressed with a row selected
deselects column when clicking outside the spreadsheet

🔥 Start the Challenge Now

This one will stretch your understanding of React state in ways a simple counter or todo list never could. Formula engines, overlay editing, and cascading recomputation — all with just hooks and vanilla React.

Your tests pass. Your linter doesn't.

ReactChallenges — Mon, 08 Jun 2026 13:02:34 +0000

Every React developer has written code like this:

function TodoList() {
  const [list, setList] = useState([]);
  const [showClearCompleted, setShowClearCompleted] = useState(false);

  useEffect(() => {
    setShowClearCompleted(list.some((task) => task.isComplete));
  }, [list]);

  // ...
}

The app works. The tests pass. The feature is shipped. And nobody notices that this code has a bug — not a functional bug, but a structural one.

The silent lie of derived state

setShowClearCompleted inside a useEffect that watches list is the React equivalent of buying a notebook, writing down the result of 2 + 2, and then, every time one of the numbers changes, erasing it and writing 4 again — instead of just asking "what is 2 + 2?" when you need the answer.

The value of showClearCompleted is derived from list. It is not a separate piece of state. It is a computation over state you already have. Yet the code above treats it as if it were independent — storing it, syncing it, and triggering an extra render to apply it.

👉 Try it yourself: Challenge #53 — Best Practices

Here is what the corrected version looks like:

function TodoList() {
  const [list, setList] = useState([]);
  const showClearCompleted = list.some((task) => task.isComplete);

  // ...
}

No effect. No extra state variable. No cascading render. Just a value computed from state you already own. The component renders, the computation runs, the UI updates — all in a single pass.

Why this matters: cascading renders

When you call setState inside a useEffect, React has to do two renders instead of one. The first render computes the effect dependencies. The effect fires. It calls setState. React schedules a second render with the new state.

In a small component, you won't feel it. In a page with dozens of components, each with their own derived-state effects, the cascade compounds. You get flickers, stale intermediate states, and a performance profile that is needlessly heavy for no reason at all.

And the worst part? If you only test the output — the DOM, the rendered text, the visible behavior — you will never catch this.

Most platforms don't check. We do.

Go to any coding challenge site. Pick a React challenge. Write the version with useEffect. Run the tests. They pass. Congratulations, you solved it.

But did you write good React? The answer depends on what "good" means. If it means "the tests pass," then yes. If it means "idiomatic, performant, maintainable React that your coworkers won't silently judge during code review," then no.

Challenge #53 on React Challenges is different. When you hit Run Tests, two things happen:

Your code runs against a suite of behavioral tests (does the todo list add, delete, toggle, and clear items?)
Your code is checked against an ESLint configuration that enforces React best practices

If you use useEffect to sync derived state, the linter catches it:

 ✗ App.tsx:29:5  error
   react-hooks/set-state-in-effect
   Calling setState synchronously within an effect causes cascading renders

And the challenge is not considered complete until all lint rules pass.

The test-passing trap

There is a quiet assumption in the coding challenge world: if the tests pass, you are done. This assumption trains developers into habits that are fine for a green checkmark and dangerous for a production codebase.

You can write a component that works and is wrong. You can render the correct UI with code that silently burns through render cycles, hides derived data behind state machines, and uses effects as event handlers because the mental model of React's render cycle never fully clicked.

Most platforms let you walk away with the green checkmark and a false sense of mastery. We wanted to build one that tells you the second thing: yes, it works — but it is not right yet.

And for that, you need a linter.

👉 Try it yourself: Challenge #53 — Best Practices

🚀 New React Challenge: Best Practices

ReactChallenges — Mon, 08 Jun 2026 11:25:53 +0000

Your todo list passes all tests. You ship it. But here's the thing no one tells you about interviews — reviewers don't just check that your code works. They look for the 3 anti-patterns hiding in plain sight. This challenge puts ESLint in the reviewer's seat and asks you to clean up the code without breaking a single test.

👉 https://www.reactchallenges.com/challenges/best-practices

🧩 Overview

In a real technical interview, solving the logic is only half the battle. Reviewers are trained to spot lazy useState initializers, derived state hidden inside useEffect, and impure calls during render. This challenge gives you a working todo list and surfaces exactly those violations through automated linting. Fix all 3 warnings without changing how the app behaves.

✅ Requirements

Fix all ESLint warnings without changing app behavior
All 6 tests must keep passing after your changes
Resolve these 3 violations:
- @eslint-react/use-state — pass a lazy initializer instead of calling the function eagerly
- react-hooks/set-state-in-effect — derive showClearCompleted directly from state, skip the useEffect workaround
- @eslint-react/purity — move new Date() out of the render path

Three small fixes, three big "aha" moments. Whether you're prepping for React interviews or just want to stop shipping code that silently wastes renders, this one will sharpen the way you read your own components. No new features — just cleaner, faster React.

🔥 Start the Challenge Now

What useOptimistic Actually Saves You

ReactChallenges — Tue, 26 May 2026 17:20:19 +0000

A checkbox toggle should feel instant. But when that toggle needs to persist to a server, you face a choice: wait for the response and feel sluggish, or update immediately and handle the fallout. The second option — optimistic UI — is better for users, but the manual implementation adds state, flags, and try/catch blocks that pile up fast. For a simple checkbox the difference is small — a few lines. For anything more complex, the gap widens quickly.

👉 Try it in practice: useOptimistic

The manual way: state + pending + rollback

Here's a typical TODO checkbox that optimistically updates the UI before the server responds. No libraries — just React's built-in hooks:

function TodoItem({ todo, onToggle }) {
  const [checked, setChecked] = useState(todo.completed);
  const [pending, setPending] = useState(false);

  async function handleToggle() {
    setChecked((prev) => !prev);
    setPending(true);

    try {
      await onToggle(todo.id, !checked);
    } catch {
      setChecked(checked);
    } finally {
      setPending(false);
    }
  }

  return (
    <label>
      <input
        type="checkbox"
        checked={checked}
        disabled={pending}
        onChange={handleToggle}
      />
      {todo.title}
    </label>
  );
}

26 lines for one checkbox. The try/catch handles a server error, but what if the component unmounts while the request is in flight? What if the parent updates todo.completed from a different source while your toggle is pending — the local checked state and the prop drift apart, and the catch handler restores a stale value. Each edge case adds more state and more branches.

With useOptimistic

Now the same feature with useOptimistic and startTransition:

function TodoItem({ todo, onToggle }) {
  const [optimisticChecked, addOptimistic] = useOptimistic(
    todo.completed,
    (state, next) => next,
  );

  function handleToggle() {
    startTransition(async () => {
      const next = !todo.completed;
      addOptimistic(next);
      await onToggle(todo.id, next);
    });
  }

  return (
    <label>
      <input
        type="checkbox"
        checked={optimisticChecked}
        onChange={handleToggle}
      />
      {todo.title}
    </label>
  );
}

23 lines. Not a dramatic difference in raw line count. The savings aren't in how many lines you type — they're in what you no longer have to think about.

Here's why: startTransition wraps the async work in a React Transition. When the transition ends (on success or error), React re-renders the component. At that point, useOptimistic simply renders whatever todo.completed is. If the parent updated it — success, the checkbox stays checked. If the parent didn't update it — failure, the checkbox goes back to how it was. The rollback isn't "built-in error handling." It's just a consequence of the passthrough prop not changing.

The manual version needs try/catch for a different reason: it has a separate pending flag and a separate checked state. If onToggle throws, both are stuck in the wrong value unless you manually reset them. With useOptimistic, there's nothing to reset — the prop is the only source of truth.

For a checkbox, it's a few lines. For anything more complex — adding to a list, toggling related fields, or managing multiple optimistic values — the manual approach balloons while the useOptimistic version barely grows. That's where the real savings live.

This doesn't mean you can skip error handling entirely. The UI reverts on its own, but you still want to show an error toast, log the failure, or offer a retry — all of which happen outside the optimistic state logic. useOptimistic handles what the checkbox shows; you still handle what the user should know.

Keep complexity at the edge

There's a pattern here that goes beyond this checkbox.

Any time your code has to deal with something external — a server response, a user action, an API call — you have two options. You can let that uncertainty spread through your functions and components, or you can contain it at the boundary where it enters.

The Zod rule validate at system boundaries does exactly this for server-side data. Validate the request body at the endpoint, and every function downstream receives clean, typed data. No more checking "is this field a string?" ten layers deep.

useOptimistic does the same thing for UI state. The user clicks, and instead of spraying pending and error flags across your component, you declare the optimistic change right where the user acted — inside startTransition. The hook keeps the UI in sync with the prop. Everything downstream just renders.

One boundary, one place to think about it, one thing to debug.

👉 Try it in practice: useOptimistic

🚀 New React Challenge: Instant UI with useOptimistic

ReactChallenges — Sat, 23 May 2026 10:37:07 +0000

Ever clicked a like button and watched it stall for a second while the server thinks about it? That tiny delay makes your app feel sluggish. React 19 ships useOptimistic to fix exactly that — the UI changes before the server responds, and snaps back automatically if something goes wrong.

🔥 Start the Challenge Now

🧩 Overview

Learn React's useOptimistic hook by building instant heart toggles. Click the heart, see it turn red immediately, and let React handle the server in the background. If the request fails, the heart reverts on its own — no manual rollback code.

✅ Requirements

Render two cards side by side: one labeled "Successful toggle" and another "Error toggle".
Both cards start with the heart in a neutral (not liked) state.
Clicking the heart on the successful toggle card must:
- Turn the heart red immediately, before the server responds.
- Keep the heart red after the server confirms the change.
Clicking the heart on the error toggle card must:
- Turn the heart red immediately, before the server responds.
- Revert the heart to neutral after the server responds with an error.
Use the useOptimistic hook together with startTransition to manage the optimistic state.

💡 Notes

addOptimistic must be called inside startTransition — otherwise React warns even though the UI still updates.
The passthrough state only needs to be a boolean (just the like value). The rest of data can stay static.
toggleFavoriteError always throws. A try/catch with console.error prevents the red error overlay in dev without affecting the optimistic revert.
The data-testid attributes in the starter are already wired to the tests — don't rename or remove them.

🧪 Tests

renders the app title
renders both cards with labels
starts with hearts not liked
optimistically toggles the heart immediately and persists on success
reverts the heart on server error

If you've been writing setState(optimisticValue), then try/catch with manual rollbacks, useOptimistic deletes all that boilerplate. Give it a try and feel how snappy your UI can be.

🔥 Start the Challenge Now

🚀 New Challenge: Shopping Cart with Redux

ReactChallenges — Wed, 13 May 2026 16:11:34 +0000

Redux is one of those libraries that makes perfect sense when you read the docs — but feels completely different when you're the one writing the slice, dispatching actions, and watching components react to state changes. Theory gets you started; building gets you fluent.

Ready to code? Try the challenge: Shopping cart with Redux

Let's be honest: for most React applications, Redux is overengineering. With Context and useReducer, you can build a global state solution that's just as capable — less boilerplate, fewer dependencies. But the job market has its own rules. Many teams still use Redux, many codebases were built with it, and many job descriptions list it as a requirement. Knowing Redux isn't about ideology — it's about being ready for the code you'll actually encounter.

This challenge puts you in the driver's seat of a real Redux workflow: you'll build a fully functional shopping cart powered by Redux Toolkit, from the slice logic all the way up to a multi-component React UI.

What you'll build

You'll create a complete shopping cart interface with the following features:

Add products to the cart with quantity tracking
Remove products individually
Update product quantities in real time
Toggle the cart's open/closed state from a global slice
Display a running total derived from the cart state

Ready to code? Try the challenge: Shopping cart with Redux

Looking for more React challenges? Check out all the available challenges at reactchallenges.com — from beginner to advanced, with real test suites that validate your solutions.

Debounce vs Throttle: When to Use Each

ReactChallenges — Tue, 12 May 2026 07:49:22 +0000

Most React developers have faced the problem: a search input that fires an API call on every single keystroke, or a scroll handler that runs hundreds of times per second. It wastes bandwidth, clogs the main thread, and creates a terrible user experience. The fix is straightforward — you need to control how often your functions run.

That's where debounce and throttle come in. They're two related but distinct techniques for limiting function execution frequency. Knowing which one to pick saves you from subtle bugs and performance headaches.

👉 Try it in practice: useDebounce vs useThrottle

Debounce: wait until things settle

Debounce delays execution until a certain amount of time has passed without any new calls. Think of an elevator door — it starts closing, but if someone walks in, it reopens and waits again. The door only actually closes once people stop arriving.

In code, debounce is the go-to choice for search inputs. You don't want to query your API on "r", "re", "rea", "reac", "react". You want to wait until the user stops typing and then make one request.

function useDebounce(value, delay) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebouncedValue(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debouncedValue;
}

Every time value changes, the timer resets. Only when the value stops changing for delay milliseconds does the debounced value update. The cleanup function (clearTimeout) is critical — without it, stale timers accumulate and you get unexpected updates.

Other debounce use cases:

Resize event handlers (wait until the user finishes resizing the browser)
Autosave in text editors (save after the user pauses typing)
Form validation triggered on onChange (validate once, not on every keystroke)

Throttle: guarantee a maximum rate

Throttle works differently. Instead of waiting for things to settle, it guarantees execution at most once within a fixed time window. Think of a revolving door — it lets people through at a controlled, constant rate no matter how many are trying to push in.

Scroll handlers are the classic example. When the user scrolls, the browser fires scroll events at an incredibly high rate — easily 60+ times per second. You rarely need to run logic at that frequency. Throttling to once every 100ms or 200ms keeps the UI smooth while still updating on time.

function useThrottle(value, limit) {
  const [throttledValue, setThrottledValue] = useState(value);
  const lastRan = useRef(Date.now());

  useEffect(() => {
    const elapsed = Date.now() - lastRan.current;

    if (elapsed >= limit) {
      setThrottledValue(value);
      lastRan.current = Date.now();
    } else {
      const timer = setTimeout(() => {
        setThrottledValue(value);
        lastRan.current = Date.now();
      }, limit - elapsed);

      return () => clearTimeout(timer);
    }
  }, [value, limit]);

  return throttledValue;
}

The key difference from debounce: throttle tracks the last execution time and allows a new execution only if enough time has elapsed. It doesn't care whether values are still changing — it just enforces a speed limit.

Other throttle use cases:

Tracking mouse position for tooltips or custom cursors
Handling infinite scroll pagination (trigger a fetch at most once every N milliseconds)
Rate-limiting rapid button clicks (prevent double-submits without disabling the button)

Debounce vs Throttle: side by side

The difference becomes clear when you visualize how each behaves with rapid input:

Technique	Behavior	Analogy	Best for
Debounce	Executes once after activity stops	Elevator door	Search inputs, autosave, validation
Throttle	Executes at a fixed maximum rate	Revolving door	Scroll, resize, mouse tracking

The same input sequence produces different results:

Imagine firing an event 100 times in 1 second. With a debounce of 300ms, the handler runs once (after the last event, provided 300ms passes with no new events). With a throttle of 300ms, the handler runs 3-4 times (roughly once every 300ms during that second).

Common mistakes

Using debounce when you need throttle. A scroll-driven animation debounced at 200ms will look broken — it won't fire at all while the user is scrolling, then it'll jump awkwardly when they stop.

Using throttle when you need debounce. A search input throttled at 300ms sends unnecessary intermediate requests (every 300ms instead of just the final query). The user's network and your API both pay the price.

Not cleaning up timeouts in React. This is the most frequent bug. If your component unmounts while a timeout is pending, setState on an unmounted component triggers React warnings (and in older versions, actual memory leaks). The useEffect cleanup function prevents this.

Forgetting useRef for mutable values. When implementing throttle, you need to track lastRan across renders. Plain variables reset on every render, and useState causes unnecessary re-renders. useRef is the right tool — it persists across renders without triggering updates.

Why custom hooks for this?

You can absolutely import debounce and throttle from lodash or write them as plain utility functions. But wrapping them in hooks gives you something powerful: the delay only affects the debounced/throttled value, not the original source of truth.

Your component keeps an up-to-date value at all times (for immediate UI feedback like showing typed characters in an input), while the debounced/throttled version is used only where needed (for API calls). This separation of concerns is clean, explicit, and prevents the timing logic from leaking across your component.

Going deeper

Most implementations of useDebounce and useThrottle power through the happy path. Real-world usage introduces edge cases worth thinking through:

What happens when the delay changes dynamically? If a user adjusts a slider controlling debounce delay, does your hook handle it gracefully or does it skip updates?
What if value is an object? Reference equality means { query: "react" } will always be "new" — you might want deep comparison or a specific key to watch.
Should the initial value fire immediately? Some debounce implementations let you pass a leading option to trigger on the first call instead of waiting. Tailwind's prefers-reduced-motion equivalent is worth considering for accessibility too.

These are exactly the kind of subtleties that turn a 10-line hook into a 50-line one — and the kind of thing that comes up in code reviews.

👉 Try it in practice: useDebounce vs useThrottle

Stop Fetching Data Sequentially When It Could Be Parallel

ReactChallenges — Sun, 10 May 2026 11:22:19 +0000

Picture this: you fetch a list of items from an API, and for each item you need extra data from a different endpoint. The natural instinct is to loop through the items and fire a request for each one — maybe inside a useEffect, maybe with an await inside a .map. The code works. The data shows up. But if you look at the network tab, every request waits for the one before it, and your loading spinner sits there for seconds longer than it should.

This is sequential fetching of independent data, and it is one of the easiest performance wins you can grab in any frontend app.

👉 Try it in practice: Rick & Morty: Double Fetching

The trap

Imagine you are building a page that displays characters from the Rick & Morty API. The characters come from https://rickandmortyapi.com/api/character/?page=1, and for each character you also want to show the title of their first episode. That episode title lives at character.episode[0] — a separate URL.

Here is the code that feels right but is wrong:

const fetchCharacters = async () => {
  const res = await fetch(`https://rickandmortyapi.com/api/character/?page=1`);
  const data = await res.json();
  const characters = data.results;

  for (const character of characters) {
    const episodeRes = await fetch(character.episode[0]);
    const episodeData = await episodeRes.json();
    character.episodeTitle = episodeData.name;
  }

  return characters;
};

It reads like a recipe: get all characters, then for each character, get their episode. Step by step. But here is the problem: episode 2's data does not depend on episode 1's data. There is zero reason for request 2 to wait for request 1 to finish. And yet, with await inside a for loop, that is exactly what happens.

If you have 20 characters and each episode request takes 200ms, the episode fetching alone takes 4 seconds — 20 requests × 200ms — when it could take 200ms total.

The same trap shows up in other forms. A useEffect that awaits one fetch, then another, then another. Three independent requests that could fire simultaneously, queued up as if they share a dependency. Every await that isn't necessary is a waterfall you are paying for with user time.

The fix: Promise.all

The solution is Promise.all. Instead of awaiting episode requests one by one, fire all of them at once and wait for the group:

const fetchCharacters = async () => {
  const res = await fetch(`https://rickandmortyapi.com/api/character/?page=1`);
  const data = await res.json();
  const characters = data.results;

  const episodePromises = characters.map((character) =>
    fetch(character.episode[0]).then((res) => res.json()),
  );

  const episodes = await Promise.all(episodePromises);

  return characters.map((character, i) => ({
    ...character,
    episodeTitle: episodes[i].name,
  }));
};

Now all 20 episode requests leave the browser at roughly the same time. The total wait is the slowest individual request, not the sum of all of them. For 20 episodes at 200ms each, you go from 4 seconds to about 200ms. That is not a micro-optimization — that is the difference between a sluggish app and a fast one.

Promise.all fails fast: if one request rejects, the whole thing rejects. In a real app you probably don't want a single failed episode to crash the entire character list. A small adjustment handles that gracefully:

const episodes = await Promise.allSettled(
  characters.map((character) =>
    fetch(character.episode[0]).then((res) => res.json()),
  ),
);

const charactersWithEpisodes = characters.map((character, i) => {
  const episode = episodes[i];
  return {
    ...character,
    episodeTitle: episode.status === "fulfilled" ? episode.value.name : "Unknown",
  };
});

Promise.allSettled waits for all promises to complete — whether they succeed or fail — and gives you back the result of each one. One broken request won't take down the rest.

Recognizing the pattern in the wild

Sequential fetching rarely announces itself with a visible for loop. Here are the places it hides:

Chained await in effects. A useEffect that looks like this is a waterfall:

useEffect(() => {
  const user = await fetchUser();        // waits
  const posts = await fetchPosts();      // waits for user
  const settings = await fetchSettings(); // waits for posts
}, []);

If posts and settings don't depend on user, fetch them together:

const [user, posts, settings] = await Promise.all([
  fetchUser(),
  fetchPosts(),
  fetchSettings(),
]);

Nested .then() instead of Promise.all. This:

fetch("/api/products")
  .then((products) => {
    products.forEach((p) => {
      fetch(`/api/reviews/${p.id}`).then((reviews) => {
        // one by one, sequentially
      });
    });
  });

Should be:

const products = await fetch("/api/products").then((r) => r.json());
const reviews = await Promise.all(
  products.map((p) => fetch(`/api/reviews/${p.id}`).then((r) => r.json())),
);

Accidental serial in server components. A React Server Component that does:

const user = await db.query("SELECT * FROM users WHERE id = $1", [id]);
const orders = await db.query("SELECT * FROM orders WHERE user_id = $1", [id]);

If the database can handle concurrent queries, fire them together:

const [user, orders] = await Promise.all([
  db.query("SELECT * FROM users WHERE id = $1", [id]),
  db.query("SELECT * FROM orders WHERE user_id = $1", [id]),
]);

When sequential is actually correct

Not everything should be parallel. The rule is simple: if request B needs data from request A, await A first. A search endpoint that returns results from a query, followed by a detail endpoint that needs the ID from the first result — that chain is necessary.

Also, some APIs have rate limits. Sending 100 parallel requests to a third-party API that caps you at 10 per second will get you blocked. In those cases, batch your requests or use a concurrency limiter. But don't pre-optimize for rate limits you don't have. Most internal APIs, public APIs like Rick & Morty, and your own backend can handle parallel requests just fine.

One more thing: loading state

With sequential fetching, you can naively show a loading indicator and it sort of works — the spinner just stays longer than it should. With parallel fetching, you want to be more deliberate about what "loading" means. Show a skeleton or a list of placeholders while the character list loads. Then, as episode titles arrive, fill them in gradually or all at once with Promise.all. The user sees content faster, even if some details take an extra moment.

The important shift is keeping the character list and the episode titles in a single state update. If you set characters first and then update each one with its episode title, you trigger unnecessary re-renders and risk showing incomplete data. Resolve everything together, then set state once:

const [characters, setCharacters] = useState([]);
const [loading, setLoading] = useState(false);

async function load() {
  setLoading(true);
  const chars = await fetchCharacters();      // fetches + episodes in parallel
  setCharacters(chars);                        // single state update
  setLoading(false);
}

This might seem obvious, but it is easy to mess up when the fetches are split across different functions or hooks. Resolve all independent data, then commit to state.

The performance cost of sequential fetching is invisible during development — local APIs respond in milliseconds. But on a slow 3G connection or a cold serverless function start, those waterfalls add up into seconds. Recognizing when data doesn't depend on other data, and fetching it accordingly, is one of the highest-leverage skills you can build as a frontend developer.

👉 Try it in practice: Rick & Morty: Double Fetching — fix sequential episode fetching and see the difference in the network tab.