Подъём состояния и колокация: состояние живёт у ближайшего общего владельца

Один владелец: данные вниз, события вверх

Состояние в React локально по построению: useState принадлежит ровно одному экземпляру компонента, и этот экземпляр — единственный владелец, единственное место, где значение может измениться. Когда одно и то же изменяющееся значение нужно двум компонентам, его не дублируют (две копии обязательно разъедутся; баг-репорт звучит как «чип фильтра активен, а список не отфильтрован»). Его поднимают: находят самый нижний компонент, который является предком всех читателей — ближайшего общего владельца, — переносят состояние туда, передают значение вниз пропсами, а обработчики изменений — вниз детям, чтобы те могли запрашивать обновления. Данные текут вниз, события — вверх, и у каждого куска состояния один источник истины.

function SearchSection() {
  // Ближайший общий владелец <SearchInput> и <ResultsList>:
  // query нужен обоим, поэтому живёт здесь — и не выше.
  const [query, setQuery] = useState("");
  return (
    <section>
      <SearchInput value={query} onChange={setQuery} />
      <ResultsList query={query} />
    </section>
  );
}

function SearchInput({ value, onChange }) {
  // Контролируемый: компонент ничем не владеет; он сообщает намерение наверх.
  return <input value={value} onChange={(e) => onChange(e.target.value)} />;
}

Ключевое слово — ближайший. Подъём — это не «унести наверх», а «поднять ровно до первого общего предка и остановиться». Каждый уровень выше этой точки добавляет подписчиков, которым значение не нужно.

Зона поражения: почему высота — это решение о производительности

Когда вы видите компоненты, ре-рендерящиеся без видимой причины, первый вопрос — структурный: как высоко сидит их владелец? Когда состояние меняется, React ре-рендерит компонент-владельца и затем, по умолчанию, всё его поддерево — каждый потомок вызывается заново, читает он изменившееся значение или нет. (Ре-рендер — это дешёвая фаза render, а не мутация DOM, но вызывать 1 400 функций и согласовывать их вывод 60 раз, пока человек печатает, — не бесплатно.) Высота куска состояния, таким образом, задаёт его зону поражения: состояние в листе ре-рендерит лист; состояние в корне ре-рендерит приложение. Это и есть механизм анти-паттерна «глобально по умолчанию» — складывать всё в корневой стор или верхнеуровневый контекст не просто запутывает код: каждая запись становится рендером всего приложения, и дальше приходится отбиваться React.memo на сотнях компонентов. Колокация (colocation — хранение состояния там, где оно используется) — обратная дисциплина: заметив, что значение читает лишь одно поддерево, опустите состояние обратно вниз. Спуск состояния — чистый выигрыш: меньше рендеров, меньше протаскивания пропсов, и компонент становится удаляемым целиком.

Композиция: изоляция состояния через проп children

Есть структурный приём, который для типового случая бьёт мемоизацию: передавайте тяжёлые поддеревья как children. Дети в JSX — это элементы, объекты, создаваемые там, где JSX написан, а не там, где он рендерится. Если обёртка с состоянием получает содержимое через children, её ре-рендер переиспользует те же самые объекты-элементы, что ей передали (родитель, который их создал, не ре-рендерился). React видит идентичную ссылку на элемент и выходит досрочно, не ре-рендеря это поддерево вовсе.

function ScrollTracker({ children }) {
  const [y, setY] = useState(0); // обновляется на каждый тик скролла
  // children создал родитель, и они не менялись —
  // та же ссылка на элемент, поэтому React пропускает их ре-рендер.
  return <div onScroll={(e) => setY(e.target.scrollTop)}>
    <ProgressBar y={y} />
    {children}
  </div>;
}

// <ScrollTracker><HeavyTable rows={rows} /></ScrollTracker>
// HeavyTable НЕ ре-рендерится на скролл.

Это изоляция состояния архитектурой: высокочастотное состояние (скролл, hover, черновики ввода) получает узкий компонент для жизни, а тяжёлое содержимое проходит сквозь него нетронутым. Компромисс: подъём и колокация — это рефакторинг при каждом сдвиге требований: значение, нужное сегодня одному компоненту, завтра получает второго читателя, и его придётся переносить. Это трение реально, и это честная цена контроля зоны поражения; команды, отказывающиеся её платить, сползают обратно к «глобально по умолчанию» и платят рендерами. Сценарий отказа: дублирование состояния вместо подъёма («заведу ещё и локальную копию») — два владельца, неизбежное расхождение и класс багов, где UI противоречит сам себе.