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