DEV Community: ReactChallenges

🚀 New React Challenge: GitHub Contribution Heatmap

ReactChallenges — Wed, 05 Aug 2026 08:24:32 +0000

Fetching data in React without a library means juggling useEffect, abort controllers, isLoading booleans, error state, and cache invalidation — all by hand. SWR, TanStack Query, and RTK Query solve all of that out of the box. This challenge has the grid and components pre-built — your job is to wire up SWR and bring the GitHub-style heatmap to life.

🧩 Overview

Fetch contribution data for a GitHub-style heatmap using SWR. The grid and components are already built — you wire up data fetching with loading skeletons, error handling, and year navigation to make it work.

👉 https://www.reactchallenges.com/challenges/github-contribution-heatmap

✅ Requirements

Fetch contribution data from https://example-heatmap?year={year}
Write a custom fetcher that checks res.ok, parses the error body, and throws on failure — SWR won't know a request failed unless the fetcher throws
Display a loading skeleton while data is being fetched
Display an error skeleton with the server's error message when the request fails
Display the heatmap grid with flattened contributions on success
Allow switching between years (2023–2026) with interactive buttons
Highlight the currently selected year button
Calculate the offset so January 1st aligns with the correct weekday column

💡 Notes

contributions is a 2D array (weeks × days) — flatten it with .flat() before passing to HeatmapGrid
The mock API has a random 300-500ms delay and fails ~20% of the time
The custom fetcher pattern is universal: SWR, TanStack Query, and RTK Query all require you to throw on non-ok responses
The data is from Linus Torvalds' real GitHub contributions — every cell reflects actual commits, merges, and pull requests

🧪 Tests

Renders the app title
Shows skeleton while loading
Displays heatmap grid with contributions when data loads
Shows skeleton with error when request fails
Highlights 2026 as the selected year button
Fetches new data when switching to a different year
Aligns January 1st to the correct weekday for each year

Whether you're new to SWR or already using TanStack Query, this challenge reinforces the fetch-then-render pattern that every production React app relies on. Plus, you get to see Linus Torvalds' actual commit history rendered as a heatmap — pretty cool.

🔥 Start the Challenge Now

Typing Polymorphic React Components in TypeScript

ReactChallenges — Wed, 29 Jul 2026 13:33:00 +0000

I recently came across an interview question about advanced TypeScript patterns, specifically how to type a Button component that can also render as a link. These are the kinds of concepts that are easy to forget, especially if you don't write as much code by hand anymore because AI handles a lot of it.

That's why it's worth revisiting them from time to time. One of the best ways to check whether you truly understand a concept is to explain it to yourself and honestly ask whether someone else could understand that explanation. So here we are.

Everything optional

Everything is optional, so TypeScript can't infer whether this component should behave as a button or a link. Since there is no relationship between the props, invalid combinations are allowed.

type Props = {
  href?: string;
  target?: string;
  type?: "button" | "submit" | "reset";
  disabled?: boolean;
  onClick?: () => void;
};

function Button(props: Props) {
  if (props.href) {
    return <a {...props} />;
  }

  return <button {...props} />;
}

<Button href="#" disabled />; // ✅ No TypeScript error

Union types

TypeScript says:

"I have a value whose type is LinkProps | ButtonProps. I'll check whether it matches one of the union members."

type LinkProps = {
  href: string;
  target?: string;
  onClick?: () => void;
};

type ButtonProps = {
  type?: "button" | "submit" | "reset";
  disabled?: boolean;
  onClick?: () => void;
};

type Props = LinkProps | ButtonProps;

function Button(props: Props) {
  if ("href" in props) {
    return <a {...props} />;
  }

  return <button {...props} />;
}

<Button href="#" disabled />; // ❌ Property 'disabled' does not exist on type 'LinkProps'

Discriminated unions

Sometimes you don't want to infer the rendered element from the props. Instead, you want the user to choose it explicitly.

TypeScript says:

"I have a value whose type is LinkProps | ButtonProps. I'll use the as property to determine which one it is."

type LinkProps = {
  as: "a";
  href: string;
  target?: string;
  onClick?: () => void;
};

type ButtonProps = {
  as: "button";
  type?: "button" | "submit" | "reset";
  disabled?: boolean;
  onClick?: () => void;
};

type Props = LinkProps | ButtonProps;

function Button(props: Props) {
  if (props.as === "a") {
    return <a {...props} />;
  }

  return <button {...props} />;
}

<Button as="button" href="#" />; // ❌ Property 'href' does not exist on type 'ButtonProps'

Generic polymorphic components

In React 19+, the recommended utility type is React.ComponentProps<T>.

It gives you all the props supported by the element or component represented by T.

type Props<T extends React.ElementType> = {
  as?: T;
} & React.ComponentProps<T>;

function Button<T extends React.ElementType = "button">(props: Props<T>) {
  const { as, ...rest } = props;

  const Component = as ?? "button";

  return <Component {...rest} />;
}

Note: In production code you'll often see Omit<React.ComponentProps<T>, "as"> instead of React.ComponentProps<T>. This removes any existing as prop from the rendered component. Since HTML elements like "button" and "a" don't define an as prop, the simplified version used here is sufficient.

Now TypeScript automatically infers the correct props based on the value of as:

<Button as="a" href="#" /> // ✅
<Button as="button" disabled /> // ✅

<Button as="button" href="#" /> // ❌
<Button as="a" disabled /> // ❌

Note: If you're using React 18 or earlier, use React.ComponentPropsWithoutRef<T> instead. Before React 19, ref wasn't treated as a normal prop for function components, so excluding it was usually the correct choice.

React.ComponentProps<T> is equivalent to saying:

"Give me all the props that the element or component T accepts."

Unlike union types, there's no need to manually define every possible combination (LinkProps | ButtonProps | ...). The props are computed directly from the generic type T, making the component scalable to any HTML element or custom React component.

🚀 New React Challenge: useEffect vs useLayoutEffect

ReactChallenges — Wed, 22 Jul 2026 16:16:37 +0000

You've used useEffect a thousand times. But did you know it runs after the browser paints? That means if you're measuring the DOM to position an element, users will see a flicker — the element renders at the wrong position, then snaps into place. useLayoutEffect fixes that by running before paint. This challenge proves it with a tooltip.

🧩 Overview

A tooltip component needs to center itself by measuring its own width. The starter uses useEffect, causing a visible flicker — the tooltip appears uncentered for a moment before snapping to the middle. Replace it with useLayoutEffect and the measurement happens before the browser paints, giving you a perfect first frame.

👉 https://www.reactchallenges.com/challenges/use-effect-vs-use-layout-effect

✅ Requirements

Replace useEffect with useLayoutEffect in the TooltipContent component so the tooltip is centered before the browser paints, avoiding the flicker.

💡 Notes

useLayoutEffect runs before paint — use it for DOM measurements.
useEffect runs after paint — use it for logging, subscriptions, and side effects that don't affect layout.
Pro tip: if the flicker is too fast to see, enable CPU throttling (4x or 6x) in DevTools → Performance tab.

🧪 Tests

Uses useLayoutEffect for the DOM measurement

This is one of those hooks that doesn't come up often — but when it does, knowing the difference between useEffect and useLayoutEffect is the difference between a polished UI and a janky one. A single line change, a world of difference.

🔥 Start the Challenge Now

🚀 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