20 задач по React с разбором: что реально проверяют на собеседовании и в production

Введение

Запрос 20 задач по React с разбором обычно ищут не ради академической подборки. На практике нужен набор тем, которые повторяются и на собеседованиях, и в реальном коде: почему компонент перерисовался, зачем key, где ломается форма, когда Context начинает тянуть лишние обновления, почему useEffect дал гонку запросов, а SSR и hydration неожиданно расходятся с тем, что было локально.

Слабая подготовка к таким задачам выглядит одинаково: человек помнит отдельные API, но не связывает их с моделью работы React. Сильный ответ начинается не с перечисления хуков, а с объяснения потока данных, границ ответственности и цены обновления. Именно поэтому рядом со списком задач полезно держать разборы рендеринга React, reconciliation и Fiber.

Как читать эти задачи

Ниже каждая задача дана в трех плоскостях:

• что именно проверяют;
• где кандидаты обычно ошибаются;
• как выглядел бы взрослый ответ, если задача всплыла в production или на интервью.

Это полезнее, чем просто смотреть на «правильный код». В React одна и та же задача может иметь несколько корректных решений, но разную стоимость по памяти, CPU, читаемости и сопровождению.

Таблица: какие классы задач по React встречаются чаще всего

Блок	Что проверяют	Где чаще всего ломаются	Что важно в ответе
Рендеринг	когда и почему идет обновление	путают render и commit	источник обновления и радиус ререндера
Списки	стабильность identity	index как key	сохранение состояния элементов
Формы	модель данных и валидация	смешивают controlled и uncontrolled	цена обновления и UX формы
Хуки	зависимости и side effects	stale closure и гонки	жизненный цикл эффекта
Состояние	локальный state, Context, store	глобализируют все подряд	границы ответственности
Производительность	где узкое место	преждевременная оптимизация	измерение до оптимизации
SSR и RSC	серверный и клиентский слой	смешивают роли SSR и RSC	что исполняется где и зачем

Архитектура: что на самом деле решают задачи по React

Большинство задач по React крутятся вокруг одной схемы:

1. Есть источник данных: props, local state, серверный ответ, DOM или внешний store.
2. Есть событие: input, click, async completion, navigation.
3. React пересчитывает дерево, сравнивает его с предыдущей версией и решает, что обновить.
4. Ошибка возникает либо в identity элементов, либо в потоке данных, либо в неверной границе между вычислением и эффектом.

Если держать эту схему в голове, то и батчинг обновлений, и concurrent rendering, и Strict Mode перестают выглядеть как набор несвязанных фактов.

20 задач по React с разбором

1. Почему компонент перерисовался

Проверяют, понимаете ли вы, что ререндер не равен реальному изменению DOM. Обычно нужно назвать источник обновления: изменился state, пришли новые props, обновился context, сработал родительский ререндер.

Типичная ошибка: сказать «компонент перерисовался, потому что React так работает» и не уметь локализовать триггер. Нормальный ответ включает цепочку: какое обновление произошло, какой участок дерева затронут и почему это не всегда проблема. Для смежного разбора полезна статья про лишние ререндеры в React.

2. Что сломается, если использовать index как key

Задача почти всегда про identity элементов списка. Если список меняет порядок, вставляет элементы в середину или удаляет их, index приводит к тому, что React переиспользует состояние не тех элементов.

На интервью хорошо звучит не просто «так нельзя», а объяснение: key нужен не для исчезновения warning, а для стабильного сопоставления прошлого и нового дерева. Отдельно это разобрано в материале про частые ошибки с React keys.

3. Почему input внезапно потерял фокус в списке

Обычно причина в unstable key, пересоздании компонента или в том, что родитель каждый раз рендерит новый subtree вместо обновления существующего.

Сильный ответ: сначала проверяем identity элемента, потом смотрим, не создается ли компонент условно заново, и только потом ищем проблемы в refs или сторонней библиотеке.

4. В чем разница между controlled и uncontrolled input

Здесь проверяют не словарь терминов, а понимание источника истины. В controlled-поле значение живет в React state. В uncontrolled-поле значение живет в DOM.

Типичная ошибка: утверждать, что controlled всегда лучше. Для больших анкет, file input и простых submit-форм это не так. По теме рядом лежат controlled vs uncontrolled компоненты и сложные вопросы по React-формам.

import { useState } from "react";

export function SearchForm() {
  const [query, setQuery] = useState("");

  return (
    <form>
      <input
        value={query}
        onChange={(event) => setQuery(event.target.value)}
        placeholder="Поиск"
      />
      <p>Текущее значение: {query}</p>
    </form>
  );
}

В этом примере React контролирует значение. Это удобно для live preview и мгновенной валидации, но при большой форме цена каждого обновления становится заметнее.

5. Почему setState не обновил значение сразу

Задача проверяет понимание batching и того, что чтение state сразу после setState в том же синхронном куске кода не гарантирует новое значение.

Зрелый ответ: обновления в React планируются и могут группироваться. Если новое значение зависит от старого, нужен functional update, а не чтение замыкания.

6. Что не так с этим useEffect

Обычно дают эффект с неправильными зависимостями, утечкой таймера, stale closure или повторным запросом. Суть задачи не в том, чтобы механически «добавить все в deps», а в том, чтобы разделить синхронизацию с внешним миром и вычисления, которые вообще не должны жить в эффекте.

Для системного понимания здесь полезен блок из React Hooks interview.

7. Как появляется stale closure

Чаще всего через таймер, подписку или callback, который замкнул старое значение. Кандидаты часто лечат это случайным добавлением зависимостей, не объясняя, почему поведение было неверным.

Сильный ответ: stale closure возникает, когда функция видит снимок значений из прошлого рендера. Дальше уже выбирают инструмент: dependency array, functional update, ref или перестройка архитектуры.

8. Почему запросы в useEffect дают гонку

Это частая production-задача: пользователь быстро меняет фильтр, старый запрос завершается позже нового и перетирает актуальные данные.

Минимально зрелое решение включает отмену через AbortController или проверку версии запроса.

import { useEffect, useState } from "react";

export function UserCard({ userId }: { userId: string }) {
  const [user, setUser] = useState<{ name: string } | null>(null);

  useEffect(() => {
    const controller = new AbortController();

    fetch(`/api/users/${userId}`, { signal: controller.signal })
      .then((res) => res.json())
      .then((data) => setUser(data))
      .catch((error) => {
        if (error.name !== "AbortError") throw error;
      });

    return () => controller.abort();
  }, [userId]);

  return <div>{user ? user.name : "Загрузка..."}</div>;
}

Такой ответ лучше, чем фраза «React иногда лагает с асинхронщиной». Проблема здесь не в React, а в жизненном цикле побочного эффекта.

9. Когда нужен useMemo, а когда нет

Проверяют, различаете ли вы кеширование дорогого вычисления и попытку «лечить» любой ререндер. Частая ошибка: заворачивать в useMemo все подряд и получать больше сложности, чем пользы.

Нормальный ответ: useMemo нужен там, где есть дорогой расчет или где важна referential stability для дочернего оптимизированного компонента. Подробно это увязано с React.memo, useMemo и useCallback.

10. Почему React.memo не спас

Если родитель на каждом рендере создает новые объекты, массивы и inline-функции, мемоизация дочернего компонента не даст ожидаемого выигрыша.

Сильный ответ содержит фразу о том, что оптимизация должна начинаться с измерения и с поиска горячего пути, а не с механического оборачивания компонентов.

11. Когда Context API начинает тормозить

Задача не про то, что Context плохой. Она про то, что любое изменение value уведомляет всех потребителей этого контекста.

Если в один контекст положить тему, пользователя, feature flags и состояние модалки, вы получите широкий радиус обновлений. Поэтому полезно понимать, когда выбрать Context API, а когда вынести данные в store и селекторы. Для сравнения есть и материал Redux vs Zustand vs Context.

12. Зачем нужен useRef, если есть state

Проверяют понимание того, что ref хранит значение между рендерами, но не триггерит новый рендер. Это подходит для DOM-доступа, id таймеров, предыдущих значений и императивных интеграций.

Типичная ошибка: использовать ref как теневой state для бизнес-данных. Это ломает предсказуемость. Смежный разбор есть в статье про useRef на практике.

13. Когда оправдан forwardRef и useImperativeHandle

Это задача про границу между декларативным и императивным управлением. forwardRef нужен, когда компонент должен пробросить ref к внутреннему DOM-узлу. useImperativeHandle нужен, когда наружу надо отдать ограниченный API вроде focus() или clear().

Подробный разбор уже есть в forwardRef и useImperativeHandle. На интервью важно проговорить, что через ref нельзя тащить бизнес-состояние, иначе архитектура быстро становится хрупкой.

14. Чем portal отличается от обычного рендера

Здесь ждут не только createPortal, но и понимание bubbling по React tree, а не только по DOM. Задача часто завязана на модалки, dropdown и overlay.

Сильный ответ объясняет, что портал меняет место в DOM, но не вырывает компонент из React-дерева. Это важно для context, state и обработки событий. Подробнее это разобрано в React Portals.

15. Что такое reconciliation

Это одна из базовых задач на модель работы React. Нужно объяснить, как React сравнивает предыдущее и новое дерево и почему тип элемента и key влияют на сохранение состояния.

Плохой ответ: «React сравнивает virtual DOM». Нормальный: React сопоставляет элементы, определяет, что можно переиспользовать, а что нужно размонтировать и смонтировать заново. Для глубины полезен разбор reconciliation.

16. Что дает Suspense

Многие отвечают так, будто Suspense сам по себе решает все проблемы загрузки данных. Это неверно. Suspense управляет отображением fallback, когда компонент или ресурс временно не готов.

На сильном ответе стоит отдельно сказать, что граница Suspense должна совпадать с UX-границей экрана. Иначе пользователь будет видеть лишнее мерцание. Смежная статья: Suspense в React.

17. В чем разница между SSR, CSR и RSC

Эта задача стала очень частой после усиления server-first подходов. Проверяют, понимаете ли вы, что SSR отвечает за серверный HTML первого ответа, CSR за клиентский рендер, а RSC за границу между серверными и клиентскими компонентами.

Слабый ответ пытается выбрать «что лучше вообще». Сильный объясняет, какой подход нужен для какого экрана. Для этого есть отдельный материал React SSR vs CSR vs RSC и React Server Components.

18. Что делает Strict Mode в dev-режиме

Часто спрашивают, почему эффект вызвался дважды. Здесь важно не говорить, что «React сломан». StrictMode в development помогает выявлять небезопасные сайд-эффекты и код, который не переживает повторный mount/unmount цикл.

Хороший ответ показывает, что кандидат умеет отличать dev-поведение от production-поведения. Смежная статья: React Strict Mode.

19. Как объяснить concurrent rendering простыми словами

Обычно проверяют не знание терминов, а то, понимаете ли вы идею приоритизации обновлений. Не все обновления одинаково срочные: ввод текста важнее пересчета тяжелого списка.

Взрослый ответ связывает тему с отзывчивостью UI, startTransition и тем, что React может прерывать и переигрывать работу до commit. Для углубления есть React concurrent rendering explained.

20. Как оптимизировать большой список

Эта задача объединяет почти все предыдущие: stable keys, мемоизацию, виртуализацию, нормальные селекторы и контроль над объемом работы на каждом рендере.

Типичная ошибка: сразу тянуть useMemo и React.memo, не проверив, что bottleneck вообще в рендерах, а не в сортировке, фильтрации или DOM-количестве. Для соседнего контекста полезны оптимизация React на middle-собеседовании и code splitting и lazy loading.

import { memo, useState } from "react";

const Row = memo(function Row({
  item,
  onSelect,
}: {
  item: { id: string; title: string };
  onSelect: (id: string) => void;
}) {
  return <li onClick={() => onSelect(item.id)}>{item.title}</li>;
});

export function HugeList({ items }: { items: { id: string; title: string }[] }) {
  const [selectedId, setSelectedId] = useState<string | null>(null);

  return (
    <ul>
      {items.map((item) => (
        <Row key={item.id} item={item} onSelect={setSelectedId} />
      ))}
      <li>Выбрано: {selectedId ?? "ничего"}</li>
    </ul>
  );
}

Даже здесь оптимизация неполная. Если список реально огромный, потребуется виртуализация, иначе узкое место останется в количестве DOM-узлов, а не только в числе ререндеров.

Разбор производительности: где в этих задачах реальные узкие места

Когда говорят «задачи по React», часто думают только о JavaScript-API. Но реальные проблемы обычно лежат в одном из четырех мест:

• слишком широкий радиус обновления;
• тяжелые вычисления в горячем пути;
• большой объем DOM;
• неудачная граница между серверным и клиентским кодом.

Например, задача про форму часто упирается не в сам input, а в то, что каждая буква перерисовывает полстраницы. Задача про список может упираться не в key, а в сортировку на каждом рендере. Задача про SSR может быть не про HTML, а про дорогую hydration-фазу на слабом устройстве. Поэтому хороший ответ всегда привязан к измерению: profiler, browser performance panel, web vitals, время ответа API и стоимость commit.

Production pitfalls

Ниже три сбоя, которые реально повторяются в проектах:

• Нестабильные key в списке заказов или форм. Признак: пользователь редактирует одну строку, а состояние «переезжает» в другую после сортировки или фильтрации.

• Гонки запросов в useEffect. Признак: в логах несколько параллельных запросов на один и тот же экран, а в UI периодически показываются устаревшие данные.

• Глобальный Context на слишком широкий срез данных. Признак: profiler показывает каскад ререндеров по дереву после локального изменения, например открытия одной модалки или смены фильтра.

Во всех трех случаях ошибка не в конкретном хуке. Ошибка в неправильной границе ответственности.

Практики, которые реально помогают

• Сначала формулируйте источник истины: React state, DOM, серверный снимок или внешний store.
• Держите key стабильным и связанным с сущностью, а не с позицией в массиве.
• Не кладите в useEffect то, что можно вычислить на рендере.
• Оптимизируйте только после измерения, а не по интуиции.
• Делите Context по зонам изменения, а не по удобству импорта.
• Для больших экранов думайте о границах: route, feature, widget, Suspense, server/client.
• В формах отдельно проектируйте draft-state, validation-state и server-state.

Частые ошибки

• Путать ререндер с обновлением DOM.
• Использовать index как key в динамическом списке.
• Лечить stale closure случайным набором зависимостей.
• Тащить бизнес-данные в ref, потому что так «меньше ререндеров».
• Использовать Context как замену нормальной модели состояния.
• Заворачивать все подряд в useMemo и React.memo.
• Отвечать про SSR, CSR и RSC так, будто это взаимоисключающие религии, а не инструменты для разных задач.

Как отвечать на интервью

Хороший шаблон ответа на задачу по React выглядит так:

1. Сначала назвать, какой слой проблемы проверяют: identity, state, effect, rendering, performance, server/client boundary.
2. Затем показать причину: откуда приходит обновление или почему ломается состояние.
3. После этого предложить решение и обязательно назвать ограничения.
4. В конце коротко сказать, как бы вы проверили гипотезу в production: profiler, логирование, network waterfall, user timing или тест.

Если ответить только кодом, это выглядит как заученный рецепт. Если ответить только теорией, это выглядит как пересказ документации. Нужна связка «модель работы React -> симптом -> решение -> trade-off».

FAQ

Какие задачи по React обязательны для middle frontend-разработчика

Минимум: ререндеры, key, controlled и uncontrolled формы, useEffect, Context API, useRef, memoization, Suspense и базовая разница между CSR и SSR.

Какие задачи чаще встречаются у senior

Там чаще смотрят на архитектурные темы: границы Context, performance budget, большие формы, race conditions, concurrent rendering, SSR/RSC, overlay-архитектуру и управление сложными списками.

Нужно ли учить React internals для таких задач

До уровня исходников движка не всегда нужно, но понимать Fiber, reconciliation и commit/render phase очень полезно. Без этого многие ответы получаются механическими.

Какие задачи по React чаще всего связаны с реальным production

Практически все из этой подборки. Особенно формы, списки, ключи, эффекты, оптимизация рендеров, контекст и серверный рендеринг.

Как лучше тренироваться

Не решать задачи изолированно, а брать экран целиком: список, фильтр, форма редактирования, загрузка данных, модалка, SSR-страница. Тогда сразу видны компромиссы, которые на интервью и отличают сильный ответ от шаблонного.

Итоги

Подборка 20 задач по React с разбором полезна только тогда, когда вы видите за каждой задачей не отдельный API, а модель работы интерфейса. Почти все сложные вопросы сводятся к четырем вещам: где живут данные, как обновляется дерево, что сохраняет identity и сколько стоит конкретное обновление.

Если готовиться именно так, задачи про key, useEffect, Context, Suspense, формы, refs и SSR перестают быть набором разрозненных тем. Они собираются в одну инженерную картину, с которой уже можно нормально проходить интервью и писать более устойчивый production-код.