Redux — библиотека управления состоянием с единым store и явными событиями. Новое состояние вычисляется reducers из предыдущего состояния и action. Обычно используют Redux Toolkit, который уменьшает boilerplate и безопасно применяет immutable updates.

State хранится централизованно, изменения описываются actions, а reducers вычисляют следующий state предсказуемо. Однонаправленный поток облегчает tracing и replay. Side effects выносят за пределы reducers.

Store хранит текущее state tree, принимает actions через dispatch и уведомляет subscribers. Он также объединяет reducers и middleware. Store не обязан содержать все локальное UI-состояние приложения.

Action — обычный объект, описывающий произошедшее событие, обычно с полем type и payload. Хорошее имя отражает domain event, а не инструкцию изменения каждого поля. Actions должны быть сериализуемыми, если важны DevTools и persistence.

Reducer — функция (state, action) => nextState. Она обрабатывает известные actions и возвращает прежний state для остальных. Reducer не выполняет HTTP, timers и случайные вычисления.

function counterReducer(state = {count: 0}, action) {
  switch (action.type) {
    case 'increment':
      return {...state, count: state.count + 1};

    default:
      return state;
  }
}

Одинаковые входы должны давать одинаковый результат без внешних side effects. Это делает обновления тестируемыми, поддерживает replay и time-travel debugging. I/O выполняет middleware или отдельный orchestration layer.

Это создание нового объекта для изменившейся ветки вместо мутации существующего state. Ссылочное сравнение позволяет быстро определить изменения. Redux Toolkit использует Immer, поэтому внутри reducer можно писать mutation-like syntax с immutable результатом.

Selector читает или вычисляет данные из store. Memoized selector не пересчитывает результат, пока его входные ссылки не изменились. Сложную derivation logic лучше держать в selectors, а не компонентах.

Middleware перехватывает dispatch между caller и reducer. Оно используется для async flows, logging, analytics и обработки ошибок. Middleware не должно скрывать критичную бизнес-логику без наблюдаемых actions.

Это HTTP, storage, timers, navigation, случайность и любое взаимодействие вне чистого reducer. Их реализуют thunk, saga, observable middleware или listener middleware. Результат обычно возвращается в store новым action.

Явный поток данных, хорошие DevTools, предсказуемые updates, testability и удобная диагностика сложных сценариев. Центральный event log полезен большим командам. Экосистема предлагает устойчивые patterns для normalized data.

Дополнительные actions, reducers, selectors и async conventions увеличивают объем кода и порог входа. Глобальный store легко перегрузить локальным state. Плохая granularity вызывает лишние updates и связанность features.

Когда много удаленных компонентов используют общее сложное состояние, важны audit/debugging и несколько команд меняют одни domain entities. Он полезен для долгоживущих async workflows и normalized caches. Решение должно окупать инфраструктуру.

Для формы, раскрытия панели или данных одного feature часто достаточно component state или query cache. Если actions лишь дублируют простые setters, архитектура не дает пользы. Начинать лучше с colocated state.

MobX — реактивная библиотека, которая отслеживает чтения observable state и автоматически обновляет зависящие computations и views. Код часто выглядит как обычные объекты и методы. Связи формируются динамически во время выполнения.

Это состояние, чтения и изменения которого отслеживает MobX. Когда observable меняется, зависимые computed values и reactions инвалидируются. Изменения обычно группируют в actions.

Computed — производное значение из observables. MobX кеширует его и пересчитывает при изменении реально прочитанных dependencies. Computed должен быть чистым и не выполнять I/O.

Reaction запускает side effect при изменении наблюдаемого выражения. Его используют для persistence, analytics или интеграции с внешним API. Reaction нужно уничтожать, когда заканчивается lifetime владельца.

Меньше boilerplate, естественная объектная модель и точные updates по фактически прочитанным dependencies. Удобен для богатых domain models и сложных производных значений. Быстро внедряется в локальные features.

Динамический dependency graph и скрытая реактивность могут усложнить tracing. Легко создать side effects с неочевидным lifecycle или чрезмерно mutable shared model. Нужны соглашения о actions, ownership и disposal.

Redux делает события и переходы состояния явными через actions/reducers. MobX больше опирается на observable graph и автоматические reactions, поэтому бывает лаконичнее. При неаккуратном дизайне поток изменений сложнее проследить.

Когда важна лаконичная модель объектов, много computed dependencies и команда принимает runtime-реактивность. Redux удобнее, если нужен строгий event log и максимально явный flow. Выбор зависит от требований к debugging и культуре команды.