Shared Module - любимый антипаттерн angular разработчиков. Как он влияет на размер бандла?
ฝัง
- เผยแพร่เมื่อ 8 ก.ค. 2024
- Видео сумбурное, переснять не получается, если тяжело, то переходите к краткому гайду.
Shared module это антипаттерн который вносит ряд проблем в проект:
- увеличивает бандл на размер не используемых компонентов
- не дает возможности использовать private компонентов
- сложный в поддержке и рефакторинге
- и много другого
В этом видео я показал насколько изменился размер бандла при уходе от общего модуля по типу shared, более ярко проблема будет видна при работе с роутингом, но это тема другого плейлиста
==============================
Код готового урока:
github.com/MaksymGrom/angular...
==============================
Инструкция по установке angular проекта:
Вариант 1:
Пройдите плейлист: • Как работает WEB. Мест...
Вариант 2:
github.com/MaksymGrom/angular...
Загрузите зависимости (npm install)
Можно запускать проект (ng serve)
==============================
Выбор редактора код это дело каждого, но в этом плейлисте я использую webstorm. Как настроить один из популярнейших редакторов ниже:
VS Code: • VS Code extensions для...
WebStorm: • WebStorm работа с angu...
Архитектурные елементы Angular • Angular архитектурные ...
Основы RxJS • RxJs Теория: Observabl...
Подробнее об OnPush • ngOnChanges vs ngDoChe...
Немного старого видео об иммутабельности • Immutable. Неизменяемо...
Не забываем что SQL важен независимо чем планируешь заниматься при веб разработке, даже если планируешь быть менеджером проектов.
Курс по SQL можно найти по ссылке: • Что такое SQL? Как раб...
Спасибо что продолжаете смотреть меня и радовать комментариями.
---- Соц сети
Телеграм, где можно узнать о новых видео и получать доп контент
t.me/webDevGromMaxChannel
P.S. В youtube я отвечаю быстрее чем в telegram, буду рад комментам в youtube
----
Чтобы поддержать канал
1) Можно поставить лайк (или дизлайк, если не понравилось видео)
2) Оставить комментарий более 5 слов
3) Досмотреть видео до конца (так удержание будет выше и мне это поможет в продвижении)
4) Оставить отзыв в комментариях, что можно улучшить в видео, чтобы не хотелось его закрывать
5) Можно стать участником моего канала на платной основе / @grommaks
#directives #angular #grommax
Материально поддержать канал можно следующим способом
1) Перевод на карту send.monobank.ua/7oqmsFg3Y
2) Пройти опрос, чтобы помочь выбрать подходящие варианты поддержки
forms.gle/ZbFCKJSpDNYp4AMC6
Оглавление
00:00 - Введение
00:28 - Shared Module пример
01:28 - Увеличенный бандл с shared
03:45 - Lazy loading и размер бандла
05:21 - Чем еще плох shared?
06:52 - Альтернатива shared module
10:06 - Краткий гайд
Единственное, о чём жалею, это о том, что это видео не вышло раньше. Спасибо
Хорошее объяснение, спасибо!
Красавчик, раскидал по полочкам, как надо
ВОобще тема об анализе размера бандла, интересная.
Очень круто, не думал что так можно. Контент супер, продолжай в том же духе)
Спасибо)
с помощью standalone и lazy loading уменьшили бандл на проекте с 58 Мб до 4 Мб, цифра не финальная, еще работаем :)
Спасибо за видео, за это и за все другие по Ангуляру :) Контент уникальный и полезный :)
😮 шикарный результат, если гугл рейтинги важны, то я думаю сайт позеленел знатно 😄
@@grommaks важны, но пока релиза еще не было :)
Всё очень круто! Но хотелось би какой-то проект с регистрацией, сохранением состояния, типа магазина или какой-то админки, чтобы посмотреть как в работе всё выглядит, на реакте таких видео полно, а вот с ангуляром проблемы(! Спасибо за уроки
Интересное видео. Не совсем понятно какой смысл измерять размер бандла в dev режиме. В prod сборке Ivy и tree shaking решает все проблемы кроме взаимодействия с командой по поводу обновления shared компонентов.
Интересно, а при создании модуля для каждого компонента вместо standalone, насколько строк изменится бандл. Видел такую рекомендацию, мол это норм подход (но видимо сейчас уже не очень актуально).
А по поводу lazy loadinga никогда не тестил, но верил почему-то, что второй раз при роутинге ранее загруженные модули (тот же shared, родные модули) второй раз грузится не будут...
Angular собирает общие модули в бандл и грузит их один раз, по этому это точно :)
Stand-alone придумали чтобы такие модули убрать, и возможно скоро еще больше можно будет делать, но пока я вижу такое вот применение 🫣
показал бы результаты оптимизации после три-шейкинга в прод моде.
Честно ни разу в работе не видел такого, мы всегда импортировали из своей шаред либы только то, что нужно.
А почему три шейкинг не отсеивает незаюзанные молули при сборке?
До ivy не откидывали, с ivy нужно мне поэкспериментировать, не думаю что во всех сценариях будет хорошо работать
На текущем проекте shared и NX monorepo сильно замедляет скорость деплоя
объясните пожалуйста а зачем в таком случае делать все компоненты 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