Почему не хочешь использовать MobX при создании приложения для доставки пиццы?

Почему я бы не рекомендовал MobX для приложения доставки пиццы

При разработке приложения для доставки пиццы с его сложным состоянием (заказы, корзина, геолокация, статусы доставки, меню), я бы сознательно избегал MobX в пользу более предсказуемых решений, таких как Redux Toolkit (RTK) или Zustand. Вот развернутое обоснование.

1. Проблемы с масштабированием и архитектурой

В MobX используется инкрементальное, реактивное обновление состояния, где изменения автоматически отслеживаются и распространяются. Это создает риски:

• Неявные зависимости и "магия": MobX полагается на декораторы @observable, @computed, @action, которые могут скрывать логику потока данных. В команде, особенно с разноуровневым опытом, это приводит к ошибкам, когда разработчики не до конца понимают, почему компонент перерендерился.

  // Проблемный пример с MobX: неочевидная реактивность
  class CartStore {
    @observable items = [];
    @observable selectedToppings = {};
  
    // Автоматически отслеживается использование `items` внутри.
    // При изменении ЛЮБОГО свойства `items` вычисление перезапускается.
    @computed get totalPrice() {
      return this.items.reduce((sum, item) => sum + item.price, 0);
    }
  }
  // Где именно произошло изменение? Трудно дебажить в большом приложении.
  

• Сложность контроля перерендеров: В приложении доставки обновления состояния частые (добавление в корзину, изменение количества, обновление статуса заказа). MobX-оптимизации (observer, useObserver) могут быть недостаточными, приводя к лишним перерендерам сложных компонентов (например, списка пицц с модификаторами).

2. Сложности с отладкой и отслеживаемостью состояния

Для доставки пиццы логи и история изменений состояния критически важны (для отладки, поддержки, анализа инцидентов).

• Отсутствие иммутабельных обновлений: MobX мутирует состояние напрямую. Это усложняет:

    *   **Отладку в Redux DevTools**: Хотя есть `mobx-logger`, интеграция не столь глубокая, как у Redux. Невозможно "путешествовать во времени" (time-travel debugging) с той же точностью.
    *   **Отслеживание происхождения изменений**: В сложном потоке (обновление статуса от курьера → уведомление клиента) трудно найти, какое действие вызвало изменение.

• Проблемы с SSR (Next.js/Nuxt): Если приложение использует серверный рендеринг для SEO (меню, страницы ресторанов), MobX требует дополнительной настройки гидратации состояний, что сложнее и менее стандартизировано, чем решения с явными сериализуемыми сторами (Redux, Zustand).

3. Неидеальное соответствие требованиям домена

Состояние приложения доставки пиццы имеет четкие доменно-ориентированные структуры и асинхронные операции (работа с API меню, отправка заказа, отслеживание геопозиции).

• Стандартизация асинхронности: В MobX нет встроенного подхода к обработке async-запросов (в отличие от createAsyncThunk или Query в RTK). Приходится вручную создавать actions с runInAction, что ведет к шаблонному коду.

  // MobX: асинхронный action требует ручного управления
  class OrderStore {
    @observable loading = false;
    @observable error = null;
  
    @action
    async submitOrder(orderData) {
      this.loading = true;
      try {
        const response = await api.postOrder(orderData);
        runInAction(() => {
          this.orders.push(response);
          this.loading = false;
        });
      } catch (err) {
        runInAction(() => {
          this.error = err.message;
          this.loading = false;
        });
      }
    }
  }
  

    В **Redux Toolkit** это решается элегантнее с `createAsyncThunk` и `createSlice`.

• Структурирование сложного состояния: Состояние включает:

    *   **Корзина** (позиции, модификаторы, промокоды).
    *   **Меню** (категории, доступность, цены).
    *   **Заказы** (история, текущий статус, геоданные).
    В MobX это часто несколько разрозненных store-классов. В **RTK** можно использовать `combineReducers` и **RTK Query** для единой структуры с встроенным кэшированием API-запросов (актуально для меню, которое редко меняется).

4. Альтернативы, лучше подходящие для задачи

1. Redux Toolkit (RTK):

    *   **Явность и предсказуемость**: Изменения через reducers, иммутабельные обновления.
    *   **RTK Query**: Встроенное решение для кэширования запросов к API меню и заказов.
    *   **Мощные DevTools**: Полная трассировка действий и time-travel.
    *   **Легкая типизация с TypeScript**.

1. Zustand:

    *   **Минимальный бойлерплейт**, простота.
    *   **Гибкость** как у MobX, но с более явным контролем обновлений.
    *   **Встроенная поддержка middleware** (логирование, персистентность для корзины).

1. React Context + useReducer:

    *   Для небольших или средних приложений может быть достаточно.
    *   Полная интеграция с экосистемой React.

Заключение

Хотя MobX — мощная библиотека с отличной производительностью для определенных сценариев, для production-приложения доставки пиццы его недостатки перевешивают преимущества. Ключевые риски — сложность отладки в растущей кодовой базе, неявные обновления состояния, которые трудно поддерживать, и отсутствие стандартизированных практик для асинхронных операций и структурирования store.

Выбор Redux Toolkit или Zustand даст команде более надежную, предсказуемую и поддерживаемую архитектуру, что критически важно для бизнес-приложения с частыми изменениями состояния и высокими требованиями к отказоустойчивости.