Что относится к побочным эффектам

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

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

На интервью вам удобно идти в три шага. Сначала дайте критерий, потом приведите примеры, потом назовите практический риск. Такой код сложнее повторять, тестировать и безопасно отменять. Если эффект запустится не тогда, когда вы ожидали, UI может показать старые данные, создать лишний запрос или оставить незакрытую подписку.

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

Важно не смешивать похожие вещи. Date.now() и Math.random() не обязательно меняют внешний мир, но делают функцию недетерминированной. Запись в localStorage, вызов fetch, addEventListener или setInterval уже точно требуют контроля жизненного цикла.

В React тело компонента должно быть чистым описанием UI для текущих props и state. Поэтому во время render не стоит делать запросы, подписки, запись в storage и ручные изменения DOM. React может вызвать render повторно, пропустить результат или размонтировать и смонтировать компонент снова.

Плохой пример: запрос запускается во время render.

function UserCard({ userId }: { userId: string }) {
  // Плохо: это побочный эффект во время render.
  fetch(`/api/users/${userId}`);

  return <div>Loading...</div>;
}

Что сломается. Каждый повторный render может создать новый запрос. Старые ответы могут перезаписать свежие данные. В development вы увидите дубли. Безопаснее держать такой код там, где есть понятный lifecycle. Для простого client-side запроса это может быть useEffect. В приложениях с роутерами и фреймворками часто лучше использовать loader, server component, query library или другой слой данных.

Пример с контролем запроса, loading state и защитой от устаревшего результата:

function UserCard({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

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

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

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

        if (!response.ok) {
          throw new Error("Request failed");
        }

        const nextUser = await response.json();
        setUser(nextUser);
      } catch (error) {
        if (error instanceof DOMException && error.name === "AbortError") {
          return;
        }

        setError("Не удалось загрузить пользователя");
      } finally {
        if (!controller.signal.aborted) {
          setIsLoading(false);
        }
      }
    }

    loadUser();

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

  if (isLoading) return <p aria-live="polite">Loading...</p>;
  if (error) return <p role="alert">{error}</p>;
  if (!user) return <p>Пользователь не найден</p>;

  return <div>{user.name}</div>;
}

Здесь эффект зависит от userId. Старый запрос отменяется при смене id или размонтировании. Ошибка отмены не показывается пользователю как реальная ошибка. UI не оставляет на экране старого пользователя во время новой загрузки и отдельно показывает ошибку или пустое состояние. Это не единственный способ. Главное, что эффект имеет setup, зависимости и cleanup.

Самые понятные примеры для frontend-собеседования:

• HTTP-запросы через fetch или клиент API.
• Подписки на события: addEventListener, media query listener, WebSocket.
• Таймеры: setTimeout, setInterval, animation loop.
• Работа с браузерным хранилищем: localStorage, sessionStorage, cookies, IndexedDB.
• Ручное чтение или изменение DOM, измерение layout, focus management.
• Отправка аналитики, логирование, запись во внешние сервисы.
• Мутация внешних объектов, кэшей и глобальных переменных.

Не нужно перечислять все подряд. Выберите 4-5 примеров и для одного сразу назовите риск. Например, если подписаться на resize и не снять обработчик, компонент уже исчезнет, а обработчик продолжит работать.

Эффект лучше объяснять не как кусок кода, который просто запускается после render, а как синхронизацию с внешней системой. У синхронизации есть начало, обновление и завершение.

Для подписки начало это addEventListener, завершение это removeEventListener. Для таймера начало это setInterval, завершение это clearInterval. Для запроса начало это вызов API, а завершение может быть отменой через AbortController или проверкой, что ответ еще актуален.

Если вас спрашивают про повторный запуск эффектов, не называйте это багом React. В development Strict Mode помогает найти эффекты, которые не готовы к повторному mount или cleanup. Поэтому эффект не должен полагаться на то, что он выполнится ровно один раз за всю жизнь приложения.

Практический вывод такой. Не используйте глобальные флаги как основной способ запретить второй запуск. Лучше сделать effect setup и cleanup корректными. Если аналитика или платежный запрос действительно не должны дублироваться, это нужно решать на уровне события, идемпотентности API, ключа операции или серверной защиты, а не надеждой на один render.

Сильный ответ на этот вопрос звучит не как список терминов, а как правило для безопасного UI. Побочные эффекты неизбежны, потому что frontend общается с сетью, браузером и пользователем. Проблема не в самом эффекте, а в том, где он расположен и кто контролирует его жизненный цикл.

На интервью можно завершить так:

Я стараюсь держать вычисления и render чистыми, а эффекты изолировать. Для каждого эффекта проверяю, что его запускает, от каких данных он зависит, что произойдет при повторном запуске и как он очищается. Это снижает риск утечек, лишних запросов, stale data и странного поведения в React.