Всем привет! Продолжаю мучать facade) Вопрос, на сколько правильно

использовать facade для общения между компонентами? К примеру если надо из одно компонента перекинуть объект-параметр в другой, сделать это путём добавления нужного поля в state в заполнить его в одном компоненте, и считать в другом?

че за фасаде то?

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

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

компоненты диктуют правила игры стору через абстракциию.

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

pattern https://balramchavan.medium.com/best-practices-building-angular-services-using-facade-design-pattern-for-complex-systems-d8c516cb95eb

причем тут вообще паттерн фасад и передача данных каких-то

ждём тогда ссылки на правильные статьи)

по хорошему фасад это класс который агрегирует более одной абстракции. в этой статье это больше адаптер, т.к одна абстракци

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

очень плохая абстракция

я сейчас прячу стейт за абстракцией и в компоненте работаю с ней. Основные методы getData updateData

у меня нет ссылок на статьи, лучше чистый код прочесть сначала и сами паттерны изучить. Чтобы понимать ДЛЯ ЧЕГО что-то делается, а не повторять бездумно

+++

объясняю чем плохо: у вас AuthService в вашем фасаде лишний, тк он используется только на гвардах... там в гварде он и инжектится, купируя его распространение в приложении OrderList или DashBoard (как и остальные) — конкретные компоненты, они тоже не должны гулять по приложению

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

ок, продолжай учиться по плохим статьям, меньше конкуренция

Фасад - это упрощение api по русски если

можно, просто интересно было узнать можно ли для этого использовать фасад и стейт)

нет

спасибо

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

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

я по схеме вижу, что так

а компоненты smart?

у меня всё проще на самом деле, не как в статье, я просто прикрутил detail-facade к detail-view(там create и update)+ state в которую я сохраняю все изменения с entity, но из list-view есть передача параметра selected entity в тот же самый detail-view

не понятно)

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

smart

вот посмотри как я делаю. будут вопросы пиши. https://github.com/evoytenkoapps/angular-best-practices/blob/master/examples/src/app/redux-store-ngxs/_services/facade/facade/animal.facade.ts#L8

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

Коротко можете сказать что это за Смарт?

спасибо большое, я как раз пример искал хороший)

https://github.com/evoytenkoapps/angular-best-practices#%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0

ключевое тут. ты провайдишь абстракцию на любую реализацию, хоть сервисы, хоть стору, хоть firebase. короче широкую на широкую)https://github.com/evoytenkoapps/angular-best-practices/blob/master/examples/src/app/redux-store-ngxs/_providers/animal-facde.provider.ts

А для чего это? Какие задачи решаются?

задачи простые - бери больше, кидай дальше и чтобы другим понятно было)

а вот компонент инжектит в себя абстракцию, найдешь в нем импорт сторы? https://github.com/evoytenkoapps/angular-best-practices/blob/master/examples/src/app/redux-store-ngxs/_components/_smart/animal/animal.component.ts#L17

исправил ссылку

не совсем понятно, если честно. у меня есть для работы с источниками данных - разные сервисы, которые уже реализуют интерфейсы. Из того что я читал и видел в примерах, я понял, что facade+state - это доп. слой, т.е. в стейте уже агрегируются данные под конкретный компонент в стейте компонента могут быть, данные из разных сервисов к примеру сущности и данные из справочников. а фасад служит для загрузки данных в стейт и сохранения изменений из компонента... сложность наверное ещё для меня в том, что большинство примеров с ngxs, а я пытаюсь сделать без него...

ну да верно. правильней мою реализацию назвать сервисом. вы мне скажите у вас компоненты импортируют state, стору или как там её, стейт менеджер короче?

можно данные грузить из фасада, можно из эффектов сторы как делает большенство , как лучше сам не знаю)

Такой фасад тоже плохо делать?https://github.com/onehungrymind/fem-production-angular/blob/04.0-facades/libs/core-state/src/lib/widgets/widgets.facade.ts

а это что такое? @fem/api-interfaces

Ладно-ладно, я не фронт-разраб Я не знаю что такое виджет даже просто увидел схему и применил свой опыт, походу мой опыт не релевантен тут вижу высокую связанность и пугаюсь 😂

компоненты импортируют facade, чрез него например идёт сохранение или загрузка данных, список сущностей к примеру, справочники тоже(правильно ли?) наверное проще будет показать, компонент ничего про state не знает

Алиас для импорта

норм короче, на мой взгляд

https://gist.github.com/WiktorNowikow/5062bc27eb5f209541353a3f40d4b7bc

Если ты используешь форм билдер, зачем там new контролы?

да, действительно, можно и без них, ты прав

сущности тянутся из внешней либы?

советую сделать абстракцию для фасада InstitutionsWithoutInnDetailFacade, как в моих пемерах.

а вы мокируете http сервисы?

нет, они просто у меня сгенерированы Swagger UI

Юра 🪐

если тут @fem/api-interfaces лежат дто бекенда, то не верно их использовать в виджете.

must have. https://github.com/evoytenkoapps/angular-best-practices#%D0%BC%D0%BE%D0%BA%D0%B8%D1%80%D1%83%D0%B5%D0%BC-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D1%8B

Там не дто а интерфейсы, как тогда шарить интерфейсы между двумя апками

там сущности что бек возвращает?

По сути да

их по хорошему, нужно мапить на такие же, но из другой папки. например models

у вас бизнес зависит от http, это плохо с точки зрения той же dependency inversion

Это не мой проект))

По-хорошему дто должны лежать там, где их используют, а не прострации висеть в какой-то кучи всего Так изменение дто влечёт и изменения компонента/сервиса, одно место

У меня на работе, одна и та же модель на разных ендоинтах имеет разные названия свойств)))

Потому что это др модель и пересечение случайное Логический каплинг не достаточен для объединения в коде Дублирование данных не есть дублирование логики, и значит под dry не попадает

мокировать, это же создавать искусственные сервисы?

ага.

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

Кстати а как вы мапперы делаете? Я делаю клас в котором статик методы

почитайте мой гайд. вам там есть что поправить. 1) добавить модификаторы доступа на все 2) указать типы функций 3) убрать any 3) добавить явную отписку через takeuntil или заменить подписки на операторы высшего порядка.

Swagger UI генерирует клиентский код по api, т.е. у меня настоящие сервисы http, им сгенерированные

да, спасибо, это я уже увидел многое по Вашим примерам

это не angular, но в целом так как и тут. объект с методами. В ангуляре статик методы не нужны, т.к. инжектор поставляет уже инстансы

А я инстанс и не делаю

статик метод - это метод не прототипа, а самой функции-конструктора.

Ну я не делаю инжект класса

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

я понял косяк. loadGlosItemStatuses - должен поток возращать, а не supbscription. переделайте на поток и подписывайтесь в компоненте. и будет норм. добавите в компоненте takeuntil, т.к там есть onDestroy

эммм не совсем понимаю, вот с loadGlosItemStatuses я думал всё норм он же темплейте вызывается (glosItemStatuses$ | async) , а такие подписки вроде уничтожаются автоматический после дестроя компонента? или нет?

вот тут дичь( https://gist.github.com/WiktorNowikow/5062bc27eb5f209541353a3f40d4b7bc#file-institutions-without-inn-detail-component-ts-L89

понял, спасибо, сейчас попробую)

надо сделать this.facade.loadGlosItemStatuses().pipe(takeUntil(...)).subscribe()

onDestroy в компоненте же?

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

да.

спешл фо ю https://github.com/evoytenkoapps/angular-best-practices/blob/english/examples/src/app/components/how-to-unsubscribe/unsubscribe.component.ts

не понимаю. переведите в фасаде все на реактивные потоки или интерактивные методы. все подписки в компонент.

Thanks a lot

что в итоге то?

https://gist.github.com/WiktorNowikow/0ec1fbd2e3fde633187b9b3809620da4

с map массива криво работаете.

можете подсказать, где именно косяк

Raman Yazvinski
результат мапа должен куда-то присваиваться, для д...

спасибо, понятно, проще тогда действительно forEach использовать с такими массивами