Senior React Frontend — Вопросы на собеседовании React разработчика

Что реально меняется, когда компонент становится серверным?

Он выполняется только на сервере, поэтому не отправляет JavaScript в браузер и может обращаться к базе напрямую, но не может хранить состояние, использовать эффекты и вешать обработчики. Настоящая работа — провести границу: интерактивные листья остаются клиентскими, всё выше может быть серверным. Пометка «use client» делает клиентским и всё, что компонент импортирует, и именно так бандл незаметно перестаёт уменьшаться.

У приложения плохой INP. Как подступиться?

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

Как решить, что относится к компоненту дизайн-системы, а что к фиче?

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

Ошибка гидратации возникает только в проде. Как отлаживать?

Это значит, что серверный HTML и первый клиентский рендер разошлись, и причин немного: Date.now или Math.random в рендере, чтение localStorage или window по пути рендера, форматирование по локали и таймзоне, расширения браузера, переписывающие DOM. Воспроизведите продовый рендер локально и делите дерево пополам. Подавить предупреждение — неверное решение: два дерева останутся реально разными.

Когда монорепозиторий во фронтенде оправдан, а когда это накладные расходы?

Оправдан, когда несколько приложений делят компоненты и вы хотите ревьюить и выпускать изменение сразу для всех, имея инструменты — Turborepo или Nx — для инкрементальных сборок. Накладными расходами становится для одного приложения с парой библиотек, где вы платите настройкой кеша и сложностью CI без нужды. Решающий вопрос — межпакетные изменения происходят еженедельно или дважды в год.

Как мигрировать большую кодовую базу с классовых компонентов на хуки?

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