Какие задачи не нужно решать через useEffect?
- You might not need an effect
Эффект — для синхронизации с внешней системой (подписка, таймер, сторонний виджет, запрос). Лишние эффекты: вычисление из props и state (считать при рендере), реакция на событие пользователя (код в обработчике, а не в эффекте, следящем за state), сброс состояния при смене props (key на компоненте), цепочки эффектов, обновляющих state друг друга. Загрузку данных лучше отдать библиотеке (TanStack Query) или фреймворку — они решают гонки, кэш и повторы.
- Каждый лишний эффект — лишний рендер и риск рассинхронизации
- Эффект с только setState внутри — почти всегда ошибка
- В StrictMode эффекты в разработке запускаются дважды — так ловят отсутствие очистки
А ещё Вопрос: «почему этот код должен выполниться — из-за показа компонента или из-за действия пользователя?»
Подробно
// плохо: отправка формы через эффект
useEffect(() => { if (submitted) post(data); }, [submitted]);
// хорошо
function handleSubmit() { post(data); }Что хотят услышать
- Эффект — для внешних систем.
- Вычисления — при рендере, события — в обработчиках.
- Сброс через key, данные через библиотеку.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Отправку формы правильно делать в эффекте, следящем за флагом submitted
- ✓Эффект — для синхронизации с внешним миром; вычисления — при рендере, реакции — в обработчиках
- ✗Вычислять отфильтрованный список в useEffect с setState, чтобы не тормозить рендер компонента
- ✗Любой код, который должен выполниться, нужно помещать в useEffect
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.