Атомарная модель

Один большой стор на всё приложение хранит и тему, и фильтры, и черновик формы, и выбранный инструмент. Компоненту нужен только инструмент, но он подписан на стор и рискует ре-рендериться при изменении темы, если селектор написан неаккуратно. Атомарная модель переворачивает подход: вместо одного большого хранилища - множество крошечных независимых единиц состояния, атомов. Компонент подписывается ровно на нужный атом и обновляется только при его изменении. Состояние собирается снизу вверх из мелких кусочков, а не делится сверху вниз из единого стора.

• Независимые кусочки UI-состояния: тема, выбранный инструмент, открытая панель - каждый свой атом
• Формы, где каждое поле это отдельный атом, и ввод в одно поле не трогает остальные
• Производные значения как атомы, вычисляемые из других атомов
• Постепенный рост состояния: новые атомы добавляются по месту, без правки общего стора
• Jotai как преемник архивированного Recoil для атомарной модели в React

Предварительные знания

• Обзор парадигм реактивности и место атомов на карте
• Идея производного состояния: значение, вычисляемое из другого состояния
• Понимание, что узкая подписка снижает лишние ре-рендеры

• Парадигмы: обзор

От Recoil к Jotai

Атомарную модель в React популяризировал Recoil, экспериментальная библиотека из Facebook, представленная в 2020 году. Идея была в том, чтобы строить состояние из мелких единиц-атомов, на каждую из которых компонент подписывается отдельно, вместо одного большого дерева состояния. Recoil показал силу подхода, но остался экспериментальным и в итоге был архивирован: активная разработка прекращена. Эстафету подхватил Jotai из коллектива Poimandres, тех же, кто сделал Zustand. Jotai взял ту же атомарную идею, сделал API минималистичным и стал основным выбором для атомарной модели. По состоянию на 2026 год Recoil не используют для нового кода, а атомы это Jotai.

Атомы снизу вверх

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

Любопытная деталь: одна и та же команда Poimandres сделала и Zustand (единый стор), и Jotai (атомы). Это два сознательно разных ответа на клиентское состояние, а не один правильнее другого: сверху вниз через один стор или снизу вверх через атомы.

Точечные подписки

Главное практическое следствие атомов это точечность подписок без ручных селекторов. Когда компонент использует атом, он подписывается ровно на него. Изменение любого другого атома его не касается. В модели единого стора, чтобы добиться того же, разработчик пишет узкие селекторы; в атомарной модели узость подписки заложена в саму единицу состояния.

Поскольку каждое поле это свой атом, ввод в имя обновляет только компонент имени. Компонент почты не ре-рендерится, потому что не подписан на nameAtom. Чем мельче дробление на атомы, тем точечнее реактивность, и тем меньше лишних перерисовок без какой-либо дополнительной оптимизации со стороны разработчика.

Атомы удобно дробить по смыслу независимости: то, что меняется и читается отдельно, стоит и держать отдельным атомом. Слишком крупный атом начинает вести себя как мини-стор и теряет преимущество точечной подписки.

Производные атомы

Атомы не только хранят, но и выводят значения. Производный атом это атом, значение которого вычисляется из других атомов. Он читает нужные атомы в своей функции, и Jotai сам строит граф зависимостей: производный атом пересчитывается только тогда, когда меняется хоть один из атомов, от которых он зависит. Это та же идея производного состояния, но выраженная через атомы и их граф.

totalAtom не хранит сумму как отдельное значение, а вычисляет её из priceAtom и qtyAtom. Если меняется цена или количество, totalAtom пересчитывается и подписанный компонент обновляется. Если меняется не связанный с ним атом, totalAtom не трогается. Граф зависимостей строится автоматически из того, какие атомы прочитала функция через get.

Важно различать преемственность библиотек: Recoil это первая популярная библиотека атомов, и она архивирована - активная разработка прекращена, для нового кода её не берут. Текущий выбор для атомарной модели в React это Jotai, который продолжает ту же идею с более компактным API.

Связь с другими темами

Атомарная модель связана с производным состоянием и противопоставлена единому стору:

• Производное состояние — Производный атом вычисляется из других атомов - та же идея вывода значения из состояния
• Zustand — Один общий стор с селекторами против множества независимых атомов: два разных подхода к клиентскому состоянию

Итог

• Атом это крошечная независимая единица состояния, на которую подписываются по отдельности
• Состояние собирается снизу вверх из атомов, а не делится сверху вниз из одного большого стора
• Подписка точечная: компонент использует нужный атом и ре-рендерится только при его изменении
• Производный атом вычисляется из других атомов и пересчитывается только при изменении своих зависимостей
• Атомы можно добавлять по месту, наращивая состояние без правки общего хранилища
• Recoil (первая библиотека атомов) архивирован; преемник и текущий выбор для атомарной модели - Jotai

Связанные уроки

• sm-06-paradigms-overview — Атомарная модель это третья парадигма из общей карты, теперь подробно
• sm-04-derived-state — Производный атом это та же идея производного состояния, выраженная атомами
• rc-38-zustand-state — Другой подход к клиентскому состоянию: один общий стор против россыпи независимых атомов