с помощью standalone и lazy loading уменьшили бандл на проекте с 58 Мб до 4 Мб, цифра не финальная, еще работаем :) Спасибо за видео, за это и за все другие по Ангуляру :) Контент уникальный и полезный :)
Всё очень круто! Но хотелось би какой-то проект с регистрацией, сохранением состояния, типа магазина или какой-то админки, чтобы посмотреть как в работе всё выглядит, на реакте таких видео полно, а вот с ангуляром проблемы(! Спасибо за уроки
Интересное видео. Не совсем понятно какой смысл измерять размер бандла в dev режиме. В prod сборке Ivy и tree shaking решает все проблемы кроме взаимодействия с командой по поводу обновления shared компонентов.
Честно ни разу в работе не видел такого, мы всегда импортировали из своей шаред либы только то, что нужно. А почему три шейкинг не отсеивает незаюзанные молули при сборке?
До ivy не откидывали, с ivy нужно мне поэкспериментировать, не думаю что во всех сценариях будет хорошо работать На текущем проекте shared и NX monorepo сильно замедляет скорость деплоя
Интересно, а при создании модуля для каждого компонента вместо standalone, насколько строк изменится бандл. Видел такую рекомендацию, мол это норм подход (но видимо сейчас уже не очень актуально). А по поводу lazy loadinga никогда не тестил, но верил почему-то, что второй раз при роутинге ранее загруженные модули (тот же shared, родные модули) второй раз грузится не будут...
Angular собирает общие модули в бандл и грузит их один раз, по этому это точно :) Stand-alone придумали чтобы такие модули убрать, и возможно скоро еще больше можно будет делать, но пока я вижу такое вот применение 🫣
объясните пожалуйста а зачем в таком случае делать все компоненты standalone, если можно их сделать обычными компонентами и записывать их в папку declarations а не imports, в чем разница?
Во первых это модно :) Во вторых можно потом удалять не используемый компонент с папки и все его зависимости автоматически будут убраны, так как он сам себя описывает. С 10 компонентов уже не понятно зачем столько импортов и какие можно удалить В третьих, это новый подход и команда ангулар работает над новыми возможностями, например host directive доступна если она standalone
ну допусти для lazy роутов не использовать Shared Module обосновано. А если их нет, и в большинстве компонент используются модули допустим с материала, что тогда будет в бандле? Или например как ведет себя шаред с библиотеками, когда у нас есть много энтри поитов и в каждом есть зависимость на шаред, если я не ошибаюсь в конечной js ки для энтри поита вкомплилится только то что импортировалось из шареда, а не весь шаред, если я не прав, поправите плиз. Не заводить шаред обосновано если в проекте все лезийно грузится, либо по какой то причине много зависимостей из него не используется.
Если нет ленивых модулей, то проект реально маленький Из примера в видео, даже если я не пользовался компонентом ни где, он попал в бандл Получается, модуль shared который подключает много всего из Material, а также подключает свои модули и компоненты затянет все это в конечный размер бандла Если в проекте условно matTable больше не используется, а он подключен в shared, то он попадет в бандл, аналогично будет с устаревшими компонентами и модулями в проекте Это называется treeShaking, на примере сервисов, которые providenIn root, если этот сервис удалить со всех компонентов, то он удалится из бандла, потому что его отдельно в shared не надо было регистрировать, и подчищать не нужно его Надеюсь не запутал)
@@grommaks Вообще не приятно что treeShaking не удаляет с шареда модули или еще что, компоненты которых или что то еще не используется( Если в разных стендалон компонентах используйся одинаковые зависимости сборщик вкомпилит их только один раз в общий банл, если компоненты не лейзи? Если лейзи то наверное тогда в каждом будет по вкомпиленой зависмости что не айс, в идеале бы взять вынесли все зависимости компонент в отдельный чанк и загрузить его вначале, а на него уже пусть ссылаются компоненты , иначе получается каждая компонента будет много весить если у нее много импортов, конечно это проблема решается прелоадам лейзи модулей или компонент, но все равно не айс если каждая стендэлон компонента будет тянуть в себе пол ui либы
@@MihailGrib не не, ангулар соберет common бандл для всего что общее, не будет много раз грузить одно и то же Говорят tree shaking есть если выключен ivy, и shared уже не такая большая проблема, но это надо проверить :)
Все shared компоненты собираются в отдельный бандл 'common.js', который подгружается при переходе в lazy компоненты, при этом, не lazy shared компоненты идут в 'main.js' бандл.
Интересно) Когда буду ковырять роутинг сделаю пример чтобы увидеть своими глазами :) Есть мысль что если подключить в AppComponent SharedModule то бандл пойдет в main а не в common
@@grommaks Если под SharedModule подразумевается компонент, то да, он пойдет в main.js, если используется в разметке или классе, и подключается как eager, а те, которые подключаются как lazy пойдут в common.js. Другими словами, shared ComponentA пойдет в main.js, импортированный в eager модуль, a shared ComponentB пойдет в common.js, если используется в LazyModuleA, при этом shared ComponentC (допустим, он испортирован в LazyModuleB), тоже будет в common.js. Common.js с компонентами B и C, один раз подтянется при переходе в любой из Lazy модулей, в которые они импортированы. Получается из main.js можно все "перенести" в common.js, а дальше пойдут lazy чанки.
Сделал шаред модуль с двумя компонентами A и B, подключил его в app и в lazy, из шареда в app A компонент использую, B в компоненте задекларированной в Lazy, common.js не появился, при переходе на lazy роут, грузится только этот модуль. class SharedModule вкомпилился в main, в src_app_layzy_module_ts только ссылки на него вида _shared_module__WEBPACK_IMPORTED_MODULE_0__.SharedModule
Я испоьзовал shared один раз и уже тогда понял что это не к чему хорошему не приведет. У меня структура папок почти как в nestjs. Но на хабре говорили что бандл или билд не помню может разростись)Но у меня lazy load в routinge
@@grommaks хм интересно если использовать Webpack Bundle Analyzer будет ли существенная разница в размере бандла до и после? Components vs module vs module + предзагрузка модулей
Все, що не використовується не повинно бути імпортоване в той чи інший модуль - це очевидні речі. Я теж проти цього патерну, особливо коли туди засунуть якийсь MaterialUI за всіми його модулями компонентів...
До Ivy це була проблема і ліпили таку штуку як SCAM паттерн, але це уже не актуально, тому розберіть для себе добре як працює tree shaking The Angular Ivy renderer, that replaces the now deprecated View Engine, has good support for tree-shaking and lazy loading components. It will not include unused components even if they are imported and exported in your SharedModule. In addition, it will move components into lazy loaded chunks even if other components of the same module are used in your main bundle.
Але я тут не договорив у відео, ще е така штука як NX monorepo, так ось shared module там дуже сильно сповільнює білд Тому ivy гарна штука, але не вирішує усіх проблем з shared
![[4K] Watch SpaceX Catch A Starship Rocket From Space!!! #IFT5](http://i.ytimg.com/vi/pIKI7y3DTXk/mqdefault.jpg)
Единственное, о чём жалею, это о том, что это видео не вышло раньше. Спасибо
с помощью standalone и lazy loading уменьшили бандл на проекте с 58 Мб до 4 Мб, цифра не финальная, еще работаем :)
Спасибо за видео, за это и за все другие по Ангуляру :) Контент уникальный и полезный :)
😮 шикарный результат, если гугл рейтинги важны, то я думаю сайт позеленел знатно 😄
@@grommaks важны, но пока релиза еще не было :)
Очень круто, не думал что так можно. Контент супер, продолжай в том же духе)
Хорошее объяснение, спасибо!
Всё очень круто! Но хотелось би какой-то проект с регистрацией, сохранением состояния, типа магазина или какой-то админки, чтобы посмотреть как в работе всё выглядит, на реакте таких видео полно, а вот с ангуляром проблемы(! Спасибо за уроки
Красавчик, раскидал по полочкам, как надо
ВОобще тема об анализе размера бандла, интересная.
Интересное видео. Не совсем понятно какой смысл измерять размер бандла в dev режиме. В prod сборке Ivy и tree shaking решает все проблемы кроме взаимодействия с командой по поводу обновления shared компонентов.
Честно ни разу в работе не видел такого, мы всегда импортировали из своей шаред либы только то, что нужно.
А почему три шейкинг не отсеивает незаюзанные молули при сборке?
До ivy не откидывали, с ivy нужно мне поэкспериментировать, не думаю что во всех сценариях будет хорошо работать
На текущем проекте shared и NX monorepo сильно замедляет скорость деплоя
Спасибо)
Интересно, а при создании модуля для каждого компонента вместо standalone, насколько строк изменится бандл. Видел такую рекомендацию, мол это норм подход (но видимо сейчас уже не очень актуально).
А по поводу lazy loadinga никогда не тестил, но верил почему-то, что второй раз при роутинге ранее загруженные модули (тот же shared, родные модули) второй раз грузится не будут...
Angular собирает общие модули в бандл и грузит их один раз, по этому это точно :)
Stand-alone придумали чтобы такие модули убрать, и возможно скоро еще больше можно будет делать, но пока я вижу такое вот применение 🫣
объясните пожалуйста а зачем в таком случае делать все компоненты standalone, если можно их сделать обычными компонентами и записывать их в папку declarations а не imports, в чем разница?
Во первых это модно :)
Во вторых можно потом удалять не используемый компонент с папки и все его зависимости автоматически будут убраны, так как он сам себя описывает. С 10 компонентов уже не понятно зачем столько импортов и какие можно удалить
В третьих, это новый подход и команда ангулар работает над новыми возможностями, например host directive доступна если она standalone
@@grommaks спасибо, очень ждем новые выпуски!)
показал бы результаты оптимизации после три-шейкинга в прод моде.
ну допусти для lazy роутов не использовать Shared Module обосновано. А если их нет, и в большинстве компонент используются модули допустим с материала, что тогда будет в бандле? Или например как ведет себя шаред с библиотеками, когда у нас есть много энтри поитов и в каждом есть зависимость на шаред, если я не ошибаюсь в конечной js ки для энтри поита вкомплилится только то что импортировалось из шареда, а не весь шаред, если я не прав, поправите плиз. Не заводить шаред обосновано если в проекте все лезийно грузится, либо по какой то причине много зависимостей из него не используется.
Если нет ленивых модулей, то проект реально маленький
Из примера в видео, даже если я не пользовался компонентом ни где, он попал в бандл
Получается, модуль shared который подключает много всего из Material, а также подключает свои модули и компоненты затянет все это в конечный размер бандла
Если в проекте условно matTable больше не используется, а он подключен в shared, то он попадет в бандл, аналогично будет с устаревшими компонентами и модулями в проекте
Это называется treeShaking, на примере сервисов, которые providenIn root, если этот сервис удалить со всех компонентов, то он удалится из бандла, потому что его отдельно в shared не надо было регистрировать, и подчищать не нужно его
Надеюсь не запутал)
@@grommaks Вообще не приятно что treeShaking не удаляет с шареда модули или еще что, компоненты которых или что то еще не используется( Если в разных стендалон компонентах используйся одинаковые зависимости сборщик вкомпилит их только один раз в общий банл, если компоненты не лейзи? Если лейзи то наверное тогда в каждом будет по вкомпиленой зависмости что не айс, в идеале бы взять вынесли все зависимости компонент в отдельный чанк и загрузить его вначале, а на него уже пусть ссылаются компоненты , иначе получается каждая компонента будет много весить если у нее много импортов, конечно это проблема решается прелоадам лейзи модулей или компонент, но все равно не айс если каждая стендэлон компонента будет тянуть в себе пол ui либы
@@MihailGrib не не, ангулар соберет common бандл для всего что общее, не будет много раз грузить одно и то же
Говорят tree shaking есть если выключен ivy, и shared уже не такая большая проблема, но это надо проверить :)
Все shared компоненты собираются в отдельный бандл 'common.js', который подгружается при переходе в lazy компоненты, при этом, не lazy shared компоненты идут в 'main.js' бандл.
Интересно)
Когда буду ковырять роутинг сделаю пример чтобы увидеть своими глазами :)
Есть мысль что если подключить в AppComponent SharedModule то бандл пойдет в main а не в common
@@grommaks Если под SharedModule подразумевается компонент, то да, он пойдет в main.js, если используется в разметке или классе, и подключается как eager, а те, которые подключаются как lazy пойдут в common.js. Другими словами, shared ComponentA пойдет в main.js, импортированный в eager модуль, a shared ComponentB пойдет в common.js, если используется в LazyModuleA, при этом shared ComponentC (допустим, он испортирован в LazyModuleB), тоже будет в common.js. Common.js с компонентами B и C, один раз подтянется при переходе в любой из Lazy модулей, в которые они импортированы. Получается из main.js можно все "перенести" в common.js, а дальше пойдут lazy чанки.
@@mtvspec до ivy это вроде работало не так, надо проверить:)
Сделал шаред модуль с двумя компонентами A и B, подключил его в app и в lazy, из шареда в app A компонент использую, B в компоненте задекларированной в Lazy, common.js не появился, при переходе на lazy роут, грузится только этот модуль. class SharedModule вкомпилился в main, в src_app_layzy_module_ts только ссылки на него вида _shared_module__WEBPACK_IMPORTED_MODULE_0__.SharedModule
@@MihailGribЯ делал все standalone компонентами, не использовал классические модули.
Я испоьзовал shared один раз и уже тогда понял что это не к чему хорошему не приведет. У меня структура папок почти как в nestjs. Но на хабре говорили что бандл или билд не помню может разростись)Но у меня lazy load в routinge
Мне не сильно везет на новые проекты
А на легаси shared есть почти везде, даже презентации делать приходится, чтобы обосновать что shared это плохо)
@@grommaks хм интересно если использовать Webpack Bundle Analyzer будет ли существенная разница в размере бандла до и после? Components vs module vs module + предзагрузка модулей
@@diatm1506 в комментах пишут что ivy в ангулар в прод билд много чего оптимизирует
Возможно ivy будет достаточно для работы, но я планирую потестить
Все, що не використовується не повинно бути імпортоване в той чи інший модуль - це очевидні речі. Я теж проти цього патерну, особливо коли туди засунуть якийсь MaterialUI за всіми його модулями компонентів...
До Ivy це була проблема і ліпили таку штуку як SCAM паттерн, але це уже не актуально, тому розберіть для себе добре як працює tree shaking
The Angular Ivy renderer, that replaces the now deprecated View Engine, has good support for tree-shaking and lazy loading components. It will not include unused components even if they are imported and exported in your SharedModule. In addition, it will move components into lazy loaded chunks even if other components of the same module are used in your main bundle.
Дякую за доповнення, треба спробувати увімкнути ivy
Але я тут не договорив у відео, ще е така штука як NX monorepo, так ось shared module там дуже сильно сповільнює білд
Тому ivy гарна штука, але не вирішує усіх проблем з shared