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

Redux, Zustand, MobX, Valtio, Jotai, XState, плюс сигналы в Angular и Solid - список инструментов кажется хаосом из несовместимых имён. Но за ними всего несколько базовых парадигм реактивности: способ ответить на вопрос как изменение данных доходит до интерфейса. Стоит увидеть эти парадигмы, и зоопарк библиотек складывается в карту: flux/reducer, observable/proxy, атомы, сигналы, конечные автоматы. Каждая библиотека это реализация одной из них, и выбор инструмента сводится к выбору подходящей парадигмы под задачу.

• Redux и Redux Toolkit как воплощение flux/reducer-парадигмы
• MobX, Vue reactivity и Valtio как observable/proxy-подход
• Jotai как атомарная модель снизу вверх
• Сигналы в Angular, Solid и Preact как точечная реактивность на уровне фреймворка
• XState как конечные автоматы для сложных переходов между состояниями

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

• Категории состояния из урока про таксономию
• Идея обнаружения изменений и почему ре-рендеры важны для производительности
• Базовое представление о том, что компонент подписывается на данные и обновляется при их изменении

• Таксономия состояния

Что такое парадигма реактивности

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

Различия между парадигмами сводятся к двум вопросам. Первый: как описывается изменение - явным действием через единую точку или прямой мутацией данных. Второй: как система узнаёт, что и кого обновить - через явные подписки, через автоматическое отслеживание зависимостей или через граф мелких единиц состояния. Ответы на эти два вопроса и задают характер парадигмы.

Парадигма и библиотека это разные уровни. Redux и Zustand обе ближе к flux/reducer-семейству, но это разные библиотеки. MobX и Vue reactivity обе observable/proxy, но реализации разные. Сначала выбирают парадигму под задачу, потом конкретную библиотеку внутри неё.

Пять парадигм на карте

Карту территории удобно держать из пяти парадигм. Они не взаимоисключающие: в одном приложении может сосуществовать несколько, под разные задачи. Важно узнавать каждую по сути, а не по конкретной библиотеке.

Отдельно про сигналы: реактивные сигналы в Angular, Solid и Preact - это реальные возможности этих фреймворков. А вот Signals на уровне самого языка JavaScript - это предложение TC39, которое по состоянию на 2026 год всё ещё в комитете и стандартом не является. Эти две вещи легко спутать.

Как выбирать парадигму под задачу

Парадигмы не ранжируются по принципу лучше-хуже, они отвечают на разные запросы. Где ценится предсказуемость и прослеживаемая история изменений, выигрывает flux/reducer. Где важна минимальная писанина и привычная мутация, удобнее observable/proxy. Где состояние естественно распадается на независимые куски, подходят атомы. Где логика это набор строго определённых состояний и переходов, нужен конечный автомат.

На практике парадигмы сочетаются. Канонический стек 2026 года - Zustand плюс TanStack Query плюс nuqs - сам по себе смешивает подходы: стор для клиентского состояния, кэш для серверного, URL для навигационного. Выбор парадигмы делается под конкретный кусок состояния, а не раз и навсегда на всё приложение.

Полезный порядок мышления: сначала категория состояния (из урока про таксономию), затем парадигма под эту категорию, и только потом конкретная библиотека. Так выбор инструмента следует из задачи, а не из моды на имя.

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

Этот урок - карта, по которой устроены следующие три урока модуля:

• Flux и reducer-модель — Подробный разбор первой парадигмы: однонаправленный поток и чистые редьюсеры
• Observable и proxy-реактивность — Подробный разбор второй парадигмы: автоматическое отслеживание зависимостей
• Атомарная модель — Подробный разбор третьей парадигмы: атомы и точечные подписки

Итог

• За множеством библиотек стоит несколько базовых парадигм реактивности: способ доставки изменений данных в UI
• Flux/reducer: явные действия, чистые редьюсеры, однонаправленный поток, предсказуемость ценой обвязки
• Observable/proxy: мутируем как обычно, система сама отслеживает зависимости и обновляет зависимый UI
• Атомы: состояние собирается снизу вверх из мелких единиц, подписка идёт на отдельный атом
• Сигналы: точечная реактивность на уровне фреймворка; языковой Signals из TC39 пока только предложение, не стандарт
• Конечные автоматы: явные состояния и разрешённые переходы, когда важна строгость сложной логики

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

• sm-02-state-taxonomy — Категории состояния задают вопросы, на которые парадигмы реактивности дают разные ответы
• sm-07-flux-reducer — Flux/reducer это первая парадигма из карты, разобранная подробно в следующем уроке
• sm-08-observable-proxy — Observable/proxy это вторая парадигма из обзора
• sm-09-atoms — Атомарная модель это третья парадигма, раскрытая отдельным уроком