Жизненный цикл компонента в React в 2026 году: от render до unmount

Термин «жизненный цикл» жив до сих пор, хотя React давно ушел от классового подхода. Причина простая: разработчикам по-прежнему нужно объяснять, что происходит с компонентом во времени — когда он появляется, обновляется и удаляется.

Классовые lifecycle-методы вроде componentDidMount или componentWillUnmount сегодня почти не актуальны для нового кода. Но сами фазы не исчезли. Они просто выражаются иначе: через render/commit-модель, эффекты и cleanup.

С появлением хуков понимание lifecycle стало менее «методоцентричным» и более системным. Важно не выучить список методов, а понимать пайплайн React: что происходит в render-фазе, что в commit, когда запускается эффект и когда выполняется очистка.

В 2026 году для junior/middle этого уже достаточно, чтобы пройти большинство интервью по React-архитектуре: объяснить фазы, разницу useEffect/useLayoutEffect, поведение StrictMode и базовые последствия concurrent rendering.

Если хотите углубить блок про эффекты отдельно, держите рядом useEffect: 15 сложных вопросов с разбором и React rendering: когда компонент перерисовывается.

Что вообще такое жизненный цикл

Жизненный цикл компонента — это последовательность фаз, через которые проходит компонент в React:

• компонент появляется (mount);
• компонент обновляется (update);
• компонент удаляется (unmount).

React управляет этим процессом сам. Разработчик не «запускает lifecycle вручную», он описывает интерфейс и логику, а React принимает решение, когда и как выполнять обновления.

Базовая схема:

Mount -> Update -> Unmount

Эта схема по-прежнему полезна, но в функциональных компонентах важно понимать ее через фазы работы React, а не через набор старых методов класса.

Современный lifecycle в функциональных компонентах

Mount (монтирование)

На монтировании происходит первый проход компонента:

1. Первый render (вызов функции компонента).
2. commit (изменения применяются к DOM).
3. Запуск эффектов (useEffect, useLayoutEffect с учетом их тайминга).

Классический пример «логики после монтирования»:

useEffect(() => {
  console.log("mounted");
}, []);

Важно: это не магический «mount-only метод». Это эффект с пустым массивом зависимостей, который после первого commit запускается один раз на жизненном цикле конкретного экземпляра компонента (с оговоркой про StrictMode в dev).

Update (обновление)

Обновление происходит, когда React решает, что компонент нужно пересчитать:

• изменился state;
• изменились props;
• обновился context;
• ререндер родителя затронул ребенка.

Порядок, который нужно четко понимать:

1. Новый render компонента.
2. commit изменений.
3. Для уже существующего эффекта: сначала cleanup предыдущей версии (если он есть).
4. Затем запуск новой версии эффекта.

То есть на update эффект не просто «запускается снова». React сначала корректно завершает прошлую подписку/ресурс, потом создает новый.

Unmount (размонтирование)

При размонтировании компонент удаляется из дерева React и DOM. Перед финальным удалением React выполняет cleanup всех активных эффектов.

Пример:

useEffect(() => {
  const id = setInterval(() => {
    // polling
  }, 1000);

  return () => clearInterval(id);
}, []);

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

Render vs Commit — ключ к пониманию lifecycle

Это один из самых важных блоков для middle-уровня.

Render-фаза:

• React вызывает функции компонентов;
• строит новое дерево элементов;
• сравнивает его с предыдущим.

Commit-фаза:

• React применяет изменения к DOM;
• вызывает эффекты и соответствующие хуки после фиксации обновления.

Отсюда две практические истины:

• render не равен обновлению DOM;
• компонент может быть вызван в render, но commit для него может не привести к заметным изменениям.

Когда запускаются эффекты:

• useEffect — после commit и обычно после paint (не блокирует отрисовку);
• useLayoutEffect — после commit, но до paint (может блокировать кадр).

Поэтому useLayoutEffect используют точечно: измерение layout, синхронная коррекция позиции, предотвращение визуального скачка. Во всех остальных кейсах предпочтителен useEffect.

Жизненный цикл и StrictMode в React 18/19

Один из самых частых вопросов: «Почему эффект вызывается дважды?»

В dev-режиме под StrictMode React 18/19 может выполнять проверочный цикл:

mount -> unmount -> mount

Это сделано специально, чтобы поймать:

• эффекты без корректного cleanup;
• неидемпотентные побочные действия;
• скрытые утечки.

Почему это не баг:

• в production такой двойной цикл не выполняется как часть StrictMode-проверки;
• dev-поведение помогает обнаружить реальные проблемы до релиза.

Если кандидат на интервью говорит «это баг React», это почти всегда красный флаг. Сильный ответ: «Это диагностический механизм dev-режима, который проверяет корректность cleanup и устойчивость эффекта».

Lifecycle в классовых компонентах (кратко для понимания)

Классические методы:

• componentDidMount
• componentDidUpdate
• componentWillUnmount

В функциональном подходе соответствие выглядит так:

Классы	Хуки
componentDidMount	useEffect([])
componentDidUpdate	useEffect([deps])
componentWillUnmount	cleanup-функция из useEffect

Но это только приближенное сопоставление для объяснения. Хуки гибче:

• можно разделять эффекты по ответственности;
• не нужно держать логику разных задач в одном методе;
• проще переиспользовать логику через кастомные хуки.

Именно поэтому в новом коде почти всегда выбирают функциональную модель.

Что происходит при каждом ререндере

Функциональный компонент — это функция. При каждом ререндере React вызывает ее заново.

Следствия:

• локальные переменные внутри функции создаются заново;
• выражения в теле компонента вычисляются заново;
• функции, объекты, массивы в теле получают новые ссылки (если не мемоизированы).

Почему state не «сбрасывается»:

• React хранит состояние хуков вне локальных переменных компонента;
• useState/useRef связываются с позицией хука в компоненте.

Типичный вопрос: Почему переменная сбрасывается при каждом рендере?

Потому что это обычная локальная переменная функции, а не React-state. Для сохранения значения между рендерами нужны useState или useRef.

Когда useEffect не нужен

Очень частая ошибка junior: писать useEffect «на всякий случай».

useEffect не нужен, если задача решается:

• как вычисляемое значение в render;
• в обработчике события;
• через derived state без отдельной синхронизации.

Пример лишнего эффекта:

const [fullName, setFullName] = useState("");

useEffect(() => {
  setFullName(`${firstName} ${lastName}`);
}, [firstName, lastName]);

Проще и корректнее:

const fullName = `${firstName} ${lastName}`;

На интервью это любят спрашивать именно как маркер зрелости: можете ли вы убрать эффект, если синхронизация с внешним миром не нужна.

Частые вопросы на собеседовании

Опишите жизненный цикл компонента в React.

Сильный ответ: компонент проходит фазы mount, update, unmount; React разделяет render и commit; эффекты запускаются после commit, cleanup — перед повторным запуском эффекта и при unmount.

Когда выполняется useEffect?

После commit-фазы. Он не выполняется в render и не должен использоваться для чистых вычислений интерфейса.

В каком порядке вызывается cleanup?

Для update: cleanup старого эффекта -> запуск нового эффекта. Для unmount: cleanup перед удалением компонента.

Почему useEffect вызывается дважды?

В dev StrictMode React имитирует дополнительный цикл mount/unmount/mount для проверки побочных эффектов и cleanup.

Чем useEffect отличается от useLayoutEffect?

useEffect не блокирует paint, useLayoutEffect выполняется до paint и может его блокировать. Поэтому layout-вариант — для специальных задач измерения/позиционирования.

Что происходит при изменении props?

Компонент получает новые props, проходит render, затем commit. Если зависимости эффекта изменились, React запускает cleanup старой версии эффекта и потом новый эффект.

Что тяжелее — render или commit?

Зависит от сценария. Иногда дорог render (сложные вычисления), иногда commit (много DOM-изменений/layout/paint). На практике это проверяется профилированием, а не догадками.

Частые ошибки кандидатов

• Думают, что useEffect и есть весь lifecycle.
• Не различают render и commit.
• Путаются в порядке cleanup и повторного запуска эффекта.
• Не знают про StrictMode-поведение в dev.
• Не могут объяснить, почему компонент вызывается заново как функция.

Эти ошибки особенно заметны на middle-собеседованиях, где ждут не определения, а причинно-следственную модель.

Как правильно отвечать на интервью

Рабочая формула ответа:

1. Объяснить mount/update/unmount.
2. Разделить render и commit.
3. Указать timing useEffect.
4. Добавить поведение StrictMode в dev.
5. Привести короткий пример с cleanup.

Пример короткого ответа (60-90 секунд):

«В React lifecycle — это фазы mount, update и unmount. В функциональных компонентах это выражается через render/commit-пайплайн и эффекты. Сначала React делает render, затем commit. useEffect запускается после commit, а cleanup выполняется перед следующим запуском эффекта и при unmount. В dev под StrictMode React может дополнительно проверить эффект через mount/unmount/mount, это не баг, а диагностика утечек.»

Lifecycle и Concurrent Rendering

В современной модели React lifecycle уже не выглядит как абсолютно жесткая линейная цепочка «вызвали -> сразу закоммитили».

Из важных идей:

• startTransition позволяет помечать часть обновлений как низкоприоритетные;
• render может быть прерываемым и переоцениваться;
• commit по-прежнему остается точкой фиксации изменений.

Почему это важно:

• вы не должны связывать бизнес-логику с предположением «каждый render обязательно сразу станет видимым»;
• эффекты должны быть устойчивыми к повторным вызовам и прерываниям;
• архитектура должна учитывать приоритеты обновлений, а не только «синтаксис хуков».

Для middle+ это важный сигнал зрелости: понимать, что lifecycle в 2026 — это фазы работы React-движка, а не набор «магических методов» из старой классовой эпохи.

Практический разбор lifecycle на одном примере

Рассмотрим упрощенный компонент профиля:

function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<{ name: string } | null>(null);

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

    fetch(`/api/users/${userId}`, { signal: controller.signal })
      .then((res) => res.json())
      .then(setUser)
      .catch((err) => {
        if (err.name !== "AbortError") throw err;
      });

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

  if (!user) return <p>Loading...</p>;
  return <h2>{user.name}</h2>;
}

Что происходит на mount:

1. React вызывает UserProfile (render).
2. В commit появляется <p>Loading...</p>.
3. После commit запускается useEffect.
4. Эффект стартует запрос пользователя.

Что происходит на update при смене userId:

1. Компонент ререндерится с новым userId.
2. React делает commit.
3. Cleanup старого эффекта вызывается (abort старого запроса).
4. Запускается новая версия эффекта с новым userId.

Что происходит на unmount:

1. Перед удалением компонента React вызывает cleanup.
2. Активный запрос отменяется.
3. Компонент удаляется из DOM.

Почему этот пример полезен для интервью:

• показывает, что вы понимаете порядок cleanup;
• демонстрирует защиту от утечек и race condition;
• объясняет lifecycle без классовых методов.

Частый follow-up от интервьюера: «А что если убрать cleanup?»
Сильный ответ: можно получить попытку обновить состояние после размонтирования, лишнюю сетевую активность и непредсказуемую перезапись данных при быстрых переключениях userId.

Тонкости порядка вызовов, которые часто путают

Есть несколько деталей, на которых кандидаты ошибаются даже при хорошем общем уровне:

1. Cleanup предыдущего эффекта вызывается перед запуском новой версии эффекта, а не «когда-то потом».
2. useEffect и useLayoutEffect имеют разный timing: второй может блокировать paint.
3. Локальные переменные рендера не сохраняются между рендерами, если это не state/ref.
4. В dev StrictMode вы видите дополнительные вызовы именно для диагностики.

Отдельно про родителя и ребенка: порядок эффектов между уровнями дерева сложнее, чем «сначала родитель, потом ребенок везде одинаково». На интервью обычно не требуют точной внутренней очередности по всем хукам, но ждут, что вы не будете делать бизнес-логику, зависящую от предположений о «глобальном фиксированном порядке» эффектов.

Практическое правило: эффекты должны быть самодостаточными и корректными независимо от того, как React распланирует обновление в рамках своей модели.

Как применить это в реальном проекте

Если вы хотите, чтобы lifecycle-понимание реально помогало в разработке, используйте такой алгоритм:

1. Для каждой логики ответьте: это чистый расчет, событие пользователя или синхронизация с внешним миром.
2. Если это синхронизация, выбирайте useEffect/useLayoutEffect осознанно по timing.
3. Сразу продумывайте cleanup: подписки, таймеры, запросы, listeners.
4. Проверяйте поведение в StrictMode, а не выключайте его при первой странности.
5. Профилируйте render и commit отдельно, когда ищете узкое место.

Такой подход заметно снижает количество «плавающих» багов и делает код предсказуемым для команды.

FAQ

Есть ли lifecycle в функциональных компонентах?

Да. Фазы mount/update/unmount никуда не исчезли, изменился способ взаимодействия с ними: через хуки и модель render/commit.

useEffect заменяет все lifecycle-методы?

Нет в буквальном смысле «один в один», но он покрывает большую часть сценариев post-commit синхронизации и cleanup.

Почему React вызывает компонент как обычную функцию?

Потому что функциональный компонент и есть функция, которая возвращает описание UI. React повторно вызывает ее при обновлениях, чтобы получить новое дерево.

Можно ли контролировать порядок lifecycle?

Вы можете влиять на причины обновлений и структуру дерева, но внутренний порядок фаз определяет React. Ломать эту модель предположениями о «ручном контроле» — частый источник багов.

Итоги

Жизненный цикл компонента — это фазы работы React, а не набор «магических методов».

В 2026 ключевой уровень понимания — render/commit, timing эффектов и корректный cleanup.

useEffect — важная часть lifecycle, но не весь lifecycle целиком.

На middle-собеседованиях проверяют глубину понимания механики и аргументацию решений, а не знание терминов изолированно.