Пока делю их типа elements/blocks/cards/ в таком ключе на модули, связками, но ясно что не везде нужна вся гроздь компонентов. до заворачивания каждого как то еще не видел смысла.
но вот с сервисами внутри какого то такого плана модуля с одним компонентом (типа кнопка + сервис внутри модуля одного) то он шерился с форРутом чтоб не создавать лишний инстанс сервиса - это НЕ правильно?

читал статьи что шаред можно поделить так и вообще его не юзать - удалить, но как с форРутовыми модулями, в том числе и third-party? Но больше интересует вопрос своих личных с форРутом

Ну у нас нет шаред модуля, только папка

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

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

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

BEM в помощь - та же логика с модулями

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

Не совсем ясен контекст, можно чутьчуть подробней?

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

Спасибо за инфу))
Тем не менее, неясно, где в отмену шаред.модуля лучше импортить експортные модули с форРутами? В app.module мне кажется это немного бардачно, или я ошибаюсь?

не претендую в топ советчики но у нас на проекте сделал так - AppModule выступает оберткой, в него ничего не инжектится кроме модулей. А дальше идет разбивка на CoreModule и разного рода FeatureModule и всякие вспогалки аля Config и тому подобное. В вашем случаее я так понимаю Shared можно разбить также на разные модули что-то. вроде UI/Utils и их уже наполнять модулями по смыслу

Я не оч понял о чем это

Вот грубо так и разбито, но все равно все эти смысловые гроздьевые модуля приходится совать в шаред, чтоб в аппе этот шаред воткнуть только лишь один. Преследуется идея, чтоб в app.m были только необходимые для самой апки модуля типа browser, animations, translate, итд, чтоб прозрачней был сам модуль, и в нем же шаред со всеми layouts.m, elements.m и проч. Он видимо у многих зовется  common или core.. просто ддя себя пытаюсь понять какие архитектуры избегают шаред модуля и как именно потом форРуты работают, если они не заинжектены на рутовом уровне

я думаю без примера кода тут не разобраться ))

к примеру есть в проекте таблицы с сортировкой поиском по ней и тому подобное - значит есть модули TableModule/SearchModule/SortableModule?PaginationModule - все это лежит в папке Shared но не в модуле Shared - дальше в проекте у вас есть к примеру таблица пользователь - значит будет модуль UsersListModule в который будут импортироватся выше перечисленные модули

Да, это так. Если модуль является feature и просто чтото рисует сам по себе,  инкапуслируя в себе всю логику/сервис то это ок. Но если у какого то модуля есть експортируемый сервис нужный для работы в руте синглтоном - то его нужно импортировать в core -> а core в app.m? Так? У кого как?)))

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

Ясно. Спасибо за дискуссию. Хорошо было бы в стиле ngAir похоливарить на тему архитектур))

Ребята, привет всем. есть у меня в приложении интерептор. Его я используюв 3 модулях из 5. Не использую в app.module и  auth.module. Но запросы из auth.module он все равно интерсептит. куда глянуть, что проверить возможно, чтоб выявить где он вызывается?