Что это простыми словами

MobX — это умный склад данных, который сам следит, что и когда обновить.

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

Как и Redux, MobX хранит данные приложения в одном месте: сколько товаров в корзине, что ввёл пользователь, какая вкладка открыта. Но делает это по-другому — проще и с меньшим количеством кода.

Официальное определение

Теперь, когда суть понятна, вот как MobX описывают в вакансиях и документации. Эту формулировку вы встретите у заказчика и в резюме — и теперь будете понимать, что за ней стоит.

«MobX — библиотека для реактивного управления состоянием с автоматическим отслеживанием зависимостей через observable-объекты».

Разберём по словам. «Управление состоянием» — тот самый склад данных приложения. «Реактивное» значит, что изменения распространяются автоматически, как в Excel. «Автоматическое отслеживание зависимостей» — MobX сам понимает, какие части интерфейса зависят от каких данных, и обновляет только их. «Observable-объекты» — специальные контейнеры для данных, за которыми MobX умеет следить.

Какую задачу решает

Та же задача, что и у Redux: избавить от путаницы, когда разные части страницы показывают разные версии одних и тех же данных. MobX держит данные в едином месте и следит, чтобы всё обновлялось вовремя.

Преимущество MobX перед Redux: меньше кода и правил. В Redux нужно прописывать каждое изменение через строгие процедуры. В MobX достаточно просто поменять данные — остальное он сделает сам. Это быстрее и проще для разработчика, особенно в проектах, где не требуется жёсткий контроль за каждым изменением.

Обратная сторона: именно из-за этой «магии» сложнее отследить, что именно и почему поменялось. Поэтому выбор между MobX и Redux — вопрос предпочтений команды.

К какой экосистеме относится

  • Язык — JavaScript (часто вместе с TypeScript).

  • Фреймворк — чаще всего React. Формально MobX можно использовать и без фреймворков или с другими, но на практике вы почти всегда встретите его именно рядом с React.

  • Специальность — frontend-разработчик.

Чем заменяется

MobX — один из нескольких «складов данных» для React. Ту же задачу решают Redux (с Redux Toolkit), Zustand, Effector и Jotai. В одном проекте обычно используют что-то одно.

Главное: переход между ними дешёвый. Разработчик, который работал с MobX, освоит Redux или Zustand за считаные дни — задача та же, меняется только подход. Это не разные профессии, а разные инструменты для одной работы.

Отдельно: Recoil считается устаревшим, в новых проектах его почти не берут.

Что не путать

  • MobX ≠ React. React — это фреймворк для интерфейса, MobX — лишь одна из библиотек рядом с ним. Приложение на React может работать и без MobX.

  • MobX ≠ RxJS. Оба используют реактивный подход, но RxJS — библиотека для работы с потоками событий и данных, а MobX — именно для состояния интерфейса.

  • MobX ≠ база данных. База данных хранит информацию на сервере надолго, MobX держит данные только внутри открытой страницы и исчезает при перезагрузке.

  • MobX ≠ Pinia или Vuex. Это менеджеры состояния из мира Vue, а не React.

Насколько это важно при отборе

Короткий ответ: обычно это НЕ повод отбраковывать кандидата.

Самая частая ошибка новичка-рекрутера — искать строго «React + MobX» и отсеивать сильного разработчика, у которого в резюме указан Redux или Zustand. Он освоит MobX за несколько дней, потому что задача та же. Отсеивая по конкретной библиотеке, вы теряете хороших людей и затягиваете поиск.

Правильный подход: смотрите, есть ли у кандидата опыт с любым менеджером состояния. Если есть — этого достаточно. Если в вакансии жёстко написано «только MobX», уточните у нанимающего менеджера, действительно ли это принципиально: часто оказывается, что нет.

Когда всё же стоит обратить внимание: если у кандидата вообще нигде не упомянут ни один менеджер состояния, а вакансия предполагает большое сложное приложение — это повод спросить, как он управлял данными в проектах.

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