DEV Community: ReactChallenges

🚀 New React Challenge: Undo / Redo

ReactChallenges — Wed, 07 Oct 2026 09:04:45 +0000

Most apps let users make changes but never let them take them back. This challenge is about building the mechanism that changes everything: a history you can rewind.

🧩 Overview

Build a notes editor whose add, edit, toggle, and delete actions are tracked in a useReducer past/present/future history, so every change can be undone and redone with buttons or keyboard shortcuts.

👉 https://www.reactchallenges.com/challenges/undo-redo

✅ Requirements

The list starts with the notes "Buy groceries" and "Walk the dog".
Each note is editable through an input.
Each note has a done toggle and a delete button.
Undo and redo are disabled on first render.
Adding a note appends it to the list and clears the new-note field.
A change enables undo; undoing restores the previous list, disables undo when there is nothing left to undo, and enables redo.
Redo reapplies an undone change and disables itself once there is nothing left to redo.
Adding, editing, toggling, and deleting a note can each be undone.
An undone change can be redone.
Consecutive edits to the same note collapse into a single undo step.
An edit that does not change the text is ignored and adds no history.
Adding an empty or whitespace-only note is ignored and adds no history.
Undo is triggered by Cmd/Ctrl+Z.
Redo is triggered by Shift+Ctrl+Z.
Pressing undo with no history or redo with nothing to redo leaves the list unchanged.
The status line reports how many undo and redo steps are available.
New notes always get unique identifiers, even after undoing and adding again.
Making a new change after undoing clears the redo stack.

💡 Notes

The history shape most people reach for is { past, present, future }: present is what renders, while past and future are stacks of snapshots.
Return the same state object for a no-op (a blank note, an edit that doesn't change the text, undo/redo with an empty stack) so React bails out and history stays clean.
Keep the id counter outside the history — rewinding it on undo would let two different notes share an id.

🧪 Tests

renders the initial notes
disables undo and redo on load
adds a note and clears the input
enables undo after a change and disables it again after undoing
redoes an undone change
undoes a deletion and restores the note
undoes a toggle and restores the previous state
undoes an edit and restores the previous text
collapses continuous edits to one note into a single undo step
ignores an edit that does not change the text
does not push history when adding an empty note
does not push history when adding a whitespace-only note
undoes with Ctrl+Z
undoes with Cmd+Z
redoes with Shift+Ctrl+Z
does nothing when undo is pressed with no history
does nothing when redo is pressed with no future
reports the available undo and redo steps
keeps note identifiers unique after undo and redo
clears the redo stack when a new change is made

Work through it and you'll come away knowing how to model reversible state with a reducer — a skill that shows up everywhere from text editors to form builders to drag-and-drop canvases.

🔥 Start the Challenge Now

🚀 𝗡𝗲𝘄 𝗥𝗲𝗮𝗰𝘁 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲: Virtualized List

ReactChallenges — Wed, 30 Sep 2026 11:46:25 +0000

Ever hit a wall when a list grows to thousands of rows and React starts to choke? Mounting 10,000 DOM nodes at once is the problem — rendering only what fits on screen is the fix.

🧩 Overview

Build a virtualized list of 10,000 contacts that mounts only the rows visible in the scroll viewport (plus a small overscan), using fixed row heights and windowing math.

👉 https://www.reactchallenges.com/challenges/virtualized-list

✅ Requirements

Render a virtualized directory of 10,000 contacts.
Mount only a small window of rows — far fewer than the 10,000 in the dataset.
Scroll through the entire dataset, not just the mounted rows.
Size the scrollable area to the full dataset so the scrollbar spans the whole list.
Unmount rows that leave the viewport and mount the ones that enter it.
Keep a few overscan rows above and below the visible window.
Show the first and last mounted rows in a stats line: Showing X–Y of 10000.
Display each contact's name and email in its row.

💡 Notes

Put all the windowing logic in App.tsx: track scrollTop, measure the viewport's clientHeight, and compute the range of rows to mount.
Measure the viewport height in a layout effect — it's the moment the layout is ready.
Clamp the range so overscan never renders rows before the first or after the last contact.

🧪 Tests

Renders the app title
Only mounts a small window of rows, not the whole dataset
Renders the first contacts on load
Sizes the scrollable area to the full dataset
Shows the first and last rendered rows in the stats
Renders more rows than fit on screen (overscan)
Shows the name and email for each mounted row
Moves the window down when scrolling
Restores the first rows when scrolling back to the top
Renders the last contact when scrolled to the bottom
Mounts overscan rows above the visible window when scrolled
Never renders rows above the first one

This challenge is a hands-on way to understand virtualization from scratch — the exact pattern behind every serious long-list library. Practice windowing math, useLayoutEffect, and derived rendering, and your lists will stop freezing for good.

🔥 Start the Challenge Now

🚀 New React Challenge: OTP Input

ReactChallenges — Wed, 23 Sep 2026 12:00:08 +0000

One-time-password inputs look simple until you try to build one. Auto-advancing focus, paste handling, and keyboard navigation all have to work together — and that's exactly what this challenge asks you to wire up.

🧩 Overview

Build a six-field OTP input that moves focus as you type, accepts a pasted code, and validates it against a demo code.

👉 https://www.reactchallenges.com/challenges/otp-input

✅ Requirements

Six single-character inputs are rendered, one per digit.
The first input is focused on mount.
Typing a digit fills the focused input and moves focus to the next input.
Non-numeric characters are ignored.
Backspace clears the current digit and stays in place.
Backspace on an already-empty input clears the previous digit and moves focus to it.
ArrowLeft and ArrowRight move focus between inputs.
Pasting a code fills the inputs with the pasted digits; digits beyond six are ignored.
The status text reads "Waiting for code…" while the code is incomplete.
When all six digits are filled and match the demo code, the status reads "Code verified".
When all six digits are filled but do not match, the status reads "Invalid code. Try again."
The reset button clears all inputs, refocuses the first input, and resets the status.

💡 Notes

The six inputs are controlled: whatever logic you run in the change handler decides what actually sticks in state, so invalid characters never persist.
You need to move focus between inputs imperatively — plan how to keep a reference to each field.
A single interaction can deliver more than one digit at once (pasting a full code), not just one keypress.
Call preventDefault() on the keyboard and paste handlers so the browser doesn't also move the caret or insert text on its own.
Prefer deriving the status from the current values instead of storing it as separate state that can drift out of sync.

🧪 Tests

renders six inputs
focuses the first input on mount
renders the demo code
types a digit and moves focus to the next input
ignores non-numeric characters
backspace clears the current digit and stays in place
backspace on an empty input clears the previous digit
arrow keys move focus between inputs
pastes the demo code and verifies it
shows an error for a wrong code
truncates extra digits when pasting more than six
reset clears the inputs and refocuses the first

Mastering imperative focus management and derived state in a tiny, familiar UI. That's the skill this challenge leaves you with — useful every time you build auth, 2FA, or payment flows.

🔥 Start the Challenge Now

Context API vs Redux

ReactChallenges — Sun, 20 Sep 2026 11:36:50 +0000

The question is usually framed as "which one is better", but that's the wrong question. Context and Redux do different jobs. The important part is understanding how each one updates its consumers.

👉 Try it in practice: Shopping Cart with Context

What Context actually does

Context lets a component read and subscribe to a value without threading it down through props. The context object itself does not hold data; it only describes what can be provided and read. To make the value change, you pair the provider with useState or useReducer.

const ThemeContext = createContext("light");

function App() {
  const [theme, setTheme] = useState("light");
  return (
    <ThemeContext value={theme}>
      <Page />
    </ThemeContext>
  );
}

The key detail, from the React docs: when the value you pass to a provider changes, React re-renders every component that reads that context. It compares the old and new values with Object.is. There are no selectors, so you can't subscribe to just one field of the value.

What Redux adds

Redux is a centralized store with a single flow: action, reducer, store. Around that flow you get middleware, Redux DevTools, and an action history, so you can answer "when did this slice change and where did the data come from?".

Its real advantage over Context is useSelector. A component subscribes to the result it selects, not to the whole store:

const count = useSelector((s) => s.cart.items.length);
const theme = useSelector((s) => s.theme.mode);

Change cart and the component reading theme does not re-render. With Context, it would.

The re-render difference

A Context subscription is to the context value as a whole, not to individual fields. Put { user, cart, theme } in a single context and changing cart re-renders the component that only reads theme too. You can fix this by splitting into multiple contexts and memoizing values, but that's work you do by hand. Redux gives you granular subscriptions through selectors.

When to use each

Context for simple shared values with few consumers: theme, locale, current user, and state scoped to one feature. Zero dependencies.

Redux when shared client state gets large, is used in many places, or has update logic that's getting complex. It also helps when you need to inspect how state changes over time with Redux DevTools.

Data fetched from an API is server state and belongs in SWR or React Query, not in either of these.

A real example: the shopping cart

A cart with a few items, a header badge, and a checkout button is fine in Context.

Watch what happens as it grows: a coupon field, a quantity stepper, a "save for later" list. Now items, coupon, and saved share one context. Updating items re-renders the coupon and saved consumers too. Put the coupon draft in that same context and every keystroke re-renders the header badge.

That's where selectors earn their keep: components can subscribe to different slices of state independently, and a component re-renders only when the piece it reads changes. Redux DevTools and action history are the bonus on top.

Start with Context. Reach for a store when the state and its consumers get complex enough to justify it, not before.

👉 Build both and compare: Shopping Cart with Redux

🚀 New React Challenge: Command Palette

ReactChallenges — Wed, 16 Sep 2026 10:08:15 +0000

Search bars are fine until someone hits Cmd/Ctrl+K. A command palette replaces hunting through menus with a keyboard-first layer that filters as you type — and building one forces you to combine global keyboard handling, focus management and correct ARIA semantics in a single component.

🧩 Overview

Build a keyboard-driven command palette (Cmd/Ctrl+K) with fuzzy filtering, arrow-key navigation, a focus trap and proper combobox/listbox semantics.

👉 https://www.reactchallenges.com/challenges/command-palette

✅ Requirements

The palette is hidden on first render.
Clicking the trigger opens the palette.
Pressing Cmd/Ctrl+K opens the palette, and pressing it again closes it.
Pressing Escape closes the palette.
Clicking the backdrop closes the palette, while clicking inside the panel keeps it open.
When the palette opens, the search input receives focus and is empty.
The palette lists every command.
Typing filters the commands by fuzzy match: every character of the query must appear in the label in order, ignoring case.
When nothing matches, show No results for "<query>".
Clearing the query restores the full list.
The first command is highlighted when the palette opens and whenever the query changes.
ArrowDown moves the highlight to the next command, wrapping from the last one to the first.
ArrowUp moves the highlight to the previous command, wrapping from the first one to the last.
Enter executes the highlighted command and closes the palette.
Clicking a command executes it and closes the palette.
Executing a command sets the Last action text to that command's label.
While the palette is open, focus stays inside it when pressing Tab.

💡 Notes

Open and close from a single window keydown listener for Cmd/Ctrl+K and Escape, and call preventDefault().
Filter by subsequence, not includes ("gch" matches "Go to Challenges"), and reset activeIndex when the query changes.
Focus the input on open and keep focus trapped inside the panel by listening for focusin.

🧪 Tests

keeps the palette hidden on first render
opens the palette when the trigger is clicked
opens the palette with Cmd/Ctrl+K
focuses the search input when opened
closes the palette when the shortcut is pressed again
closes the palette on Escape
closes the palette when the backdrop is clicked
keeps the palette open when clicking inside the panel
renders every command
filters commands as the user types
matches non-contiguous characters
is case-insensitive
shows a no-results message when nothing matches
restores the full list when the query is cleared
clears the query when the palette is reopened
highlights the first command by default
moves the highlight down with ArrowDown
wraps from the first to the last with ArrowUp
wraps from the last to the first with ArrowDown
resets the highlight when the query changes
executes the highlighted command with Enter
executes a command when clicked
traps focus inside the palette on Tab

If you want to practice keyboard-driven UI the way real apps do it, this challenge gives you the full loop: open, filter, navigate, execute and trap focus — with 23 tests to keep you honest.

🔥 Start the Challenge Now

5 common TypeScript interview questions

ReactChallenges — Thu, 10 Sep 2026 09:40:33 +0000

These five questions show up in almost every TypeScript interview. They're not tricky syntax puzzles. They test whether you understand the type system well enough to use it on purpose instead of just making the compiler happy.

`any` vs `unknown`

any turns type checking off. Once a value is any, TypeScript stops protecting you and mistakes slip through until runtime. unknown is the safe counterpart: it can hold anything, but you must narrow it before using it.

const a: any = "hello";
a.toUpperCase(); // ✅ no error
a.thisDoesNotExist(); // ✅ no error either 💀

const u: unknown = "hello";
u.toUpperCase(); // ❌ 'u' is of type 'unknown'

if (typeof u === "string") {
  u.toUpperCase(); // ✅ narrowed to string
}

Reach for unknown when the type is genuinely unknown, like API responses, JSON.parse, or catch variables, and never reach for any.

`interface` vs `type`

Both describe object shapes and are mostly interchangeable. The real differences are what each one can express.

interface supports declaration merging; type doesn't.
type can express unions, intersections, tuples, and primitives; interface only describes object-like shapes.
interface extends with extends; type composes with &.

interface User {
  name: string;
}
interface User {
  age: number;
} // merged: { name: string; age: number }

type Id = string | number; // only possible with type

Declaration merging cuts both ways: it lets libraries augment existing types (like extending Window), but it can also merge a typo into a valid type. A common convention is interface for object APIs and type for unions and computed types.

Generics

Generics let you write code that works with many types while preserving the relationship between input and output. Without them you'd duplicate the function per type or fall back to any and lose the return type.

function first<T>(items: T[]): T | undefined {
  return items[0];
}

const n = first([1, 2, 3]); // number | undefined
const s = first(["a", "b"]); // string | undefined

You can constrain them when you need to rely on some structure:

function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}

const user = { id: 1, name: "Alice" };

getProperty(user, "name"); // ✅ string
getProperty(user, "age"); // ❌ "age" is not assignable to keyof typeof user

The definition is easy to recite. The interview signal is being able to show a case where a generic removed duplication or a lost type.

Utility types

Partial, Pick, Omit, and Record are built-in generics. They're not magic, but mapped types that transform an existing type into a new one.

type User = { id: string; name: string; email: string };

type PartialUser = Partial<User>; // every property optional
type UserPreview = Pick<User, "id" | "name">; // only id and name
type UserWithoutEmail = Omit<User, "email">; // everything except email
type UsersById = Record<string, User>; // { [key: string]: User }

Under the hood, Partial is roughly this:

type Partial<T> = { [K in keyof T]?: T[K] };

Knowing the mapping is what separates "I know they exist" from "I know how to build my own".

Type guards

A type guard is an expression that gives TypeScript information it can use to narrow a broader type into a more specific one within a block. Common narrowing checks include typeof, instanceof, in, and equality checks.

function format(value: string | number) {
  if (typeof value === "string") {
    return value.toUpperCase(); // string
  }
  return value.toFixed(2); // number
}

When you want to reuse a check across your code, wrap it in a named type guard using a type predicate (x is T):

type Cat = { meow: () => void };
type Dog = { bark: () => void };

function isCat(animal: Cat | Dog): animal is Cat {
  return "meow" in animal;
}

Now TypeScript can narrow the type when you call the guard:

function speak(animal: Cat | Dog) {
  if (isCat(animal)) {
    animal.meow(); // Cat
  } else {
    animal.bark(); // Dog
  }
}

The animal is Cat return type is a contract: TypeScript trusts it and narrows animal to Cat when the function returns true.

That means the logic inside the guard is your responsibility. If the predicate is wrong, TypeScript won't catch the resulting bug.

🚀 New React Challenge: Infinite Scroll

ReactChallenges — Wed, 09 Sep 2026 09:53:24 +0000

"Load more" buttons are the easy way out. Real feeds — Twitter, Instagram, your chat app — load the next page the moment you scroll near the bottom. That magic is the Intersection Observer API, and it's much cleaner than the old scroll-listener + throttle dance.

This challenge gets you building an infinite scroll list of Rick & Morty characters with React 19's Suspense-driven use() fetching already in place. Your job: make the next page fetch itself.

🧩 Overview

Build an infinite scroll list of Rick and Morty characters using the Intersection Observer API — the next page is fetched automatically when a sentinel element enters the viewport, building on an existing use() + Suspense data-fetching setup.

👉 https://www.reactchallenges.com/challenges/infinite-scroll

✅ Requirements

Keep the starter's use() + Suspense first-page fetch as the starting point
Follow the API pagination and read the next page URL from data.info.next
Load the next page automatically when the user scrolls to the bottom — no button
Trigger the load from a sentinel element observed by the Intersection Observer
Append new characters to the existing list instead of replacing them
Show a loading indicator while the next page is being fetched
Hide the loading indicator once the page finishes loading
Show an end-of-list message when there are no more pages
Stop fetching once the end is reached — no requests when info.next is null
Disconnect the observer when the component unmounts

💡 Notes

App is fully wired: title, layout, and the Suspense fallback are done — all your work happens inside Characters().
The components file is read-only, and the API follows the classic { info: { next, prev }, results: [...] } Rick & Morty response shape.
Watch out: a couple of tests pass with the starter code simply because nothing fetches yet — they only start validating real behavior once your observer is in place.

🧪 Tests

renders the app title
shows skeleton while loading
renders first-page characters after loading
observes the sentinel element
loads the next page when the sentinel enters the viewport
appends characters instead of replacing them
loads the third page on repeated intersections
shows a loading indicator while fetching the next page
hides the loading indicator once the next page loads
shows end of list when there are no more pages
does not fetch again once the end is reached
disconnects the observer on unmount

Infinite scroll is one of those tasks that shows up again and again in frontend interviews and real products.

🔥 Start the Challenge Now

🚀 New React Challenge: Roll dices

ReactChallenges — Wed, 02 Sep 2026 08:29:15 +0000

Most of us write Math.floor(Math.random() * n) on autopilot and only realize later that the boundaries are wrong — inclusive when you wanted exclusive, or off by one. This challenge replaces that guesswork with practice: build a dice roller and three random number generators where getting the range right is the whole point.

🧩 Overview

Build a dice roller app plus three random number generators, practicing how to convert Math.random() into random integer values across different ranges.

👉 https://www.reactchallenges.com/challenges/roll-dices

✅ Requirements

A form with an input that defaults to 3 and only accepts values between 1 and 6, submitted with a Roll button.
On submit, roll as many dice as the input value — rendering one Dice component per dice, each showing a random value between 1 and 6.
Add three random number generators, each with its own Roll button and a result display, producing random integers:
- Between -10 and 10, both included.
- Between 7 and 14, both not included.
- Between 0 and 255, both included.

💡 Notes

A Dice.tsx component is provided and read-only, so you can focus on state and logic instead of markup.

🧪 Tests

Default input value is 3
Does not roll more than 6 dice
Does not roll fewer than 1 dice
Clicking roll renders a number of dice equal to the input value
Random values map to valid dice faces
First random generator returns values between -10 and 10, both included
Second random generator returns values between 8 and 13, both not included
Third random generator returns values between 0 and 255, both included

If you have ever doubted whether your random range formula is right, this is a quick, test-driven way to lock it in. You'll finish confident mapping Math.random() to any range — and rendering a list of components from state while you are at it.

🔥 Start the Challenge Now

🚀 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.

DEV Community: ReactChallenges

🚀 New React Challenge: Undo / Redo

🧩 Overview

✅ Requirements

💡 Notes

🧪 Tests

🚀 𝗡𝗲𝘄 𝗥𝗲𝗮𝗰𝘁 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲: Virtualized List

🧩 Overview

✅ Requirements

💡 Notes

🧪 Tests

🚀 New React Challenge: OTP Input

🧩 Overview

✅ Requirements

💡 Notes

🧪 Tests

Context API vs Redux

What Context actually does

What Redux adds

The re-render difference

When to use each

A real example: the shopping cart

🚀 New React Challenge: Command Palette

🧩 Overview

✅ Requirements

💡 Notes

🧪 Tests

5 common TypeScript interview questions

any vs unknown

interface vs type

Generics

Utility types

Type guards

🚀 New React Challenge: Infinite Scroll

🧩 Overview

✅ Requirements

💡 Notes

🧪 Tests

🚀 New React Challenge: Roll dices

🧩 Overview

✅ Requirements

💡 Notes

🧪 Tests

🚀 New React Challenge: Calendar Events

🧩 Overview

✅ Requirements

💡 Notes

🧪 Tests

🚀 New React Challenge: Calendar

🧩 Overview

✅ Requirements

💡 Notes

🧪 Tests

🚀 New React Challenge: GitHub Contribution Heatmap

🧩 Overview

✅ Requirements

💡 Notes

🧪 Tests

Typing Polymorphic React Components in TypeScript

Everything optional

Union types

Discriminated unions

Generic polymorphic components

`any` vs `unknown`

`interface` vs `type`