Почему нельзя вызывать хуки условно?
Одним из самых строгих и важных правил при написании кода на React является запрет на вызов хуков внутри условных операторов, циклов или вложенных функций. Архитектура библиотеки спроектирована таким образом, что React не использует уникальные ключи или строковые идентификаторы для различения разных вызовов хуков между собой. Вместо этого вся внутренняя работа построена на строгом порядке вызова хуков от рендера к рендеру, который формируется в единой последовательности.
Представьте себе массив или связный список, в который записываются состояния и эффекты компонента во время первого рендеринга. Если на втором рендере из-за условной конструкции if какой-то из хуков пропустится, весь последующий список сместится, и React начнет сопоставлять данные совершенно не с теми переменными состояния. Это приводит к критическим ошибкам, падению приложения или ситуации, когда состояние одного компонента неожиданно перезаписывается данными из другого места.
Для предотвращения подобных архитектурных ошибок в экосистему React встроены статические анализаторы кода, которые жестко пресекают попытки нарушить это правило на этапе сборки проекта. Правило гласит, что все хуки обязаны вызываться исключительно на самом верхнем уровне функционального компонента, до любых возможных возвратов инструкций вроде return и до любых ветвлений логики интерфейса. Это гарантирует, что структура хуков останется абсолютно идентичной при каждом новом запуске компонента.
Если возникает необходимость выполнить какую-то логику или вызов хука в зависимости от определенного условия, это условие никогда не должно выноситься на уровень вызова самого хука. Правильным подходом является перенос проверки внутрь тела уже вызванного хука или эффекта. Например, если вам нужно отправить запрос только для авторизованного пользователя, вы вызываете useEffect всегда, а уже внутри него проверяете булеву переменную авторизации и на ее основе принимаете решение о выполнении полезной работы.
Соблюдение этого правила не только спасает проект от труднодиагностируемых багов, но и делает кодовую базу более понятной, читаемой и предсказуемой для других разработчиков. Понимание того, что состояние компонента и его эффекты детерминированы и всегда выполняются в одном и том же порядке, позволяет уверенно масштабировать проекты любой сложности без страха разрушить внутреннюю логику фреймворка.