Comments 17
будет ли доступ к _-свойствам работать с минифицированным angular.js?
-1
впрочем, быстрее оказалось посмотреть самому. Да, сейчас это работает. Полагаю, что может перестать в любой момент.
0
а с чего бы это им быть не доступными? минификаторы не изменяют имена пропертей объектов. Только локальные имена функций и переменных.
-1
это примитивные минификаторы не изменяют. Angular использует Google Closure Compiler, у которого есть режим aggressive, и в нём «private» свойства объектов очень даже изменяются, если только явно не отметить их неизменными. Посмотрите на код gmail, например.
0
эти проперти специально делают доступными из вне с пометкой что это внутренние состояние. closure compiller смотрит только на аннотацию private, которой там нет.
0
вот это уже более достойный ответ. Первый-то был откровенной неправдой. А если бы вы ещё сразу мне сказали, использует ли angular ADVANCED_OPTIMIZATIONS вообще, и отмечает ли хоть какие-то свойства как private, было бы совсем хорошо
0
Перевод на троечку. Особенно умиляет «одним из лучших шаблонов для front end разработки». Вообще ваш перевод довольно тяжело читать.
по поводу описанной реализации, она довольно очевидна. Вот только я не вижу особо преимуществ у этого способа перед банальной асинхронной загрузкой скриптов (перед закрывающимся body). В любом случае ленивая или не очень, но это инициализация приложения. И все зависимости будут подключаться уже в момент инициализации, а могли быть загружены раньше.
Скажем у меня в приложениях почти все модули используют $routeProvider на этапе конфигурации, так что модули просто будут вынуждены загрузиться одновременно.
Пока видел только ленивую подрузку модулей с целью сложить в модули переводы текстов/шаблоны
по поводу описанной реализации, она довольно очевидна. Вот только я не вижу особо преимуществ у этого способа перед банальной асинхронной загрузкой скриптов (перед закрывающимся body). В любом случае ленивая или не очень, но это инициализация приложения. И все зависимости будут подключаться уже в момент инициализации, а могли быть загружены раньше.
Скажем у меня в приложениях почти все модули используют $routeProvider на этапе конфигурации, так что модули просто будут вынуждены загрузиться одновременно.
Пока видел только ленивую подрузку модулей с целью сложить в модули переводы текстов/шаблоны
+1
Год назад я написал этот модуль, запостил статью на хабр. Теперь кто-то улучшил мой модуль, запостил статью, затем кто-то перевёл её и зпостил на Хабр. Круто.
+7
Меня всегда волновал вопрос, зачем люди используют ленивую загрузку по сети. Ну, вот например, многие обосновывали мне использование require.js или AMD.js — мол модули, мы без них жить не можем, а тут они есть и это круто. Ок.
Здесь я вижу пример, когда даже CommonJS не поддерживается, усложняется код, делается более шатким. И меня очень волнует вопрос, зачем это надо, и чем это хуже, нежели соединить все файлы в один (или несколько больших), минифицировать их, и со спокойной душой отдавать это клиенту один раз, и не париться насчет кеширования, задержек в интерфейсе из-за лишних загрузок, и так далее.
В каких особенных ситуациях нужны вот такие костыли (вероятно они есть, но лично я их никогда не встречал, ну разве что чистейший SPA, и то это довольно редко обоснованный случай)?
Здесь я вижу пример, когда даже CommonJS не поддерживается, усложняется код, делается более шатким. И меня очень волнует вопрос, зачем это надо, и чем это хуже, нежели соединить все файлы в один (или несколько больших), минифицировать их, и со спокойной душой отдавать это клиенту один раз, и не париться насчет кеширования, задержек в интерфейсе из-за лишних загрузок, и так далее.
В каких особенных ситуациях нужны вот такие костыли (вероятно они есть, но лично я их никогда не встречал, ну разве что чистейший SPA, и то это довольно редко обоснованный случай)?
+3
если у вас приложение сильно модульное и один из модулей может спокойно работать без учета остальных — то это полезно. Но в случае с приложениями на angular.js я слабо представляю себе такой кейс.
0
А что мешает разбивать приложение на модули (даже если они не связаны), загружать клиенту один раз большим (или несколькими поменьше — там в зависимости от) файлом, и кешировать это у него же (я имею ввиду инструменты подобные assets pipeline из Rails)? Тем более, так будет даже быстрее, чем за каждым мелким файлом обращаться к серверу, тратить время на коннект, ждать загрузки, и только потом получать полезный профит от непосредственно кода?
Есть еще какие-то причины такой вот ленивой загрузки?
Есть еще какие-то причины такой вот ленивой загрузки?
0
Sign up to leave a comment.
Загрузка модуля по требованию в AngularJS