Народ, помогите, пожалуйста, разобраться как правильно делать инверсию зависимостей в

ангуляр. Я наконец разобрался что это такое и пытаюсь понять как ее правильно применять в ангуляре. Правильно я понимаю что компоненты, например smart , в котором находится бизнес логика - является самым высоким слоем. Следовательно если такой smart общается с redux через абстракцию, то данная абстракция должна лежать в той же папке/модуле что и данный компонент, верно? Сейчас я ложу данные абстракции в папке
module
_services - сервисы
facade - фасады
api - http сервисы

но я думаю насколько это правильно согласно DIP
https://github.com/evoytenkoapps/angular-best-practices#%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0

в компоненте не должно быть бизнес логики, начнем с этого

Еще и такие вещи как редакс (ngrx) зачастую овервейт для небольших или даже средних проектов

а где она должна быть? и правильно я понимаю что абстракция описывающая доступ к данным должна лежать там?

в сервисе, например

в идеале в частях, не связанных с фреймворком. Компонент это штучка просто для отображения данных, а логика лежит отдельно. В сервисе, да. Вообще пробежал по диагонали что у вас там написано, это скорее worst-practices 🥴 Возьмите Мартина лучше

а что за мартин? можно ссылку?

В сервисах и утилитарных классах

https://www.piter.com/product/chistyy-kod-sozdanie-analiz-i-refaktoring-biblioteka-programmista-45ccca

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

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

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

компонент отвечает только за view не больше и не меньше. вся логика в сервисах. зачем тебе компонент на 300-500 строк кода?

дайте это 100 проектов, я свой их опытом доплню

а какая разница где хранить это 500 строк кода, когда без них всеравно никуда?

я пока не понимаю что дает вынесение этих 500 строк в другой сервис и сто пудова процентов 20 продублируется в компонент

Компонент нельзя внедрять в другой компонент, а сервис можно Логика в сервисе легко переиспользуется

ну вот представь, у тебя компонент на 900 строк кода, дебажить такие макароны то еще удовольствие. проще разбить это все на компонент которые только отрисовывает верстку и к этому компоненту еще 2-3 сервиса, у каждого из них будет своя ответственность. такое и тестами покрыть проще и читать легче, и тестами покрыть попроще

тут. да. а если логика нужна только 1 раз?

А откуда ты это знаешь? Ванга есть в семье?)

ну и сделай небольшой сервис строчек на 50 и будет тебе счастье

а если для компонента достаточно 50 или 100 строк логики, тоже в сервис?

на проекте одном где работал было правило "компонент недолжен быть больше 150 строк (цифра условная), если превышает то это повод задуматься о вынесении логики в сервис(-ы)"

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

Можно выносить логику работы с данными (кандидаты на сервисы) в приватные методы, когда понадобится, приватный метод перенести как публичный в сервис и использовать в 2+ местах...это тоже норм компромис... Называется не прекращающимся рефакторингом (DDD), ну и в чистом коде такое можно встретить...

Уйййй За такие слова в подворотне пацаны могут побить 😅