Комментарии 14
И тогда после неправильно спроектированной архитектуры нормальная работа может стать невозможной. У меня есть проект, так же на Flutter, который я ради интереса попробовал написать через архитектуру MobX. Проект разросся. Работать стало, мягко говоря, некомфортно, пришлось все переписывать на Redux.
Через архитектуру MobX? Нет такого понятия.
MobX лишь дает настоящую реактивность, а как именно организовывать архитектуру, это уже сугубо личное дело каждого разработчика.
Так вот, вы просто сделали плохую архитектуру. Причем тут MobX???
Плюсы:
1. иммутабельность, сериализация, дефолтные значения с built_value “из коробки”
2. быстрое обучение новичков из мира фронтенда знающих Redux
3. почти безболезненное включение/выключение фич
4. независимая работа членов команды над задачами. Например, на моей текущей работе в команде 13 Flutter разработчиков, абсолютно не мешающих друг другу благодаря вышеописанной структуре приложения
5. доменная часть, независимая от UI — как пример чистой архитектуры, что дает возможность поместить ее (целиком Redux состояние со всеми миддлварами и эпиками, выполняющими много работы в бекграунде) в свой отдельный изолят
1. иммутабельность
Cомнительный плюс.
2. быстрое обучение новичков из мира фронтенда знающих Redux
Ну как бы какая разница, если быстрое обучение новичков из мира фронтенда знающих любой стейт менеджер который есть во Flutter, в том числе MobX.
3. почти безболезненное включение/выключение фич
Относится к любому стороннему стейт менеджменту, к MobX в том числе.
4. независимая работа членов команды над задачами. Например, на моей текущей работе в команде 13 Flutter разработчиков, абсолютно не мешающих друг другу благодаря вышеописанной структуре приложения
Относится к любому стороннему стейт менеджменту, к MobX в том числе.
5. доменная часть, независимая от UI — как пример чистой архитектуры, что дает возможность поместить ее (целиком Redux состояние со всеми миддлварами и эпиками, выполняющими много работы в бекграунде) в свой отдельный изолят
Относится к любому стороннему стейт менеджменту, к MobX в том числе.
И вместо built value рекомендую использовать freezed
У меня есть проект, так же на Flutter, который я ради интереса попробовал написать через архитектуру MobX. Проект разросся. Работать стало, мягко говоря, некомфортно, пришлось все переписывать на Redux.Вы не пробовали проконсультироваться с другими разработчиками, у которых большой опыт работы с Mobx? Уверен, что тогда бы не пришлось все переписывать.
Не хотите вкратце здесь поделиться тем, как вы организовали архитектуру в вашем Mobx проекте? Может я или кто-нибудь другой порекомендует, как улучшить.
MaZaAa верно написал, что для Mobx нет стандартной архитектуры, как в случае с Redux. Поэтому в случае использования Mobx для больших проектов нужно уметь разделять код на слои, более менее понимать Single Responsibility Principle. C Mobx (и не только) может получится гораздо лучше, чем с Redux, но это зависит от навыков проектирования. В случае redux надо следовать уже придуманной за вас архитектуре. Довольно паршивой, но работающей, т.к. код, как-никак, разделен на слои.
Насчет структуры папок в статье, рекомендую почитать: softwareengineering.stackexchange.com/questions/338597/folder-by-type-or-folder-by-feature/338610
redux.js.org/style-guide/style-guide#structure-files-as-feature-folders-or-ducks
Кстати, насколько пет-проект раздулся-то?
Скорее всего, проблема в разработчиках, а не в MobX. Лучше расскажите, в чём именно заключается проблема и покажите на примере. У вас есть View (JSX) и ViewModel. Также, могут быть какие-то модели и сервисы на MobX (если нужна реактивность).
Если под "связями между моделями" подразумевается, что используется классовый DI и в один класс хранилища прокидываются еще несколько, а в те, в свою очередь, еще несколько — это действительно предвестник полной запутанности и неподдерживаемости. Такая архитектура крайне специфична и подойдет возможно только определенным браузерным играм, но видел ее применение и в обычных SPA, что действительно расстраивает. Только не из-за mobx, а из-за классового DI и полного размазывания ответственности хранилищ под соусом "изолирования и явного указания зависимостей", что прямо противоположно результату.
Для выведения значений сразу из нескольких семантических сторов нужен слой getters/selectors с реактивными computed-значениями, для изменения данных сразу в нескольких сторах — слой глобальных action-модификаторов состояния. Только времени разработчикам на то, чтобы продумать это все, как правило, не дают — от фронтендеров бизнес ждет быстрый видимый результат, а не продуманную архитектуру, удобную для разработки и минимизирующую количество ошибок. Вообще часто видел очень запущенный код с громадным количеством функционала, добрая половина из которого не работала и про которую бизнес даже забыл, не удосужившись вести полноценную базу знаний по продукту. И в таком виде приложение существовало долго и приносило доход, что и было целью для руководителей компании, в то время как разработчики удерживались методами, не связанными со "стремлением к саморазвитию, внедрением новых технологий, созданием стабильных архитектур". К чему я это все — к тому, что проект проекту рознь, и там, где достаточно времени уделяется качеству, можно практически на любом инструменте создать грамотную схему работы. Но с mobx получится на порядок лучше, чем на любом другом, и практически без бойлерплейта.
о Redux архитектуре во Flutter приложениях