DEV Community: ReactChallenges

🚀 New Challenge: Shopping Cart with Redux

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

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

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

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

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

What you'll build

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

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

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

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

Debounce vs Throttle: When to Use Each (and Why It Matters)

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

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

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

👉 Try it in practice: useDebounce vs useThrottle

Debounce: wait until things settle

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

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

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

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

  return debouncedValue;
}

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

Other debounce use cases:

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

Throttle: guarantee a maximum rate

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

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

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

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

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

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

  return throttledValue;
}

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

Other throttle use cases:

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

Debounce vs Throttle: side by side

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

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

The same input sequence produces different results:

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

Common mistakes

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

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

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

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

Why custom hooks for this?

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

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

Going deeper

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

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

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

👉 Try it in practice: useDebounce vs useThrottle

Stop Fetching Data Sequentially When It Could Be Parallel

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

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

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

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

The trap

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

Here is the code that feels right but is wrong:

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

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

  return characters;
};

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

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

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

The fix: Promise.all

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

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

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

  const episodes = await Promise.all(episodePromises);

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

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

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

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

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

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

Recognizing the pattern in the wild

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

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

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

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

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

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

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

Should be:

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

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

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

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

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

When sequential is actually correct

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

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

One more thing: loading state

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

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

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

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

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

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

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

You Probably Don't Need Redux Yet

ReactChallenges — Fri, 08 May 2026 09:26:43 +0000

When you start learning React, the list of things to cover feels endless: components, props, state, hooks, effects, routing. And somewhere in that list, usually right after you figure out useState, someone mentions Redux or Zustand. The implication is clear: if your app is going to be serious, you need a global state management library.

But here is the thing: you can skip it at first. Not because these libraries are bad — they aren't — but because most of the state in your app doesn't belong to them in the first place.

👉 Try it in practice: Shopping Cart

Most state is server state

Think about the data flowing through a typical app. A list of products, a user profile, search results, a dashboard with metrics. Where does it come from? An API. Where does it go when you update it? Back to the API.

This is server state — data you fetch, mutate, and cache, but that you don't own. Its source of truth lives on a server. And managing it with a global client store means you are now responsible for cache invalidation, refetching on focus, optimistic updates, and deduplication — all problems that libraries like SWR or React Query (TanStack Query) solve out of the box.

With SWR, a product list becomes a single hook:

const { data: products, isLoading } = useSWR("/api/products", (url: string) =>
  fetch(url).then((res) => res.json()),
);

No store. No reducers. No dispatching a FETCH_PRODUCTS_SUCCESS action. The hook handles loading, caching, refetching, and error state. And if you need to update a product, mutate revalidates the data automatically. The state you used to push through a global store is now handled declaratively.

What is left? Local state and context

Once you pull all server data into SWR, what remains on the client side? Usually very little. A sidebar that expands and collapses. A modal that opens and closes. A selected tab in a filter bar. Maybe a theme toggle.

These are toggles. useState is enough for every single one of them. Create it close to where it is used:

function Sidebar() {
  const [isOpen, setIsOpen] = useState(false);
  // ...
}

If the toggle needs to be read three levels down the tree, you might be tempted to reach for a global store. But React gives you context for exactly this: sharing state across a subtree without prop drilling.

const CartContext = createContext<CartState | null>(null);

function CartProvider({ children }: { children: React.ReactNode }) {
  const [items, setItems] = useState<Item[]>([]);

  function addItem(item: Item) {
    setItems((prev) => [...prev, item]);
  }

  return (
    <CartContext.Provider value={{ items, addItem }}>
      {children}
    </CartContext.Provider>
  );
}

Wrap the part of the tree that needs the cart, and leave the rest untouched. Context is not global state — it is scoped to its provider — and that is exactly why it works. A header component outside the provider does not re-render when the cart changes. A sidebar inside it does.

The rule of thumb: use context for subtree state, not application state. If you find yourself wrapping your entire app in a provider and fighting re-renders, the problem is not that you need Redux — it is that the state should not have been global in the first place.

So when do you need a global store?

There is a category of apps where client state genuinely dominates. A drawing app where every shape on the canvas has coordinates, color, rotation, and z-index. A collaborative whiteboard with dozens of objects updated in real time. A video editor with a timeline, layers, and undo history. In these cases, the state is not fetched from an API — it is created by the user on the client, and it is deeply interconnected.

This is where Zustand shines. A single, mutable store with no boilerplate, no providers, and fine-grained subscriptions that prevent unnecessary re-renders:

const useStore = create((set) => ({
  shapes: [],
  addShape: (shape) => set((state) => ({ shapes: [...state.shapes, shape] })),
  moveShape: (id, x, y) =>
    set((state) => ({
      shapes: state.shapes.map((s) => (s.id === id ? { ...s, x, y } : s)),
    })),
}));

Notice the difference from the context example above: the state here is complex, every action touches it, and the performance characteristics matter because the canvas updates at 60 frames per second. This is not a shopping cart. This is not a sidebar. And most apps — including most production apps — are not this.

The trap is that early-stage apps look at these libraries and think "I will need this eventually." But by the time "eventually" arrives, the complexity these libraries were meant to solve is already present in the codebase, and you know exactly what shape your state takes. Adding a store at that point is a deliberate architectural decision based on real problems, not a preemptive one based on fear.

The majority of React apps can be built with three things: SWR or React Query for server state, useState for local toggles, and context for sharing across subtrees. Zustand and Redux are excellent tools — but they solve a problem most apps simply do not have yet. Skip them until the code tells you otherwise.

👉 Build it yourself: Shopping Cart — manage a cart with context and provider, no global store needed.

When to Replace Multiple useState with useReducer

ReactChallenges — Thu, 07 May 2026 16:17:14 +0000

You start with one useState. Then another. Then a third. Before you know it, a single event handler calls four setters in sequence and you've lost track of which combination of state values is valid. Sound familiar?

👉 Try it in practice: Calculator with reducer

React gives us two built-in tools for component state: useState for independent values, and useReducer for grouped state transitions. The problem is that nobody tells you where the line is. You only notice you crossed it when the code starts hurting.

Here's how to recognize that moment — and what to do about it.

The smell: state that moves together

The clearest signal is when a single user action needs to update multiple state values at once. If you see a pattern like this:

const [isOpen, setIsOpen] = useState(false);
const [selectedItem, setSelectedItem] = useState<string | null>(null);
const [error, setError] = useState<string | null>(null);
const [isSubmitting, setIsSubmitting] = useState(false);

And then an event handler that touches all of them:

function handleSelect(item: string) {
  setSelectedItem(item);
  setIsOpen(false);
  setError(null);
  setIsSubmitting(false);
}

You're describing a state transition — moving from one valid state to another — but you're encoding it as a sequence of independent mutations. The more setters you call in one handler, the more likely you are to forget one, or call them in the wrong order, or leave the component in an impossible state like isSubmitting: true and error: "timeout" at the same time.

A second signal: derived state scattered across the component. If you find yourself writing if (isOpen && selectedItem && !error) in five different places, those three booleans aren't independent. They describe a single concept — the UI mode the component is in — and you're reconstructing it from pieces over and over.

A third signal: reset logic that looks like a checklist. When closing a modal or resetting a form, if you need six setX(initialX) calls in a row, the state belongs together.

The fix: describe state transitions, not state mutations

useReducer lets you define the legal transitions explicitly:

type State =
  | { status: "idle" }
  | { status: "selecting"; items: Item[] }
  | { status: "selected"; item: Item }
  | { status: "submitting"; item: Item }
  | { status: "error"; item: Item; message: string };

type Action =
  | { type: "OPEN_LIST"; items: Item[] }
  | { type: "SELECT_ITEM"; item: Item }
  | { type: "SUBMIT" }
  | { type: "SUBMIT_ERROR"; message: string }
  | { type: "RESET" };

Instead of five separate booleans and nullables, you have a single state value that is always in exactly one valid mode. The reducer maps actions to states:

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case "OPEN_LIST":
      return { status: "selecting", items: action.items };

    case "SELECT_ITEM":
      if (state.status !== "selecting") return state;
      return { status: "selected", item: action.item };

    case "SUBMIT":
      if (state.status !== "selected") return state;
      return { status: "submitting", item: state.item };

    case "SUBMIT_ERROR":
      if (state.status !== "submitting") return state;
      return { status: "error", item: state.item, message: action.message };

    case "RESET":
      return { status: "idle" };

    default:
      return state;
  }
}

Notice what disappeared: the impossible states. There is no branch where isSubmitting is true and selectedItem is null, because the type system won't allow it. The reducer rejects transitions that don't make sense — if the user somehow triggers SUBMIT while the component is idle, it returns the current state unchanged.

The component becomes a thin shell that dispatches intent:

const [state, dispatch] = useReducer(reducer, { status: "idle" });

return (
  <div>
    {state.status === "selecting" && (
      <ItemList
        items={state.items}
        onSelect={(item) => dispatch({ type: "SELECT_ITEM", item })}
      />
    )}
    {state.status === "selected" && (
      <button onClick={() => dispatch({ type: "SUBMIT" })}>
        Confirm {state.item.name}
      </button>
    )}
    {state.status === "submitting" && <Spinner />}
    {state.status === "error" && <ErrorMessage message={state.message} />}
  </div>
);

No more if (isOpen && selectedItem && !isSubmitting && !error). The component renders based on a single discriminant — state.status — and TypeScript narrows the available properties automatically.

When to switch (and when not to)

Not every component needs useReducer. Here is a practical heuristic:

Stick with useState	Consider useReducer
1-2 independent values	3+ values that change as a unit
Each setter is called in isolation	One handler calls multiple setters
Reset is one or two lines	Reset requires a checklist of initial values
State combinations are always valid	Some combinations are impossible or bug-prone
The component is 50 lines	The component is 150+ lines and growing

If you find yourself writing a function called resetForm that exists solely to call six setters in sequence, you've already built a reducer — just one spread across your component body.

Don't use useReducer for everything. A single boolean toggle doesn't need a reducer. Two independent counters in the same component don't need to be merged. The reducer shines when state values are coupled — when changing one implies changing others, and the set of legal combinations is smaller than the Cartesian product of all values.

The testing advantage

The most underrated benefit of useReducer is that the reducer is a pure function. You can test every state transition without rendering a component:

test("selecting an item from idle should do nothing", () => {
  const state = { status: "idle" as const };
  const next = reducer(state, {
    type: "SELECT_ITEM",
    item: { id: 1, name: "Foo" },
  });
  expect(next).toBe(state); // no transition allowed
});

test("submitting a selected item moves to submitting state", () => {
  const state = { status: "selected" as const, item: { id: 1, name: "Foo" } };
  const next = reducer(state, { type: "SUBMIT" });
  expect(next.status).toBe("submitting");
  expect(next.item.name).toBe("Foo");
});

No mocks, no act(), no render. Just a function that takes state and returns state. When the core logic lives in a reducer, your component tests become thin integration checks, and the business logic is tested fast, in isolation, with full confidence.

👉 Try it in practice: Calculator with reducer

🚀 New Challenge: File Explorer

ReactChallenges — Tue, 05 May 2026 08:42:34 +0000

Build a recursive file explorer tree view, similar to the sidebar in VS Code.

👉 https://www.reactchallenges.com/challenges/file-explorer

🧠 What you'll practice

Managing local state with useState
Recursive thinking in React
Rendering nested data structures
Building clean, composable components
Handling UI state at scale

📂 The challenge

You’ll implement a tree view where:

Folders can be expanded and collapsed independently
Each node manages its own state (no global state)
Nested folders are fully supported
Depth is visually represented with indentation
Only folders are interactive (files are static)
Accessibility is considered (aria-expanded)

🎯 Goal

This is a focused exercise designed to help you:

Think in component trees
Get comfortable with recursion in UI
Build patterns that scale to real-world applications

👉 https://www.reactchallenges.com/challenges/file-explorer

🥋 New coding katas are now live on ReactChallenges

ReactChallenges — Fri, 01 May 2026 11:27:07 +0000

We’ve just released a new section on ReactChallenges: coding katas.

Unlike traditional coding challenges, these are not focused on rankings, scores, or competition. Instead, they are designed for deliberate practice—short, focused exercises that help you improve specific skills through repetition.

👉 https://www.reactchallenges.com/katas

What are katas?

Katas are small, self-contained coding exercises. Each one targets a specific concept or pattern so you can:

Practice the same idea multiple times
Strengthen your mental models
Improve fluency in React and JavaScript
Build consistency over time

There is no leaderboard, no timer pressure, and no comparison with others.

Why this approach?

Most platforms optimize for competition.

This one doesn’t.

The goal of katas is to reduce noise and focus on what actually makes you better at coding:

Repetition over novelty
Understanding over speed
Clarity over complexity

If you’ve used competitive platforms before, this is intentionally different.

Who are they for?

These katas are especially useful if you:

Want to reinforce JavaScript fundamentals
Prefer structured, low-pressure practice
Are preparing for interviews or real-world development
Want to build consistency in your coding routine

👉 https://www.reactchallenges.com/katas

Less noise. More repetition. Better understanding.

New way of passing ref to child in React 19

ReactChallenges — Thu, 30 Apr 2026 16:07:17 +0000

If you have worked with refs in React, you probably know they have always felt a bit different from the rest of the API. Useful, yes—but also slightly awkward.

With React 19, that changes. Passing a ref to a child component is now much more natural because ref can be handled like a normal prop. That means less boilerplate, cleaner components, and a simpler mental model.

try this yourself, the Passing Refs in React 19 challenge on our platform lets you practice exactly this pattern.

How refs work (and why they were awkward)

A ref is just a way to keep a direct reference to something rendered by React, usually a DOM element. You normally use refs when you need to do something imperative: focus an input, scroll an element into view, measure size or position, or trigger methods like opening a modal.

function App() {
  const inputRef = useRef<HTMLInputElement>(null);

  return (
    <>
      <button onClick={() => inputRef.current?.focus()}>Focus input</button>

      <input ref={inputRef} />
    </>
  );
}

The parent owns the button, and the parent decides when the input should be focused. Because of that, the ref also belongs in the parent. The rule is simple: the ref should live wherever the action is controlled.

But what happens when the ref is inside the child?

function Input() {
  const ref = useRef<HTMLInputElement>(null);

  return <input ref={ref} />;
}

Now only the Input component can use that ref. The parent cannot call .focus(), scroll to it, measure it, or control it from outside. The ref becomes private—sometimes fine, but often not what you need.

And here's where the friction came in. Before React 19, ref was treated differently from normal props. You could not simply write <Input ref={inputRef} /> unless that component used forwardRef:

const Input = forwardRef<HTMLInputElement, Props>((props, ref) => {
  return <input ref={ref} {...props} />;
});

It worked, but it came with real costs: extra wrapper syntax, ref behaving differently from props, more complex TypeScript types, and awkward composition with memo or HOCs.

What React 19 changes

Now you can write this:

function Input({ ref, ...props }) {
  return <input ref={ref} {...props} />;
}

No forwardRef. No special wrapper. No separate mental model.

The main benefit is consistency. Before, ref felt like a special exception in React. Now it follows the same idea as everything else: if the parent needs access to something, pass it down. That makes components easier to understand, easier to teach, and reduces noise in codebases full of tiny wrapper components whose only purpose was forwarding refs.

This also helps with advanced patterns. Sometimes you don't want to expose a DOM node—you want to expose methods. For example, a modal:

function Modal({ ref }) {
  const [open, setOpen] = useState(false);

  useImperativeHandle(ref, () => ({
    open: () => setOpen(true),
    close: () => setOpen(false),
  }));

  return open ? <div>Modal</div> : null;
}

Used like this:

function App() {
  const modalRef = useRef(null);

  return (
    <>
      <button onClick={() => modalRef.current.open()}>Open modal</button>

      <Modal ref={modalRef} />
    </>
  );
}

This pattern still works, but now the component itself is cleaner.

Refs were never difficult because of what they do. They were difficult because React treated them differently.

React 19 removes that friction. A ref is usually owned by the component that needs to use it—most of the time, the parent. The child simply receives that ref and connects it to something useful.

Now that ref behaves like a normal prop, the whole pattern feels much more natural.

If you want to solidify this concept, try the Passing Refs in React 19 challenge—it takes just a few minutes.

🚀 New Free React Challenge: New Way of Passing Ref

ReactChallenges — Mon, 27 Apr 2026 20:54:44 +0000

A new free challenge is now available on ReactChallenges.com.

React 19 introduced a cleaner way to work with refs across components, reducing the need for forwardRef in many common scenarios.

This new exercise helps you practice that pattern with a real UI example.

What you'll build

A simple issue modal where users can:

Open the modal
Automatically focus the textarea when it appears
Close it with Cancel or Create

What you'll learn

How to create a ref in the parent component
How to pass a ref directly to a child component in React 19
How to control focus from outside the child component
How this compares to the previous forwardRef pattern

Why this matters

Refs are often needed for:

Modals
Search inputs
Forms
Custom UI primitives
Accessibility improvements

React 19 makes these interactions cleaner and easier to implement.

Try the challenge

👉 https://www.reactchallenges.com

Composition vs Compound Components in React

ReactChallenges — Tue, 14 Apr 2026 08:58:38 +0000

In React, reusable UI usually follows two patterns: composition components and compound components. They are closely related, but they differ mainly in how state is handled and how the API is exposed.

👉 Try it in practice: Composition Components Challenge

Composition Components (no Context)

This is the most straightforward approach. You build UI by combining components and passing data through props.

Everything is explicit: each component receives what it needs directly from its parent.

This makes the system very flexible and easy to reuse, since every part is independent. You can take a subcomponent and use it anywhere without constraints.

The downside is that as the UI grows, you often end up with prop drilling and a lot of wiring code. Sharing behavior between related parts also becomes harder because there is no shared state mechanism.

In short: simple, explicit, and flexible, but can become verbose in complex UIs.

import Airbnb from "./Airbnb";

<Airbnb.Card>
  <Airbnb.ImageWrapper>
    <Airbnb.Image src={el.image} alt={el.title} />
    <Airbnb.Heart like={el.isFavorite} onClick={() => {}} />
    <Airbnb.Recomendation />
  </Airbnb.ImageWrapper>
  <Airbnb.Content>
    <Airbnb.Title title={el.title}>
      <Airbnb.Valoration average={el.average} reviews={el.reviews} />
    </Airbnb.Title>
    <Airbnb.Description description={el.description} />
    <Airbnb.Price price={el.price} nights={el.nights} />
    <Airbnb.Cancelation />
  </Airbnb.Content>
</Airbnb.Card>;

Compound Components (with Context)

This pattern introduces shared state using React Context. Instead of passing props through every level, a parent component provides state and child components consume it directly.

This creates a tighter relationship between components. From the outside, the API becomes very clean because users don’t need to manage all the props manually.

It works especially well for structured UI systems where components are meant to work together (like cards, modals, tabs, etc.).

The trade-off is that the relationship becomes implicit. Subcomponents depend on a parent provider and are not really meant to be used in isolation. Debugging can also be slightly less obvious because the data flow is hidden inside Context.

In short: more structured, cleaner API, but less flexible and more coupled.

import Airbnb from "./Airbnb";

<Airbnb.Card data={el}>
  <Airbnb.ImageWrapper>
    <Airbnb.Image />
    <Airbnb.Heart />
    <Airbnb.Recomendation />
  </Airbnb.ImageWrapper>
  <Airbnb.Content>
    <Airbnb.Title>
      <Airbnb.Valoration />
    </Airbnb.Title>
    <Airbnb.Description />
    <Airbnb.Price />
    <Airbnb.Cancelation />
  </Airbnb.Content>
</Airbnb.Card>;

👉 Try it in practice: Compound Components Challenge

Export styles

There are two common ways to expose these components.

Named exports give maximum flexibility and are easy to tree-shake, but they don’t communicate relationships between components very well.

import { Card, ImageWrapper, Image } from "./Airbnb";

<Card data={el}>
  <ImageWrapper>
    <Image />
  </ImageWrapper>
</Card>;

Namespaced exports group everything under a single object, which makes the structure much clearer and is often preferred for compound components or design systems. The trade-off is slightly more verbosity and sometimes less optimal tree-shaking.

import Airbnb from "./Airbnb";

<Airbnb.Card data={el}>
  <Airbnb.ImageWrapper>
    <Airbnb.Image />
  </Airbnb.ImageWrapper>
</Airbnb.Card>;

When to use each

Use composition when components are independent and you want full flexibility with explicit data flow.

Use compound components when the UI pieces are strongly related, share state, and benefit from a controlled and clean API.

Summary

Composition is about flexibility and explicitness.

Compound components are about structure and shared state.

Both are just different ways of organizing the same idea: composition in React.

👉 Try it in practice: Composition Components Challenge

🚀 𝗡𝗲𝘄 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲 𝗼𝗻 𝗥𝗲𝗮𝗰𝘁 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀: 𝗔𝗶𝗿𝗯𝗻𝗯 𝗖𝗮𝗿𝗱 𝘄𝗶𝘁𝗵 𝗖𝗼𝗺𝗽𝗼𝘂𝗻𝗱 𝗖𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁𝘀 + 𝗖𝗼𝗻𝘁𝗲𝘅𝘁

ReactChallenges — Mon, 13 Apr 2026 08:44:26 +0000

A new intermediate challenge is now live focused on one of the most powerful React patterns:

🧩 𝗖𝗼𝗺𝗽𝗼𝘂𝗻𝗱 𝗖𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁𝘀
🌐 𝗥𝗲𝗮𝗰𝘁 𝗖𝗼𝗻𝘁𝗲𝘅𝘁
♻️ 𝗥𝗲𝘂𝘀𝗮𝗯𝗹𝗲 𝗖𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲

In this challenge, you'll build a fully functional Airbnb-style card component using the Compound Components pattern powered by Context.

The goal is to create a flexible API where subcomponents share state implicitly through a provider — just like production-grade UI libraries.

This challenge will help you:

Understand how compound components scale
Use Context to avoid prop drilling
Design clean and extensible component APIs
Think in terms of composition over configuration

Perfect if you're moving beyond basic components and want to write more maintainable, real-world React code.

Try it here 👇
https://www.reactchallenges.com/challenges/airbnb-card-compound-component-context

𝗙𝗲𝗲𝗱𝗯𝗮𝗰𝗸 𝗶𝘀 𝗮𝗹𝘄𝗮𝘆𝘀 𝘄𝗲𝗹𝗰𝗼𝗺𝗲.

💬 What advanced React patterns would you like to practice next?

💾 Save this for your React learning path
♻ Repost to help other developers
👥 Share with your frontend team

🚀 New React Challenge: Play Soroban

ReactChallenges — Fri, 20 Mar 2026 11:21:02 +0000

Test your React skills with this interactive Soroban-style game!

A sequence of numbers appears on the screen, and after it ends, you need to verify the calculated sum.

Why Try This Challenge?

🧠 Practice state management and React hooks.
⏱️ Handle timed interactions and dynamic rendering.
🎯 Improve problem-solving in fun, bite-sized challenges.

Try It Here

👉 Play Soroban Challenge

✅ Your feedback is always welcome!

💬 Comment which React challenge you’d like to see next.