DEV Community: ReactChallenges

🚀 New React Challenge: Calendar Events

ReactChallenges — Wed, 26 Aug 2026 11:27:51 +0000

🧩 Overview

Build a calendar that renders events on their days, supports selecting a day, and lets you add and delete events — practicing state management and data transformation keyed by absolute date strings.

👉 https://www.reactchallenges.com/challenges/calendar-events

✅ Requirements

Select a day by clicking it, highlighting the selected cell.
Show the events of the selected day in a panel below the calendar, including a heading with the selected date.
Add a new event via a text input and an "Add" button; empty or whitespace-only titles are ignored.
Delete an event from the selected day via its delete button.
Show a "no events" message for a selected day without events.
Keep events intact when navigating between months — events are keyed by absolute YYYY-MM-DD dates.
Show an event dot on every day that has at least one event.

💡 Notes

Components and the month-grid logic are already wired — your job is the events state: events, the selected day, filtering, and add/delete.
Pass your events to buildMonthDays(date, events) and the dots appear automatically.
Filter events per day by comparing each event's date to the selected day; this keeps events stable across month navigation.

🧪 Tests

Does not show dots on a day without events
Selecting a day highlights it
Shows the selected date in the panel heading
Adds a new event via the Add button
Adds a new event when pressing Enter
Ignores empty titles when adding
Shows a dot on the day of a newly added event
Supports multiple events on the same day
Shows only the events of the selected day
Deletes an event from the selected day
Keeps events when navigating between months

Whether you're prepping for interviews or sharpening your state skills, this is a compact, satisfying build — the calendar is already done, so you can focus entirely on managing events like a pro.

🔥 Start the Challenge Now

🚀 New React Challenge: Calendar

ReactChallenges — Thu, 20 Aug 2026 17:00:37 +0000

We all reach for a date library the moment a calendar shows up in a feature request. But underneath every grid is plain JavaScript — counting days, offsetting weekdays, and rolling years over. This challenge drops the library and puts you in charge.

🧩 Overview

The calendar components are already provided, so your job is the logic: render the correct days, highlight today, navigate between months, and handle leap years with plain JavaScript date math.

👉 https://www.reactchallenges.com/challenges/calendar

✅ Requirements

• Render the app title "Calendar" and the weekday header (Mon through Sun).
• Show the current month and year in the header (e.g. August 2026).
• Render the correct number of days for the selected month (28, 29, 30, or 31).
• Place the 1st day of the month in the correct weekday column.
• Fill empty cells with days from the previous and next month so the grid always completes full weeks, dimming those days visually.
• Navigate to the previous and next month.
• Highlight the current day (today) in the grid.
• Change the year correctly when navigating past December or before January.
• Handle leap years correctly (February has 29 days in a leap year, 28 otherwise).

💡 Notes

• new Date(year, month + 1, 0).getDate() returns the number of days in a month — leap years included.
• The week starts on Monday, so the leading offset for the 1st day is (getDay() + 6) % 7.
• new Date(year, month + offset, 1) rolls the year over automatically when navigating past December or January.

🧪 Tests

renders the app title
renders the seven weekday labels
shows the current month and year in the header
renders the correct number of days for the current month
places the 1st day on the correct weekday
fills the grid with days from the previous and next month
navigates to the next month
navigates to the previous month
changes the year when navigating past December
changes the year when navigating before January
highlights today's date
does not highlight any day when viewing another month
renders 28 days for February in a non-leap year
renders 29 days for February in a leap year
renders 30 days for a 30-day month
uses five weeks when the month fits in five

You'll walk away confident counting days, offsetting weekdays, and handling leap years without a single dependency. 16 tests will tell you exactly where your grid breaks.

🔥 Start the Challenge Now

🚀 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