Нужен ли здесь `useEffect`? 12 сценариев из React-код-ревью — от производного состояния до React 19.2

[cmyser]

жаль что нет комментариев при 15 лайках и 32 закладках
сделал омаж-статью https://habr.com/ru/articles/1056766/ , интересно ваше мнение, Виктор

[Viktoriko]

Спасибо большое! Очень приятно, что статья не просто попала в закладки, но ещё и стала поводом для омаж-материала.

Прочитал статью — получилось действительно интересно. Я сам с $mol в боевых проектах не работал, поэтому было особенно любопытно посмотреть на похожую тему через другую призму и сравнить подходы со своей статьёй. Как раз такие материалы хорошо расширяют взгляд: видно, что одну и ту же задачу можно разложить и решить совсем по-разному.

Спасибо, что поделились. Буду рад продолжению и новым материалам — тема точно заслуживает обсуждения.

[cmyser]

😉✌️

[alex_keysi]

Я бы ещё в шаг "Нужно скорректировать состояние" чек листа добавил вариант решения - https://react.dev/learn/you-might-not-need-an-effect#adjusting-some-state-when-a-prop-changes.

Из последнего что помнню, заместо хука useeffect с пустым массивом, можно сразу при рендере сделать setstate, убирая доп рендер.

[Viktoriko]

Спасибо за дополнение! Да, такой вариант в официальной документации React действительно есть, и для полноты его стоило упомянуть. Обновил пункт 4, согласно комментарию и документации.

При частичной корректировке состояния React допускает условный setState непосредственно во время рендера. В таком случае текущий результат рендера отбрасывается, и React сразу повторяет рендер до обновления DOM, поэтому дочерние компоненты не успевают отрисоваться с устаревшим значением.

При этом я бы уточнил два момента. Речь здесь всё-таки не про useEffect с пустым массивом, а про эффект с зависимостью от изменившегося prop, например [items]. И сам React рассматривает обновление состояния во время рендера скорее как запасной вариант: сначала рекомендует проверить, нельзя ли сбросить состояние через key или вообще не хранить корректируемый объект в состоянии.

В статье я показал именно последний вариант: хранить selectedId, а актуальный selection вычислять из нового списка. Но согласен, что условный setState во время рендера стоит добавить в чек-лист как отдельный допустимый вариант для случаев, когда состояние нельзя просто вычислить. Обновил и чек-лист.

Спасибо!