Как стать автором
Обновить

Комментарии 14

Если не сложно - добавьте плз схемку архитектуры: кто кого тыкает и кем погоняет.

Как раз на выходным разбирался с архитектурой хомяка (у меня Vue + fabricJS), остановился на MVP + нашлепка к презентеру в виде менеджера (у меня объекты - это несколько объектов fabricJS со своими методами).

PS Правда у меня скилл программирования небольшой (хорошо если уровень джуна).

Ну в целом я не знаю что рисовать, это есть в инете) Тут главный принцип:

Во вьюшке доступ к стору - readonly

Стейт можно поменять только через презентер, вызвав нужный публичный метод

Презентер меняет только тот стор который ему передали

Composition API меняет немного правила ;)

Будет еще удобнее) Там не будет вьюкса и т.п

MVP очень приятный паттерн. Работал с ним во времена WinForms лет 15 назад.

Мы тогда тоже использовали подход, когда view дергает методы presenter'a, но потом перешли к более удобному и, на мой взгляд, правильному варианту: view не знает ничего о presenter'e и генерит события. Presenter подписан на эти события и реагирует. На события также может быть подписан mediator, который как раз имеет право дергать методы presenter'ов, потому что знает о них, чтобы реализовать реакцию одной view, на события другой.

У вас, я так понял, есть шина событий, не думали о таком варианте?

В этом что-то есть, но я пока не могу придумать чем это может быть полезным? События сложнее отследить в отличии прямого доступа к презентеру. К тому же каждый компонент имеет право обратиться только к своему призентеру.

И в IDE быстрые переходы и рефакторинг работает

Если я правильно помню, мы событиями решали проблему общения с медиатором, так как он реагировал на события напрямую. Ну, и с архитектурной точки зрения view-компонент, как мне кажется, более правильно выглядит: я умею показывать данные, которые мне дают и сообщаю о том, что у меня что-то произошло, но больше ни о чем я не знаю.

Проблема вызова только своего presenter'a решалась с помощью настроенной шины событий, которая представляла собой дерево, где корень - это медиатор, а лист - view. соответственно событие, всплывая от view просто не могло попасть к чужому presenter'у.

Ваш вариант тоже вполне рабочий и если с ним нет проблем - почему нет?

Стандартные подходы Vue, где во Vuex экшенах делаются запросы и кладутся в стор и т.п не расширяемые

Мне тоже всегда виделось, что это плохо масштабируется. Поэтому вынес из стора обращения к сервисам в отдельный слой, похожий на описанный у вас презентер. Правда на React пишу, но они с Vue довольно похожи.

Вы сделали пол-шага к Clean Architecture. Я бы добавил inversifyjs для менеджмента зависимостей и заменил vuex на rxjs.

Незачем rxjs там где всё построено на реактивности) inversifyjs норм тема, изучу)

rxjs помогает добавить реактивность в обычные ts-классы, сервисы, репозитории и тп...можно конечно событийные шины лепить на колбэках, свою реализацию observable написать на проксе - дело вкуса, но ИМХО оно того не стоит. Хотя у rxjs есть свои проблемы.

Соглашусь, но пока жырновато) Позже можно будет внедрить уже вместо шины

привет с митапа) можешь, плиз, гитхаб добавить?

Привет) В конце статьи ссылка)

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.