понял) отличная аналогия

сделаю спасибо

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

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

не будут. В том и соль.

а как приложение узнает подключен роутер или он просто файлом лежит здесь

открываем корневую страницу => постучались на '/' - нам выплюнуло ОТДЕЛЬНЫЙ файлик js корневого модуля. Он имеет информацию о том, что при открытии ссылка '/foo' надо загрузить модуль foo и отдать управление ссылками '/foo/**' модулю foo, загрузили ОТДЕЛЬНЫЙ файлик foo.js и повторяем цикл до готовности

просто сделайте несколько лезимодулей и побегайте по страницам с открытой вкладкой network - миллион вопросов отпадет сразуё

нет в нормальном ангулар приложении solid-кирпича "это приложение". Есть набор зависимостей)

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

понял, поставлю целью разобраться

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

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

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

в долбаной пыхе после введения аннотаций начали поиском по тексту искать

в ларавелях сначала идут в главный роутер где регаются остальные

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

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

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

дело не в роутах, в принципе в модульности. Ангуляр пытается в ООП и тут рекомендуется поддерживаться принципа единой ответственности. APPModule не должен импортировать все зависимости приложения. Не должен декларировать все компоненты в приложении. Как минимум, каждая страница приложения должна быть инкапсулирована в NgModule со своими зависимостями. А еще лучше, применить принцип SCAM: Single component Angular module - 1 компонент = 1 ngModule. То есть у модуля не должно быть более 1 компонента в declarations.

да и начинает рыть все папки где ж тут роутер.

мои знания бека не дотянут даже до поверхностных, так что аргументированно оппонировать не смогу)) но в ангуларе логика проста, а для описания всей системы api давно придуманы openAPI 1-2-3, GraphQL и тому подобные вещи. Это просто РАЗНЫЕ сущности - роутинг ВНУТРИ ангулар приложения и обращения к бекэнд API