Я работаю с React уже почти 3 года, использовал и Redux, и MobX, и на данный момент у меня есть вопрос.
Почему подавляющее большинство фронтенд-разработчиков продолжают твердо верить, что Redux + Redux Saga + Reselect + 100 500 других библиотек, «облегчающих жизнь», — лучшее решение на данный момент? Я приведу 4 причины, почему вам следует использовать MobX вместо Redux в вашем следующем проекте.
MobX позволяет писать более чистый и понятный код.
Давайте сравним 2 фрагмента кода, которые делают одно и то же.
Вот как выглядит редюсер в Redux: 
Чтобы изменить состояние, вам нужно вызвать функцию, называемую действием в терминологии Redux: 
И в большинстве случаев (не всегда, но это «лучшие практики», которые используются во многих проектах) вам понадобится написать такой шаблон: 
Затем вам нужно будет инициализировать хранилище (это нужно будет сделать один раз, но все же): 
И пробрасываем наше инициализированное хранилище дальше в приложение через провайдера (тоже разовая операция): 
Теперь вы можете выполнять некоторые операции с данными в ваших компонентах: 
Получается, что в случае с Redux, чтобы изменить данные в вашем хранилище, вы должны вызвать некоторые функции, которые создадут новый объект состояния.
Лично для меня это звучит полной ерундой.
Давайте посмотрим на ту же функциональность, которую выполняет MobX. Наш магазин: 
И затем вы можете использовать его в компоненте: 
Да, именно так, вместо каких-то функций, изменяющих объекты, можно использовать классический ООП-подход, с классами, их свойствами и методами.
Не пугайтесь внутренних декораторов(@), они просто добавляют функциональность, необходимую для отслеживания изменений данных.
Кстати, аналогичный подход, с классами, для хранения данных используется в Angularjs (Скрин взят отсюда angular.io/start/data ): 
MobX позволяет писать меньше кода
Чтобы убедиться в этом, просто посмотрите на примеры выше.И теперь вместо того, чтобы писать бесконечный шаблон, вы наконец можете сосредоточиться на написании бизнес-логики приложения, что не может не радовать.
Третье — оптимизация производительности
Если посмотреть примеры выше, то можно увидеть, что в случае с MobX я не использовал чистые компоненты и это не ошибка.В этом случае вам просто не нужно использовать какую-либо оптимизацию, потому что ваш компонент будет перерисовываться только тогда, когда данные, которые вы в нем используете, изменятся.
И да, вы можете забыть о Pure Components, mustComponentUpdate и обо всем, что вы используете в этих случаях.
В идеале каждый ваш компонент, который не является HOC и использует какие-то данные из хранилища, должен быть наблюдаемым и тогда вы навсегда забудете о проблемах оптимизации.
Четвертое — меньше зависимостей
Любой, кто использует Redux, должен не понаслышке знать, что в его состав входит множество «замечательных» библиотек.И хорошо, если это всего лишь мысль, а может и так, разработчики пойдут по пути света из тьмы и захотят использовать Redux Saga, Reslect и кучу других малоизвестных библиотек, которые делают ваш код не только медленнее, но и сложнее в исполнении.
понимать.
А доделать какой-то мелкий функционал или найти ошибку в этом продукте будет невероятно сложно и отнимает много времени.
MobX — ультимативное решение == не требует дополнительных библиотек, лишит вас всех этих прелестей, поэтому с ним бизнес-логика вашего приложения будет чиста, как слеза ребенка.
УПД.
Спасибо МаЗаАа
Пятая причина — возможность отказаться от setState
setState имеет ряд недостатков (краткий перевод статьи который вы можете прочитать в оригинале здесь ):1. Это асинхронно.
Это может привести к неожиданному поведению: 
На скриншоте выше в оповещении должно было быть 2, но поскольку setState асинхронный, он приходит позже.
2. setState приводит к ненужным перерисовкам компонента:
A. Он выполняет повторную визуализацию, даже если новое значение == старое значение.б.
Бывают ситуации, когда изменение состояния не приведет ни к какому изменению, например, когда у нас есть условия для отображения, в которых состояние присутствует. На скриншоте ниже при нажатии произошел повторный рендеринг, хотя данные не должны рендериться из-за состояния fasle: 
V. Иногда данные, которые обновляет setState, вообще не играют роли в рендеринге DOM (например, таймеры).
И все же компонент перерисовывается.
3. setState подходит не для всех случаев.
Существуют компоненты, которые используют перехваты/методы жизненного цикла компонентов, и в этом случае не только будет ненужная повторная отрисовка, но и эти события (перехваты) будут вызываться каждый раз, когда это делается, что может привести к странному поведению.
Использование MobX защитит вас от этих недостатков, ведь вы можете полностью отказаться от setState: 
Если вы с чем-то не согласны или я чего-то не понимаю, приведите контраргументы в комментариях.
Ссылка на песочницу, из которой были сделаны скриншоты из MobX: codeandbox.io/s/mobxreact-s7db5 , с Redux: codeandbox.io/s/oj7px08qy9 Теги: #Разработка веб-сайтов #JavaScript #фронтенд-разработка #react.js #redux #mobx ##state-management #State Management
-
Умная Публикация
19 Oct, 24 -
Яндекс.деньги Из Европы С Низкой Комиссией
19 Oct, 24 -
Пустыни
19 Oct, 24 -
Яндекс Посвятил Страницу Плееру Winamp
19 Oct, 24 -
7 Фундаментальных Принципов Itil
19 Oct, 24 -
Станьте Росомахой Дома
19 Oct, 24 -
«Только Избранные Продолжат Расти».
19 Oct, 24
