Создание приложений на Angular с использованием продвинутых возможностей DI

[essome]

Какой-то оверинжиниринг получился.

[marshinov]

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

[andrey_vlas]

Вообще говоря, это я и предлагаю делать — выделять и наследовать сервисы. Манипуляции с подменой зависимостей обычно помогают избегать создания лишних компонентов с сервисами и написания повторяющегося кода. Например, подмена контроллера может заменить передачу десятка Input Output параметров через несколько уровней вложенности на одну строку с провайдером. Разумеется, использовать техники стоит только в случаях когда они приносят конкретный профит.

[marshinov]

Кажется, понял. Вы имеете в виду, что, к примеру, если у вас есть 3 похожих контроллера, то сделать один абстрактный базовый, унаследоваться и засунуть их в конкретные компоненты через DI. Либо сделать generic и его тоже просунуть через DI, верно?

[andrey_vlas]

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

[marshinov]

Может тогда лучше использовать ViewModel для этого? Если человек видит контроллер, первая мысль — ага, это MVC. В тексте вы пишете, что "ну это не MVC", но это придется объяснять просто вообще каждому первому. С другой стороны, концепт View Model, Services хорошо изучен. Если к вам придет человек с бекграундом из, скажем, Xamarin или WPF, он увидит знакомые вью модели и быстро поймет что к чему.

[andrey_vlas]

Все же ViewModel в оригинале предполагает связывание данных, которое в ангуляре я не использую. Мой подход совпадает скорее, например, с паттерном Presentation Model отсюда
В статье я попытался описать его достаточно подробно, чтобы не пришлось ссылаться на другие паттерны.

[david2tm]

Разрешите предложить вот эту библиотеку. Она тут выполняет некоторые паттерны которые вами описаны ngrx.io

[andrey_vlas]

Я упомянул ее в статье. Работал с ngrx достаточно долго, правда давно, возможно там что-то принципиально изменилось. После нее долго работал с ngxs. И считаю что для ангуляра они просто поворот не туда. Из самых очевидных минусов — огромное количество ненужного бойлерплейта, в коде сложно понять где будет обработан экшен, как и где обрабатывать ошибки. Невозможность переиспользования стейта наследованием — нужны будут уже другие экшены которые заодно придется заново описать. Более того просто нет возможности использовать преимущества иерархии инжекторов для переиспользования кода. Не вижу ни одной причины чем это лучше прямого вызова функции у сервиса, как я предлагаю. Ngxs кстати, пытались сделать подобный костыль, который достаточно криво работал. akita же из коробки предлагает нормальный подход, и кстати работает с ReduxDevtools.

[david2tm]

Я думаю что поменялось не мало. Бойлерплейта стало намного меньше, но он есть. А вот насчет переиспользования, создатели активно против этого. Они явно заявляют что это анти-паттерн. Ngxs — мне не понравился.

[talerok]

Теоретически да. На практике — сложно. Тут на проекты с Ngrx/Ngsx приходишь и материться хочется, а с таким то подходом пришедшие после люди вас просто не поймут.