Возможно, эффект тебе не нужен

Если это можно вычислить из пропсов и состояния во время рендера — это не состояние, и в эффекте ему не место. Классический анти-паттерн хранит производное значение в useState и держит его актуальным эффектом. Это два рендера на каждое изменение (поставить источник, эффект сработал, поставить производное, рендер снова), окно, где эти двое расходятся, и целый массив зависимостей, который легко испортить. Исправление — вычислять инлайн прямо при рендере.

// ❌ производное состояние, синхронизированное эффектом: лишний рендер, может протухнуть
function FullName({ first, last }: { first: string; last: string }) {
  const [full, setFull] = useState("");
  useEffect(() => { setFull(`${first} ${last}`); }, [first, last]);
  return <h2>{full}</h2>;
}

// ✅ просто вычисли это — всегда согласованно, один рендер
function FullName({ first, last }: { first: string; last: string }) {
  const full = `${first} ${last}`;
  return <h2>{full}</h2>;
}

Рендер и есть синхронизация. Каждый раз, когда ловишь себя на написании setSomething внутри эффекта, чьи единственные входы — другие пропсы/состояние, тебе почти наверняка нужен обычный const.

Преобразование данных для отображения — тот же анти-паттерн, но со списком вместо строки, и с тем же исправлением. Фильтрация, сортировка, маппинг загруженного массива во view-модели: ничто из этого не трогает внешнюю систему, значит, ничто не место в эффекте. Вычисляй в рендере. Если — и только если — профилирование показывает, что преобразование действительно дорогое и выполняется на каждый несвязанный рендер, оберни его в useMemo. useMemo — это кэш времени рендера, а не эффект; он никогда не вызывает двойной-рендер-затем-вспышку, как версия с эффектом.

// ❌ эффект зеркалит производный список в состояние
const [visible, setVisible] = useState<Todo[]>([]);
useEffect(() => {
  setVisible(todos.filter((t) => t.status === filter));
}, [todos, filter]);

// ✅ выводи в рендере; мемоизируй, только если профилирование скажет, что фильтр горячий
const visible = useMemo(
  () => todos.filter((t) => t.status === filter),
  [todos, filter],
);

Тянись за useMemo, потому что так сказал замер, а не рефлекторно. Немемоизированный .filter() по паре сотен строк — нормально, а useMemo повсюду — просто шум, скрывающий тот единственный, который важен.

Чтобы сбросить состояние при смене пропса, дай компоненту key — не сбрасывай его эффектом. Частая форма: редактор профиля держит черновик состояния, а эффект очищает черновик всякий раз при смене userId. Этот эффект рендерит черновик старого пользователя один кадр, прежде чем сброс зафиксируется, и ему приходится перечислять каждый кусок состояния для очистки. У React уже есть примитив для «теперь это концептуально другой экземпляр»: смени key, и React размонтирует старое поддерево и смонтирует свежее с начальным состоянием. Ни эффекта, ни протухшего кадра, ни перечисления.

// ❌ эффект сбрасывает локальное состояние при смене идентичности — вспышка старого черновика
function Editor({ userId }: { userId: string }) {
  const [draft, setDraft] = useState("");
  useEffect(() => { setDraft(""); }, [userId]); // ещё: забыли про остальные 3 поля
  /* ... */
}

// ✅ key заставляет React перемонтировать свежий экземпляр — всё состояние сбрасывается атомарно
function EditorBoundary({ userId }: { userId: string }) {
  return <Editor key={userId} userId={userId} />;
}
function Editor({ userId }: { userId: string }) {
  const [draft, setDraft] = useState(""); // стартует чистым на каждый userId, без эффекта
  /* ... */
}

key живёт уровнем выше, на родителе, который решает идентичность. Это самый высокорычажный эффект на удаление: он убирает целый класс багов «почему форма показывает данные предыдущей записи».

Уведомляй родителя, запускай сайд-эффекты и связывай апдейты внутри обработчика события — не в эффекте, следящем за состоянием. Здесь живут два родственных запаха. Первый — уведомление родителя: эффект, вызывающий onChange(value) после изменения value, срабатывает на любую причину изменения (включая пришедшие от родителя) и опаздывает на рендер. Помести вызов в обработчик, вызвавший изменение, где новое значение тебе уже известно. Второй — цепочки апдейтов: установка состояния A в эффекте, следящем за состоянием B, которое ставит C в эффекте, следящем за A, — это каскад лишних проходов рендера, который невозможно отследить. Вычисли всё следующее состояние в обработчике и поставь его в одном месте.

// ❌ эффект зеркалит изменение наверх к родителю — лишний рендер, срабатывает на любом пути
function Toggle({ onChange }: { onChange: (on: boolean) => void }) {
  const [on, setOn] = useState(false);
  useEffect(() => { onChange(on); }, [on]); // да и onChange даже нет в зависимостях
  return <button onClick={() => setOn((v) => !v)}>{on ? "On" : "Off"}</button>;
}

// ✅ делай обе вещи в одном месте, где есть новое значение: в обработчике
function Toggle({ onChange }: { onChange: (on: boolean) => void }) {
  const [on, setOn] = useState(false);
  function handleClick() {
    const next = !on;
    setOn(next);
    onChange(next); // родитель узнаёт сразу, в том же событии
  }
  return <button onClick={handleClick}>{on ? "On" : "Off"}</button>;
}

Обработчики событий запускаются, потому что пользователь что-то сделал; эффекты запускаются после рендера, по любой причине. Когда причина — конкретное взаимодействие, обработчик — правильный дом: он раньше, у него новое значение под рукой, и он не сработает на несвязанных перерисовках.