Какова стратегия использования React хуков и когда их применять

Что проверяют

Знаете ли вы, какой хук под какую задачу, а не просто список из документации. Главный маркер уровня: понимаете ли вы, когда useEffect не нужен. Следом обычно спрашивают про мемоизацию и про то, как вы выносите логику в свои хуки.

Как отвечать

Стройте ответ от задачи к хуку:

• локальное состояние: useState, а при сложных взаимозависимых переходах useReducer с явными действиями;
• производные данные: считаются прямо в рендере, без состояния и без эффекта. Дорогой расчёт оборачивается в useMemo;
• синхронизация с внешним миром: useEffect для подписок, таймеров, запросов, обязательно с функцией очистки. useLayoutEffect только когда нужно замерить DOM до отрисовки;
• внешний стор: useSyncExternalStore, так подписка корректна при конкурентном рендере;
• значение без перерисовки: useRef для DOM-узла, id таймера, предыдущего значения;
• отзывчивость: useTransition и useDeferredValue помечают тяжёлое обновление как несрочное;
• формы в React 19: useActionState, useOptimistic, useFormStatus из react-dom. Хук use читает промис или контекст и, в отличие от остальных, может вызываться внутри условия.

Остальные хуки вызываются только на верхнем уровне компонента или своего хука. Повторяющаяся связка выносится в кастомный хук с префиксом use. Он делится логикой, а не состоянием: у каждого компонента своя копия.

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

Где спотыкаются

Кладут в useEffect вычисление производного состояния: эффект зовёт setState, получается лишний рендер, а иногда и цикл. Если значение выводится из пропсов и состояния, эффект не нужен.

Глушат правило react-hooks/exhaustive-deps вместо того, чтобы разобраться с зависимостями. Отсюда устаревшие замыкания: обработчик видит значение из первого рендера.

Забывают очистку. Подписка или setInterval без возвращаемой из эффекта функции течёт, а StrictMode в разработке запускает эффект дважды, и проблема вылезает сразу.