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

Когда useMemo реально помогает, а когда это шум?

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

Компонент перерисовывается гораздо чаще ожидаемого. Как выяснить почему?

Открыть Profiler, записать взаимодействие и посмотреть «why did this render» — пропсы, состояние или родитель. Обычные причины: объект или стрелочная функция, созданные инлайн в родителе, контекст, значение которого пересоздаётся каждый рендер, и состояние, поднятое выше, чем нужно. Чинить надо причину, а не накрывать React.memo, который её лишь прячет.

Какую задачу решает Context и где он становится неверным инструментом?

Context избавляет от протаскивания значения через компоненты, которым оно безразлично — тема, локаль, текущий пользователь. Неверным он становится для часто меняющегося состояния: при изменении значения перерисовываются все потребители, и нет селектора, чтобы подписаться на часть. С этого момента нужна библиотека состояния с подписками, а не один контекст, в котором лежит всё.

Зачем нужна библиотека вроде TanStack Query вместо useEffect и fetch?

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

Чем useEffect отличается от useLayoutEffect?

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

Как обработать ошибку, брошенную во время рендера?

Её ловит error boundary и показывает запасной интерфейс вместо белой страницы, потому что непойманная ошибка рендера размонтирует всё дерево. Границы не ловят ошибки в обработчиках событий и в асинхронном коде — это как раз то, что упускают, там нужен обычный try/catch. Ставить границы стоит вокруг осмысленных секций, чтобы один сломанный виджет не уносил экран.

Где размещать разбиение кода в React-приложении?

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