TL; DR; MobX для 1–3 человек или небольших приложений, Redux для всего остального.

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

MobX - Простое масштабируемое управление состоянием для React
https://news.ycombinator.com/item?id=12371248

Что такое MobX и когда его использовать. №199
https://github.com/mobxjs/mobx/issues/199#issuecomment-221000954

Понимание MobX и Redux
https://www.youtube.com/watch?v=83v8cdvGfeA

Найдите минутку, чтобы прочитать эти темы. Эти аргументы во многом напоминают мне старые времена, когда люди пытались выбрать между Backbone и Angular и Angular против Knockout.

Что я выучил

Redux

Плюсы

  • Легче тестировать, легко достичь 100% тестового покрытия.
  • Предсказуемое детерминированное состояние упрощает отладку.
  • Хорошо масштабируется для больших команд из коробки.
  • Мнение. Есть только один способ передачи данных.

Минусы

  • Мнение. Вы работаете медленнее, потому что вам нужно следовать шаблону даже в тривиальных вещах.
  • Более крутая кривая обучения. Для эффективного использования требовалось более четкое понимание концепций ES6 и ES7, а также Flux.
  • Больше кода плиты котла.

MobX

Плюсы

  • Быстрее кодировать, поскольку есть больше автоматических магий, подобных двусторонней привязке данных, и, следовательно, меньше кода.
  • Нет необходимости изучать или понимать концепцию Flux.
  • Более гибкий. Вы сами решаете, как поддерживать состояние.
  • Свобода. Вы можете заставить государство работать с вами.

Минусы

  • Хорошо масштабируется только для больших команд, если они поддерживаются и правильно организованы с самого начала (вы находитесь во власти гения с первых нескольких человек, начавших проект).
  • Слишком много свободы. Легко построить что-то плохим способом. Вы можете использовать MobX для создания чего-то похожего на Flux, но от этого также легко отказаться.

Этот комментарий от rwieruch на Hacker News резюмировал это лучше всего для меня:

Я согласен с тем, что для большинства пользователей Redux кажется шаблоном. В то же время я думаю, что большинство людей недооценивают то, откуда мы пришли. Лично я написал огромное количество кода Angular раньше и в определенный момент почувствовал себя очень недовольным двусторонней привязкой данных и обработкой состояния в Angular. В какой-то момент это было непредсказуемо в огромной кодовой базе. Тогда пришло время Flux, и в нашей компании мы представили собственную реализацию хранения и однонаправленного потока данных. После этого был анонсирован Redux, и нам с самого начала понравились четкие ограничения и легкий API. Используем сейчас.

В команде разработчиков каждый может четко следить за изменениями состояния, за самим состоянием и за местами, откуда эти изменения состояния были инициированы. Redux является масштабируемым, и его не следует использовать для каждого небольшого проекта, который может существовать без библиотеки управления состоянием, и вместо этого следует использовать setState. Redux просто работает, даже если у вас уже есть большое количество действий в продакшене.

Я думаю, что MobX находится на правильном пути, предлагая альтернативный способ управления государством. На данный момент я вижу явную выгоду в том, чтобы начинать небольшие проекты в небольших командах, которые не полагаются на ограничения и масштабируемость Redux. Небольшие функциональные возможности, такие как useStrict, помогут MobX получить более масштабируемую систему управления состоянием. В противном случае в растущей базе кода это будет похоже на старые времена Angular с двусторонней привязкой данных. В конце концов, в этом сила MobX, потому что он непредубежден: вы можете либо изменить свое состояние непосредственно в компоненте, либо построить вокруг него надлежащую инфраструктуру, чтобы сделать его масштабируемым.

Источник: https://news.ycombinator.com/item?id=12377214

Заключение

Я всегда буду настаивать на Redux в группах больше 3+ из-за его исключительной предсказуемости, что я считаю бесценным по мере роста чего-либо. Для меня мы должны помнить, откуда мы пришли. DHTML - ›jQuery -› Backbone против Knockout против Ember - ›Meteor -› Angular против React. Во многих случаях управление состоянием становилось самым большим источником ошибок и проблем, поэтому был представлен Flux и, в конечном итоге, Redux. MobX - отличный инструмент, который рекомендует использовать его в духе Flux, но он напоминает Knockout JS и другие библиотеки MVVM того времени, когда сначала волшебство сработало, но через 6–12 месяцев волшебство и свобода была плохой новостью, поскольку разработчики реализовывали различные решения таким образом, чтобы они работали на них, оставляя ошибки, которые трудно отследить.

Ранее я контролировал рост приложения с нуля до размера сложной JIRA, и по мере роста команды и проекта я обнаружил, что две ключевые вещи, которые замедляли нас, - это отсутствие предсказуемости, отсутствие тестируемости и вариативность кода. Можно было бы возразить, что эти вещи должны были быть обнаружены при проверке кода, или эти передовые методы должны были быть более строгими во время проверки, но любой, кто работал в быстрорастущей компании, знает, что все вышеперечисленное - роскошь. По крайней мере, с Redux меньше шансов, что что-то тоже выйдет из-под контроля. Эта неявная предсказуемость в вашей кодовой базе бесценна для растущей компании, поскольку вы никогда не знаете, какие инженеры присоединятся к вашей команде или какой у них настоящий уровень квалификации.

Хотя Redux не такой гибкий, у него есть четкие ограничения, а состояние очень детерминировано, что упрощает отладку проблем. Хотя вы можете спроектировать состояние MobX так, чтобы оно было более предсказуемым за счет использования его useStrict функции и хорошего дизайна, его свобода также является слабым местом, поскольку не применяется явным образом, что оставляет возможность одному разработчику испортить код, если он прошел проверку кода.

Для личного использования в небольшом приложении или с другом, с которым я могу легко общаться и думающим, как я, я бы использовал MobX, потому что мне действительно не нужно делиться кодом с кем-либо, а MobX дает мне гибкость в разработке того, как мой ум чувствует в этот момент. Однако, если я знаю, что люди, с которыми я не знаком, могут присоединиться ко мне на предприятии (что является почти любым сценарием рабочей среды), или я создаю что-то, что, я надеюсь, однажды будет огромным, я буду использовать Redux, потому что он встроен. стандартизация.