Comments 12
Если б ангуляр еще не был бы монолитом, пытающимся объять необъятное — цены бы ему не было. А так очень забавно наблюдать, как прекраснейшие идеи из ангуляра (а их там довольно много, без шуток, начиная с модульности и заканчивая (старым) роутингом, который потом превратили в УГ, но переизобрели обратно) потом заново реализовываются в разных мелких либах и фреймворках, практически таким же образом — и получают большую популярность, потому что идеи-то прекрасные, особенно когда не надо для их использования вкорячивать ангуляр целиком.
+2
Не могу полностью согласиться, мне как раз нравится что все что нужно идет из коробки, по желанию можно добавить NgRx. Надеюсь что они доведут treeshaking до ума, и тогда большой размер исходного ангуляра станет меньшей проблемой. А так работа с ним пока не доставляла каких-то огорчений.
+3
UFO just landed and posted this here
И как происходит аудит и менеджмент сторонних зависимостей, например, в ваших проектах, как я полагаю, составленных из множества библиотек?
Да так же, как везде. Фиксируем версии, проверяем все непрямые зависимости, по необходимости вообще выгружаем зависимости себе и запиливаем регламент их обновления, включающий и повторный аудит.
Например, с Ангуляром я могу заложиться на срок жизни (поддержки) всего монолита
Если вы в ангуляре собственноручно и под крылом одной конторы нафигачили от начала и до конца проект — то да. Если вы взяли ангуляр и поняли, например, что красивые контролы вам ангуляр сам не нарисует, и пошли собирать сборную солянку из готовых ангуляр-компонентов — поздравляю, у вас всё точно так же, как и у других без ангуляра. И солянка ваша может развалиться примерно с такой же вероятностью.
+1
UFO just landed and posted this here
Про контроль зависимостей понял, так и думал, вы используете какие-то автоматические инструменты для этого?
Ни разу не приходилось работать с настолько большой солянкой, чтоб это стало надо. Один раз, когда нужен был жесткий контроль лицензий — написали (за полчасика) шелл-скрипт, читающий license из package.json на предмет всяческого ата-та (а потом заменили его на чуть более умный сканер лицензий на ноде, который вообще все файлы смотрел на предмет ключевых слов не в белом списке).
Ну и там естественно регламент был, чтоб при каждом обновлении зависимостей это всё прогонялось, и любые положительные срабатывания либо отправлялись на разборки с юристами, либо же рубились бы обновления.
Что касается моих проектов, то нам повезло мы почти все пишем сами, что касается UI.
Ну да, и это тот самый случай где ангуляр действительно очень уместен.
0
Насколько я понимаю, как минимум material стал частью ангуляра, про сторонние компоненты понятно, что ситуация таже
+1
Проблема высосана из пальца. В процессе развития любое приложение обрастает библиотеками и самый легкий Вью или Реакт начинают напоминать Франкенштейна. Так что лучше сразу обо всем позаботиться)
0
Ну вот в том-то и дело, что не любое.
И кроме того, есть еще другой момент — вот эти самые «библиотеки», которые не только с npm берутся, а иногда и собственные пишутся. Когда у вас есть небольшая библиотека (скажем, компонентов UI, хотя есть и другие варианты), но она с собой тянет всю массу ангуляра — это грустно. Когда у вас таких небольших библиотек три, и каждая тянет с собой отдельную версию ангуляра (потому что версии разные) — это уже не грустно, а ужасающе.
И кроме того, есть еще другой момент — вот эти самые «библиотеки», которые не только с npm берутся, а иногда и собственные пишутся. Когда у вас есть небольшая библиотека (скажем, компонентов UI, хотя есть и другие варианты), но она с собой тянет всю массу ангуляра — это грустно. Когда у вас таких небольших библиотек три, и каждая тянет с собой отдельную версию ангуляра (потому что версии разные) — это уже не грустно, а ужасающе.
0
Заметил небольшую очепятку в статье в самом начале раздела «как обновиться до 9 версии»: «Пройлите»
+1
Sign up to leave a comment.
Angular 9 теперь доступен — Ivy прибыл