> Как работает состояние счетчика при ререндере в React? (React)

Короткий ответ

Состояние счетчика при ререндере в React сохраняется благодаря замыканиям и механизму хука useState. Каждый вызов useState создает пару "текущее значение + setter", привязанную к конкретному fiber-узлу. При ререндере React берет сохраненное значение из очереди обновлений этого узла, а не пересоздает его. Если счетчик объявлен как обычная переменная (не через useState), его значение сбрасывается при каждом рендере.

Подробное объяснение

Когда компонент ререндерится, React повторно выполняет его тело функции. Все переменные, объявленные внутри компонента без хуков, создаются заново. Но useState хранит состояние вне компонента - в специальной структуре данных, связанной с fiber-узлом. При первом рендере useState инициализирует состояние и записывает его в очередь обновлений fiber-узла. При последующих рендерах React извлекает текущее значение из этой очереди, игнорируя переданный initial value (кроме случая с функцией-инициализатором, которая тоже выполняется только один раз).

Важно: setter из useState не меняет значение мгновенно. Он добавляет обновление в очередь, и React применяет его перед следующим рендером. Это гарантирует, что в рамках одного рендера состояние остается константным. Если вызвать setter несколько раз подряд с одинаковым значением, React может объединить эти обновления и выполнить только один ререндер.

На практике

Для счетчика типичный паттерн - использовать функциональную форму setter: setCount(prev => prev + 1). Это гарантирует, что при нескольких вызовах подряд (например, в цикле или после асинхронной операции) каждое обновление будет опираться на актуальное предыдущее значение, а не на устаревшее замыкание. Если передавать просто setCount(count + 1), то при нескольких вызовах в одном синхронном блоке все они увидят одно и то же count, и счетчик увеличится только на 1.

Также стоит помнить о Strict Mode в React 18+: он дважды вызывает функцию компонента в development, чтобы выявить побочные эффекты. Это не влияет на итоговое состояние, но может сбить с толку при отладке.

Пример кода

JSX
import { useState } from 'react';

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

  // Правильно: функциональное обновление
  const handleIncrement = () => {
    setCount(prev => prev + 1);
  };

  // Неправильно: может привести к багу при batch-обновлениях
  const handleIncrementBug = () => {
    setCount(count + 1);
  };

  return (
    <div>
      <p>Счетчик: {count}</p>
      <button onClick={handleIncrement}>+1</button>
    </div>
  );
}

Как отвечать на собеседовании

Начни с ключевого механизма: useState хранит состояние вне компонента, в fiber-дереве. Объясни, что при ререндере React не пересоздает состояние, а берет его из очереди обновлений. Упомяни, что замыкания в колбэках могут захватывать устаревшее значение, поэтому для счетчика предпочтительна функциональная форма setter. Если спросят про производительность - отметь, что React батчит обновления и может пропустить ререндер, если новое состояние равно предыдущему (сравнение через Object.is).

Что проверяет интервьюер

• Понимание разницы между локальной переменной и состоянием хука
• Знание механизма замыканий в контексте React
• Умение объяснить, почему функциональная форма setter важна для асинхронных сценариев
• Осведомленность о batch-обновлениях и оптимизациях React
• Понимание жизненного цикла компонента и fiber-архитектуры

Типичные ошибки

• Утверждение, что useState хранит состояние в самом компоненте или в замыкании
• Игнорирование проблемы устаревших замыканий при множественных вызовах setter
• Путаница между useState и useRef - последний не вызывает ререндер
• Предположение, что setter изменяет состояние синхронно
• Забывание про Strict Mode и двойной вызов функции в development