javascript

Как устроено состояние в React.js

  • среда, 2 сентября 2026 г. в 00:00:12
https://habr.com/ru/articles/1073434/

Что поисковики и ИИ предлагают учить перед собеседованиями? Чаще всего — что-то в духе списка вопросов с гитхаба.

github.com/sudheerj/reactjs-interview-questions
github.com/sudheerj/reactjs-interview-questions

И как это учить? Тупо нажимать на каждый ответ и заучивать разницу в синтаксисе?

А на собесе потом:

— Расскажите про состояние на фронте.
useState нужен для маленького состояния, useContext — для чуть больших приложений. Для совсем больших берём Redux. Иногда можно и Jotai.

— А в чём разница?
— Для 
useState не нужен <Provider>, для Redux — нужен.

— Вы описываете синтаксис. Его любой ИИ знает лучше вас. А в чём вообще разница между подходами? Почему Jotai не требует <Provider>?
— 🫠

Если учить синтаксис сейчас бессмысленно, то как учить архитектуру? Redux — это шаблон «Одиночка»? Jotai — «Состояние»? Или наоборот?

Собесы

Я — ведущий разработчик интерфейсов в трансконтинентальном проекте. Провожу собеседования и часто вижу отличные знания синтаксиса, списанные с ИИ, и ноль понимания, зачем это всё и почему не по-другому.

Так что тогда проверять на собеседованиях в 2026 году? Или лучше — что вообще нужно инженеру после того, как написание кода стало бесплатным?

Состояние на фронте — это две-три концепции, размноженные на сотни библиотек. Сложность этих концепций — ерунда на постном масле.

История

  • 2007 год, Gmail. Вот где были настоящие задачи по контролю состояния на фронте. Как справились без React и MobX? 🤓

  • 2015 год, Redux. Я уже показывал, что сначала это была часть React. Потом проект распилили на два.

  • 2019 год, React Hooks. Redux уже существовал. Зачем тогда сделали useReducer?

  • 2022 год, Jotai. Почему этой библиотеке не нужен <Provider>?

Концепции

Достаточно один раз разобраться в паре концепций, чтобы почувствовать: различия в синтаксисе десятков библиотек для состояния — второстепенны.

Функциональные требования простые:

  • хранить состояние в обычном ECMAScript — var, замыкание, хоть localStorage;

  • React-компоненты должны читать и записывать это состояние;

  • перерисовываться должны только компоненты с этим состоянием;

  • желательно использовать состояние через один хук — без глобальных <Provider> и мемоизации всего остального приложения.

Cостояние в JS?

Если я пишу код в React — он становится реактивным?

Почему-то нет. Такой код не заработает:

var глобальноеСостояние = { счётчик: 0 };

function Счётчик(params) {
  function увеличитьСчётчик() {
    глобальноеСостояние.счётчик += 1;
  }

  return (
    <dl>
      <dt>Счётчик: {глобальноеСостояние.счётчик}</dt>
      <dd>
        <button className="btn" onClick={увеличитьСчётчик}>
          Плюс один
        </button>
      </dd>
    </dl>
  );
}

Может, дело в хуках? Я же пишу на React!

function useGlobalState() {
  var [счётчик, установитьСчётчик] = React.useState(0);

  return [счётчик, установитьСчётчик];
}

function Счётчик(params) {
  var [счётчик, установитьСчётчик] = useGlobalState();

  function увеличитьСчётчик() {
    установитьСчётчик(function увеличить(предыдущийСчётчик) {
      return предыдущийСчётчик + 1;
    });
  }

  return (
    <dl>
      <dt>Счётчик: {счётчик}</dt>
      <dd>
        <button className="btn" onClick={увеличитьСчётчик}>
          Плюс один
        </button>
      </dd>
    </dl>
  );
}

Заработает. Но выяснится, что у каждого экземпляра <Счётчик /> — своё собственное состояние.

Тогда, может, дело в контексте, Redux, Jotai? В них же есть какая-то магия. Они же хранят состояние как-то по-особенному. Ведь правда?

На ютубе так говорят инфлюенсеры, ИИ им вторит: «Для больших проектов используйте Redux». А у меня как раз настоящий, взрослый проект. Наверное, Redux реализует шаблон проектирования «Состояние». А Jotai, может, — «Одиночка».

Да, я не знаю, как эти шаблоны вообще влияют на жизненный цикл React. Но звучит солидно!

ИИ не помогает

В 2026 году, с ИИ, я могу спросить любой вопрос и получить все различия в синтаксисе этих библиотек. А вот различия в подходах, объяснение проблем, которые они решают, объяснение этой магии «лучшего» хранения состояния — по-прежнему сложная задача для модели.

Скоро ИИ научится объяснять и это, и все поймут смыслы. Но пока можно быть быстрее и понять раньше, чем остальные.

Концепция состояния в React

Я люблю метод обучения, где есть текст, видео, и вместе с лектором идёшь от мотивации и боли к самостоятельному «изобретению» решения. И верю в мысль: хочешь убедиться, что что-то понял, — попробуй объяснить это другим. Поэтому описал всё в виде текста и видео на степике: лекция «Грокаем состояние» доступна всем бесплатно.

Путь начинается с useState для одного компонента. Но состояние получается локальным для каждого компонента — даже если завернуть его в свой глобальный хук useGlobalState.

Дальше — контекст, для нескольких компонентов сразу.

Работает. Но как быть с лишними перерисовками? Зачем провайдер на всё приложение, если состояние нужно всего двум компонентам?

Есть ли какой-то «глобальный» useState?

И так далее…

Код ничего не стоит

Сейчас написание кода стоит по цене подписки на ИИ. Что тогда продавать инженеру?

Я могу закинуть в ИИ что угодно, и он напишет что угодно:

— Сделай состояние на Redux. 
— Пять минут. Готово!

— Погоди, зачем так сложно? Может, достаточно просто useContext
— Ты абсолютно прав. Семь минут. Переписал на контекст.

— Так я вообще-то просто тему сайта меняю. Хватит и глобального useState
— Прошу прощения, ты абсолютно прав. Четыре минуты. Вот useState.

Так что нам выбирать?

Без понимания концепций тяжело разобраться в синтаксисе десятков библиотек по управлению состоянием. Да и синтаксис ИИ правда знает лучше меня. Так что, я теперь бесполезен? Что во мне остаётся после ИИ?

Учиться никогда не было так легко!

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

Я потратил около месяца, чтобы до конца разобраться, какая мотивация у этих библиотек по состоянию. Как именно React, Redux и Jotai хранят простые JavaScript-объекты. И записал это в виде курса на стёпике.

Есть люди, которые про любой паттерн говорят: «Так мы это на втором курсе универа проходили, это база». Вот я не такой.

Я всегда учился и жил на четвёрку. Мне нужно два-три раза прочитать книгу, чтобы понять её смысл. Даже после «книги с кабанчиком» у меня не складывается чёткая картина, как написать свой S3 на Next.js. Приходится читать заново, пробовать, ошибаться и пробовать ещё раз. Я не отличник — поэтому учусь лучше.

Попросите ИИ

Серьёзно, попросите любой ИИ-генератор кода добавить глобальное состояние на useState, Redux и Jotai вот для этого примера. Увидите, что ИИ справится со всем. Получите ровно три работающих проекта, покрытых тестами и документацией. Код стал практически бесплатным!

// глобальное состояние

function Счётчик(params) {
  return (
    <dl>
      <dt>Счётчик: </dt>
      <dd>
        <button className="btn">Плюс один</button>
      </dd>
    </dl>
  );
}

function App() {
  return (
    <ul>
      <li>
        <Счётчик />
      </li>
      <li>
        <Счётчик />
      </li>
    </ul>
  );
}

Что тогда остаётся делать инженеру?

Выбрать один из вариантов — как и раньше? На StackOverflow есть десяток способов отцентровать <div>. Но мне для задачи нужен один!

А как сделать правильный выбор? 

А что вообще правильно? 

Какая вообще разница в state managers?

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Что учить после ИИ?
33.33%ИИ1
33.33%Всё потеряно1
33.33%Базу1
Проголосовали 3 пользователя. Воздержались 3 пользователя.