Нужно ли тянуть все общие модули проекта, например 30 штук из Shared, если в действительности нужно пару модулей?
неправильно, нужно шаред модуль делить на маленькие подмодули
Зачем? Есть же тришейкинг, деление на субмодули только структурированность повысит
например, из Shared сделать "SharedTableModule" ,"SharedTuiModule" и тд?
А если приложение большое, с эстетической точки зрения не очень будет смотреться SharedModule. где 50-100 других модулей
советую подход SCAM - один компонент = один модуль. Тогда каждый модуль будет изолировать зависимости и функционал одного компонента, и webpack'у будет проще делать tree-shaking и разделять проект на файлы.
Тут shared модули экспортирует, так что scam не подходит Хз, всегда без shared работал и норм было, просто не заглядывал, что там ide наимпортила
Это хорошая штука до первого кольца зависимостей
удобнее управлять зависимостями. с шаредом потом не поймешь че где и как аккуратно заменить
А как с ним получить циркулярку?
Плодить модуль на каждый компонент - раздувать бандл сайз без причины
есть такая вещь, gzip называется
Если компонент = модуль, то рано или поздно в большом проекте получится: CompA imports CompB CompB imports CompC ....N imports M.... CompC imports CompA
CompC imports CompA кааак, они же атомарны
Если они все нижайшего уровня, когда каждый из них не требует импорта - вопросов ноль, но смысл же в реиспользовании компонентов. И любой частый в бизнесе кейс или редактор модели станет камнем преткновения всего дерева
Ааа, кажется понял, о чем вы Типа scam только для ui-core, а для страниц/форм обычные модули с кучей компонентов У меня такое деление
Ну в целом да, обёртки над 3rd party или простейшие формочки ввода - это все прекрасно работает на scam и действительно удобно, спорить тут сложно. Но первая же сложная модель которая циклична в своей сути (дерево например) вызвало цикл зависимостей, который кроме как мержом в один модуль не удалось разрешить
модули которые вызывают цикличные зависимости можно динамично импортировать и собирать с помощью createNgModuleRef
Да, но это ломает tree-shacking и является сокрытием ошибок модульности приложения. Каждый такой кейс хорошо бы разбирать отдельно и решать на месте. Вероятность того, что модули вызвавшие цикл должны быть декомпозированы и реорганизованы по опыту всегда высока.
Хз, никогда не получалось на такое наткнуться Дерево по идее через ng-content + contentChildren спокойно резолвится, я сто лет назад лазил в его реализацию и не вспомню уже
Если есть модель в духе такой, то тут лучше решение как иметь компонент <class-a-editor> и <class-b-editor> в одном модуле я не нашел к сожалению, возможно я что-то упускаю конечно. ClassA { prop1: string; prop2: ClassB; } ClassB: { prop1: number; prop2: ClassA; }
Обсуждают сегодня