Pull to refresh

Comments 22

Есть прикладной смысл загрузки модуля по требованию?

Мне казалось логичнее наоборот при бутстрапе ангулара грузить все, включая темплэейты, кэшировать их и дальше ходить к серверу уже за данными/сохранением данных. так гораздо проще можно обрабатывать ошибки + сделать полуофлайновое приложение.
Смысл обозначен в начале статьи. Представьте, что у Вас приложение с сотней-другой модулей. Каждый модуль реализует функционал для одной из групп пользователей приложения. Может так получиться, что конкретному пользователю, из всей сотни модулей для работы необходим только десяток. Остальные 90 он просто не имеет право использовать.
ну так может логичнее на момент бутстрапа уже знать что ему можно, а что нет, и грузить нужное?

Просто довольно частый кейс: работаем, потом бах, на минуту пропало соединение, если все загружено, мы покажем пользователю сообщение что соединения нет, но все его данные будут сохранены и отправлены на сервер после восстановления соединения. (см. гмайл например). пока связи нет работаем с локальным сторэджем. как только появилась — отсылаем все на сервер.

в случае если чтото не загружено, то пользователь лишается такой возможности. более того, то что уже загружено скорее всего тоже перейдет в непредсказуемое состояние, если пользователь попытается открыть незагруженный модуль и получит ошибку.

у нас например есть пользователи, которые с ноутбуком заходят в глубину помещений и там связи нет ( бц, офисное здание, склад) а работать им там надо
У любой технологии есть свои плюсы и минусы. Всегда приходится искать какой-то компромисс. Для Вашего сценария (с нестабильной связью) возможно, что полная загрузка в начале имеет смысл. Но тем не менее это не повод для фундаментального ограничения в других сценариях. К тому же функцией конфигурации модуля предусмотрено указание модулей, которые были загружены при bootstrap`е. Таким образом при первоначальной загрузке можно указать некоторый «ядерный» функционал, который будет доступен сразу после загрузки приложения.
Да, конечно. мне просто хотелось ваш случай понять. спасибо за объяснения.
Добавил прозрачную поддержку загруженных angular`ом модулей в штатном порядке. Теперь не нужно ничего указывать при конфигурировании. Все модули которые были загружены процедурой bootstrap автоматически учитываются загрузчиком.
особенно если учесть, что для приложения с сотней модулей, которым часто пользуются пользователи, фактически загрузка будет только 1 раз. потом все из кеша будет браться.
UFO just landed and posted this here
Это значит что данные предоставляемые модулем предназначены для определённой группы пользователей, и эти данные не должны попасть в другую группу. Простейший пример: директор-сотрудник. Наличие всех модулей на клиенте — это потенциальная бреш в безопасности.
UFO just landed and posted this here
Хочу обратить внимание, что целью статьи было показать решение для отложенной загрузки для angularjs, а никак не единственно верный механизм для обеспечение безопасности приложения.
А что касается безопасности, то конечно глупо надеяться обеспечить безопасность только средствами клиента. Но как по мне, так я не хочу оставлять ключ под ковриком, даже если он от второй двери.
UFO just landed and posted this here
По крайней мере мне, так проще конфигурировать функционал приложения. На клиента передаётся меню, которое формируется в зависимости от роли пользователя приложения. Дальше уже работает отложенная загрузка, которая подтянет необходимый модуль как только его функционал будет востребован. Я это делаю следующим образом:
где-то в html
   <a href="#!/feature">cool feature</a>

код:
app.config(['$routeProvider', function ($routeProvider) {
    $routeProvider.
        when('/feature', { template:  '<div load-on-demand="\'feature\'"></div>' });
} ]);
app.config(['$loadOnDemandProvider', function ($loadOnDemandProvider) {
    var modules = [{
        name: 'feature',
        script: 'js/feature.js',
        template: 'template/feature.html'
    }];
    $loadOnDemandProvider.config(modules, []);
} ]);


На клиента не тянется ничего лишнего при старте — уже хорошо. Упрощается отладка — тоже неплохо. Применение находит в достаточно больших проектах, где весь функционал грузить при старте не только накладно, но и не за чем.
UFO just landed and posted this here
Не забывайте про то, что браузеру нужно не только загрузить JS-код, но и «скомпилировать» его — на это тоже уходит некоторое время при ощутимом количестве кода.
К тому же, говоря про кеш (браузера?) вы вероятно забываете, что есть пользователи, которые зайдут на ваш сайт всего один раз, и не дождавшись загрузки более никогда на него не вернутся. Сейчас, при бурном развитии мобильного интернета, этот сценарий становится всё более вероятным.
UFO just landed and posted this here
«Или что» — на реальных скоростях 3G даже несколько мегабайт будут грузиться непозволительно долго. Говоря за себя, я обычно закрываю сайт, который не осилил загрузиться примерно за 5 секунд.
Ну и на крупных городах свет клином не сошёлся, скорость интернета в глубинке часто бывает весьма низкой.
UFO just landed and posted this here
UFO just landed and posted this here
Насчёт 4-го пункта — спасибо. Добавлю в вызов функции $loadOnDemandProvider.config функцию, которая будет вызываться при ошибках загрузки. Или подумаю, как это сделать иначе. А то на данный момент всё в $log пишется.
Ну как всегда же — тяжелые виджеты, которыми пользователь не часто пользуется бессмысленно загружать сразу же
Слава богу у меня не такое большое приложение. Обхожусь объединением на стороне сервера в один файл нужного и отдаче пользователю. После ExtJS конечно было не привычно, даже пробовал готовый вариант lazy loading, но с отладкой у меня не заладилось(просто отсутствие нужных скриптов в списке загруженных, хром.) и в итоге пришёл к такому методу, потом можно будет и минифицировать на ходу.
Sign up to leave a comment.

Articles