Двадцать вопросов из интервью React, которые отличают простое использование от настоящего понимания

Разработка с React и объяснение принципов работы React — это разные навыки. На собеседованиях основное внимание уделяется второму аспекту: что происходит при вызове setState, почему важны ключи, когда перезапускаются эффекты. Ниже приведены двадцать вопросов, которые постоянно возникают. Ответы основаны на том, какую проблему решает каждая функция, и на типичных сложностях в производственной среде, а не на шаблонных формулировках из учебников.

1. Что на самом деле такое виртуальный DOM

Виртуальный DOM — это не какая-то волшебная пыль для ускорения. Это обычное дерево JavaScript, описывающее тот вид, в котором должен выглядеть интерфейс. При изменении состояния React создаёт новое виртуальное дерево, сравнивает его с предыдущим с помощью операции diff, а затем согласовывает изменения, применяя к реальному DOM браузера только необходимые корректировки. Работа с реальным DOM запускает процессы формирования макета и отрисовки; изменение объектов JavaScript стоит немного ресурсов, поэтому React использует процессорную мощность в памяти, чтобы сократить нагрузку на браузер. Такой подход направлен на минимизацию нагрузки на браузер, а не на то, чтобы каждое сравнение выполнялось бесплатно. Утверждение «Виртуальный DOM всегда быстрее» без учёта этих нюансов — типичная ошибка начинающих разработчиков.

2. Виртуальный DOM против DOM браузера

Фактические обновления DOM требуют значительных ресурсов и могут приводить к изменению форматирования и перерисовке элементов. Виртуальные обновления представляют собой различия объектов в памяти; React группирует дорогостоящие операции записи в DOM, вместо того чтобы выполнять их после каждого вызова функции состояния. Использование механизма track-changes для редактирования эффективнее, чем полная перезапись всего документа при каждой опечатке.

3. Почему ключи списков важны при перемещении строк

Ключи позволяют идентифицировать элементы между разными отрисовками. Без них React использует позицию индекса, что нарушается при добавлении, удалении или переупорядочивании элементов. Использование индекса массива в качестве ключа «работает» до тех пор, пока переупорядочивание не приводит к тому, что поля ввода и флажки остаются привязанными к неверным строкам — это видимость «утечки состояния», на самом деле являющаяся ошибкой ключей. Лучше использовать стабильные уникальные идентификаторы из данных; индексы подходят только для по-настоящему статичных списков. Если интерфейс поддерживает перетаскивание для переупорядочивания или фильтрацию, использование индексов в качестве ключей в конечном итоге повредит локальное состояние строк.

4. Объяснение функции useState с самых основ

Обычные элементы интерфейса уничтожаются при возврате функции. useState предоставляет функциональному компоненту долговечную память и запланирует перерисовку при изменении этой памяти:

const [count, setCount] = useState(0);

count — это текущее значение; setCount запрашивает его обновление. Обновление не применяется в процессе перерисовки: запись значения count сразу после вызова setCount всё равно показывает предыдущее значение, поскольку новое значение отображается при следующей перерисовке.

5. Почему обновления useState кажутся замедленными или группируемыми

React объединяет обновления, поступившие в рамках одного события, в одну перерисовку. Начиная с React 18, такое объединение распространяется также на обещания и таймеры, а не только на обработчики событий React. Если вам нужно получить последнее значение на основе предыдущего состояния, используйте функциональный обновитель:

setCount(prev => prev + 1);

Эта формула использует самое свежее значение из очереди, а не устаревшую копию состояния. Интервьюеры часто спрашивают, что произойдёт, если закрыть переменную count внутри таймера без соответствующей функции обновления.

6. Какую проблему на самом деле решает useEffect?

Отрисовка должна быть чистой функцией, преобразующей параметры и состояние в JSX. Приложения также загружают данные, привязывают обработчики событий, запускают таймеры и взаимодействуют с DOM — это побочные эффекты. useEffect выполняет такую нечистую работу после сохранения состояния, а не во время отрисовки:

useEffect(() => {
  const id = setInterval(() => console.log("tick"), 1000);
  return () => clearInterval(id); // cleanup
}, []);

Функция очистки, возвращаемая этим хуком, выполняется перед следующей итерацией эффекта и при демонтировании компонента. Если её пропустить, интервьюеры спросят о дублирующихся таймерах и обработчиках, которые продолжают работать после демонтирования.

7. Что на самом деле контролирует массив зависимостей?

Он указывает React, когда нужно снова выполнить эффект, путём поверхностного сравнения зависимостей:

• [] — один раз после монтирования
• [count] — снова при изменении count
• отсутствует — после каждой отрисовки (редко желательно)

Если забыть указать значение из массива, возникает устаревшая замыкание: эффект сохраняет первое зафиксированное значение навсегда. Существуют правила проверки на полную зависимость именно из-за того, что такие ошибки встречаются очень часто.

8. Контролируемые и неконтролируемые компоненты

Контролируемые элементы ввода берут значение value из состояния React и обновляются через onChange; правда всегда на стороне React.

Неконтролируемые элементы ввода сохраняют состояние DOM; оно считывается через ref при необходимости (часто при отправке формы).

// Controlled
<input value={name} onChange={e => setName(e.target.value)} />

// Uncontrolled
<input ref={inputRef} defaultValue="Dev" />

Режим с контролем включает реальную проверку и форматирование, но сопровождается перерисовкой интерфейса при каждом нажатии клавиши. Режим без контроля остаётся более лёгким, когда нужно только окончательное значение. Возможны смешанные формы — с некоторыми контролируемыми и неконтролируемыми полями, — но они затрудняют анализ при проверке кода.

9. Передача пропсов и момент остановки

Передача пропсов осуществляется через слои, которые лишь пересылают данные дальше. Переименование пропсов влияет на множество файлов. Контекст полезен для тем, авторизации или локализации; Redux или Zustand помогают, когда графы состояния становятся сложными. Нюанс: контекст не является бесплатным — каждый потребитель перерисовывается при изменении значения, поэтому он не подходит в качестве стандарта для всех общих полей. Передача пропсов на два уровня часто является более понятной, чем создание специального поставщика контекста для одноразового значения.

10. Когда стоит использовать useReducer вместо useState?

Используйте useReducer, когда обновления происходят в зависимости от типа действия, следующее состояние зависит от предыдущего в сложных случаях или несколько полей изменяются одновременно:

function reducer(state, action) {
  switch (action.type) {
    case "increment": return { count: state.count + 1 };
    case "reset": return { count: 0 };
    default: return state;
  }
}
const [state, dispatch] = useReducer(reducer, { count: 0 });

Это своего рода мини-Redux внутри компонента. Логика переключения состояния остается в useState; запутанная логика переходов должна находиться в одном тестируемом редьюсере. Вынесение этой логики из обработчиков событий JSX также делает юнит-тесты проще, поскольку не требуется отрисовка всей структуры компонента.

11. Объясните разницу между useMemo и useCallback, не ограничиваясь простым цитированием документации

Оба инструмента позволяют избежать повторной обработки данных между перерисовками для различных форм данных:

• useMemo хранит в кэше рассчитанное значение
• useCallback хранит в кэше ссылку на функцию

const sorted = useMemo(() => expensiveSort(list), [list]);
const handleClick = useCallback(() => doThing(id), [id]);

Идентичность функции имеет значение, поскольку при каждой перерисовке создается новый объект функции. Передача новой функции в дочерний элемент с использованием memo нарушает принцип мемоизации; useCallback обеспечивает стабильность ссылки. Не следует использовать эти хуки повсеместно — мемоизация имеет свои издержки. Применяйте их к ресурсоемким операциям или к дочерним элементам, которые уже мемоизированы. Преждевременная мемоизация — частая ошибка у начинающих разработчиков, которую интервьюеры любят подчеркивать.

12. React.memo полезен — но его легко обойти

React.memo пропускает перерисовку, если пропсы являются поверхностно идентичными. Новые литералы объектов или массивов считаются разными даже при идентичном содержимом, поэтому использование встроенного выражения { style: { color: 'red' } } делает memo бесполезным, если родительские элементы не стабилизируют пропсы с помощью useMemo/useCallback. В противном случае memo увеличивает нагрузку на сравнение, не предотвращая выполнение операций в дочерних элементах.

13. Ключи как идентификаторы, а не просто предупреждения консоли

Ключи — это система идентификации в React между перерисовками. Неправильные ключи приводят к повторному использованию неверного элемента DOM для неправильных данных: состояние формы остается у другой строки, анимации запускаются на неверном элементе, состояние useState для элемента списка сохраняет значение предыдущего элемента. Это выглядит как повреждение состояния, но на самом деле это ошибка с ключами. Демонстрация сломанного списка с индексными ключами в песочнице — один из самых быстрых способов усвоить это правило.

14. Контекст: подходящие и неподходящие применения

Контекст позволяет делиться значениями, необходимыми многим компонентам, без передачи их через пропсы — авторизованный пользователь, тема, локаль:

const ThemeContext = createContext();
<ThemeContext.Provider value={theme}>
  <App />
</ThemeContext.Provider>

Этот подход плохо подходит для работы с высокочастотными состояниями (значениями формы при каждом нажатии клавиши) в крупных структурах, поскольку каждый потребитель обновляется при любых изменениях без возможности селективной подписки. Для таких случаев лучше использовать хранилище с более тонкой настройкой подписок. Переключатели тем — классический пример хорошего соответствия контексту; положение курсора в совместном редакторе обычно таким не является.

15. Соответствие жизненных циклов классов эффектам

Примерное соответствие классов:

• componentDidMount → useEffect(..., [])
• componentDidUpdate → useEffect(..., [dep])
• componentWillUnmount → очистка эффектов

Более глубокая смена подхода: жизненные циклы ориентированы на время (загрузка/обновление/сброс); эффекты — на синхронизацию, то есть на поддержание соответствия этой внешней системы данным значениям, именно поэтому эффекты перезапускаются при изменении зависимостей. Попытки рассматривать эффекты как методы жизненного цикла, переводимые буквально по строкам, приводят к конфликтам с массивом зависимостей.

16. Состояние по сравнению с параметрами

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

17. Выявление ненужных повторных отрисовок без угадывания

Распространённые причины: передача новых литералов объектов/массивов/функций родителями, повторная отрисовка всех потребителей из-за частых изменений контекста или нахождение состояния на слишком высоком уровне. Не стоит догадываться — используйте профилятор React DevTools, зафиксируйте взаимодействие и посмотрите, какие свойства изменились. Чтобы решить проблему, обычно перемещают состояние на более низкий уровень или делят компоненты, чтобы дорогостоящие поддеревья не обрабатывались при дешёвых обновлениях, а не сразу покрывают всё useMemo. Профиляторы превращают ощущение медленной работы в конкретное объяснение проблемы с родителями и свойствами, которое можно устранить.

18. SSR по сравнению с CSR

CSR поставляет простую HTML-структуру вместе с JS; браузер формирует страницу после загрузки — быстро в обслуживании, но медленнее при отображении содержимого, исторически имел слабые позиции в SEO до запуска JS. SSR отправляет HTML по каждому запросу, затем выполняет процесс гидратации, добавляя обработчики событий — это улучшает первое отображение и SEO, но требует больше работы сервера. Next.js и подобные фреймворки добавляют возможности статической генерации и стриминга, однако основной компромисс остается между временем отклика сервера/SEO и затратами на обработку данных на сервере. Утверждение, что «SSR всегда лучше», без указания этого компромисса, является слабым ответом на вопросы во время собеседования.

19. Несоответствия при гидратации и причины их возникновения

Механизм гидратации привязывает React к серверному HTML, не удаляя маркировку. Несоответствия возникают, когда серверный HTML отличается от результата первой отрисовки на клиенте: использование Date.now() или Math.random() в процессе отрисовки, проверки через window, которые дают разные результаты на сервере, или вставка узлов с помощью расширений. React выдает явные предупреждения и часто перерисовывает содержимое на клиенте для восстановления ситуации — это добавляет дополнительную нагрузку и приводит к мгновенному отображению некорректного контента. Обычным способом предотвращения этого является защита API, доступных только в браузере, с помощью useEffect или специальных компонентов.

20. Почему React оборачивает нативные события в SyntheticEvent

Класс SyntheticEvent в React нормализует особенности разных браузеров (что позволяет свойству onChange вести себя одинаково) и ранее использовал делегирование событий на уровне корня вместо одного нативного обработчика на каждый узел. В React 17+ делегирование происходит в контейнер корня приложения, а не в объект document, но суть остается прежней. Раньше использовалось объединение объектов событий для их повторного использования, из-за чего при асинхронном доступе могло возвращаться значение null; с React 17 такой механизм устранён, однако наличие промежуточного слоя между событием браузера и обработчиком по-прежнему указывает на глубину структуры. Упоминание того, что внутри всё ещё существует объект e.nativeEvent, показывает, что вы понимаете, что данная абстракция является обёрткой, а не заменой модели событий DOM.

Что на самом деле ценят на собеседованиях

Хорошие ответы на вопросы во время собеседования объясняют проблему, её сложности и то, как вы бы помогли коллеге — а не просто заученное определение. Специалисты, проводящие собеседование, меньше интересуются тем, можете ли вы определить useEffect, и больше — тем, не столкнулись ли вы с проблемами из-за устаревших закрытий функций, отсутствия процедур очистки или ошибок в зависимостях, и можете ли вы объяснить причины. Попробуйте воспроизвести эти ошибки в среде тестирования перед собеседованием; примеры реальных проблем свидетельствуют о понимании темы. Определения помогут вам преодолеть первую минуту разговора; аргументы о компромиссах и примеры неудач будут формировать основу дальнейшего обсуждения.

Составьте краткий личный справочник с описанием ошибок, которые вы уже исправили — устаревшие эффекты, некорректные клавиши, несоответствия в уровне гидратации — и практикуйтесь объяснять каждую из них менее чем за минуту. Такая подготовка лучше, чем бессонная ночь перед собеседованием с изучением сигнатур API, и позволяет привести конкретные примеры, когда интервьюер просит рассказать о вашем опыте работы. Сопоставляйте каждый пример с реальным исправлением, чтобы ответ основывался не только на трудностях, но и на принятом решении. Именно этот финальный шаг отличает тех, кто просто «читал документацию», от тех, кто умеет работать с этой технологией в условиях давления.