Что если передать массив в useEffect

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

Короткий ответ на интервью можно построить так:

Массив в useEffect это массив зависимостей. Если он пустой, эффект запускается после первого коммита и чистится при размонтировании. Если в нем есть значения, эффект повторится при изменении любого из них. Если второго аргумента нет, эффект будет запускаться после каждого рендера.

После этого добавьте практический риск. Неправильные зависимости приводят к устаревшим данным, лишним запускам, лишним запросам и циклам рендера.

На интервью важно не смешать три случая. Синтаксис похож, но поведение разное.

// 1. После каждого рендера
useEffect(() => {
  console.log("render happened");
});

// 2. После первого коммита, затем cleanup при размонтировании
useEffect(() => {
  console.log("mounted");
}, []);

// 3. После первого коммита и при изменении userId
useEffect(() => {
  console.log("user changed", userId);
}, [userId]);

Вариант без массива не всегда ошибка. Он нормален, если эффект должен синхронизироваться после каждого рендера. Но для запросов, таймеров и setState такой вариант часто опасен. Любое обновление компонента снова запустит эффект.

React сравнивает элементы массива зависимостей с предыдущими значениями через Object.is. Для примитивов это обычно ожидаемое поведение. Для объектов, массивов и функций важна ссылка.

Проблемный пример:

function Users({ status }) {
  const filters = { status };

  useEffect(() => {
    fetchUsers(filters);
  }, [filters]);
}

Здесь filters создается заново на каждом рендере. Даже если status не изменился, ссылка новая. Значит, эффект может запускаться лишний раз.

Более безопасный вариант:

function Users({ status }) {
  useEffect(() => {
    const filters = { status };
    fetchUsers(filters);
  }, [status]);
}

Теперь зависимость отражает реальную причину запроса. Если статус не меняется, эффект не запускается только из-за нового объекта.

Хорошая формулировка звучит так: зависимости должны соответствовать значениям, которые эффект читает из компонента. Если эффект использует userId, token или enabled, эти значения должны быть в массиве зависимостей, если только вы не переписали код так, что они больше не нужны.

Не стоит говорить, что вы уберете зависимость, чтобы эффект не срабатывал. Это выглядит как борьба с симптомом. Лучше сказать, что вы проверите, почему зависимость нестабильна, и измените код так, чтобы эффект оставался корректным.

Бесконечный цикл часто появляется, когда эффект обновляет state, который сам заставляет эффект снова выполниться. Иногда это нужно, но тогда должно быть условие остановки.

Проблемный пример:

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    setCount(count + 1);
  }, [count]);

  return <span>{count}</span>;
}

Эффект меняет count. Изменение count снова запускает эффект, и цикл продолжается. В браузере это может заморозить интерфейс, заспамить аналитику или отправить серию одинаковых запросов, если внутри эффекта есть сеть. Если вам нужно один раз вычислить начальное значение, лучше сделать это в инициализаторе useState или добавить понятное условие.

Обратная ошибка это stale closure. Она возникает, когда эффект использует значение, но вы не указали его в зависимостях. Код может долго выглядеть рабочим. Потом он начнет отправлять запрос со старым id или использовать старый callback.

Для запросов важен не только массив зависимостей. Нужна еще отмена устаревшей работы. Если userId меняется быстро, старый запрос может завершиться позже нового и перезаписать актуальные данные.

function UserCard({ userId }) {
  const [user, setUser] = useState(null);
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController();

    async function loadUser() {
      setIsLoading(true);
      setError(null);

      try {
        const response = await fetch(`/api/users/${userId}`, {
          signal: controller.signal,
        });

        if (!response.ok) {
          throw new Error("Failed to load user");
        }

        const data = await response.json();
        setUser(data);
      } catch (error) {
        if (error.name !== "AbortError") {
          setError(error);
        }
      } finally {
        if (!controller.signal.aborted) {
          setIsLoading(false);
        }
      }
    }

    loadUser();

    return () => {
      controller.abort();
    };
  }, [userId]);

  if (isLoading) return <p>Loading user...</p>;
  if (error) return <p role="alert">Could not load user.</p>;

  return <pre>{JSON.stringify(user, null, 2)}</pre>;
}

Здесь [userId] говорит, когда нужно загрузить другого пользователя. Cleanup отменяет предыдущий запрос перед новым запуском эффекта и при размонтировании компонента. Проверка response.ok, loading и error state не дают показывать старые данные как успешный ответ. role="alert" помогает озвучить ошибку пользователям скринридеров.

Сильный ответ не должен быть длинным. Достаточно назвать поведение и сразу показать, что вы понимаете риски.

В useEffect массив во втором аргументе это список зависимостей. С пустым массивом эффект не будет повторяться из-за ререндеров, с массивом значений он повторится при изменении любого значения, без массива он запускается после каждого рендера. Я бы отдельно следил за тем, чтобы зависимости были полными, потому что иначе будет stale closure. А если эффект делает запрос, подписку или таймер, я добавлю cleanup.

Такая формулировка звучит спокойнее, чем фраза про полный аналог componentDidMount. Она показывает, что вы думаете не только о синтаксисе, но и о поведении UI.