Разделение приложения AngularJS на изолированные модули

[kriptomen]

Я сейчас только в процессе изучения AngularJS, поэтому возникает вопрос — реально ли упереться в производительность на реальных проектах (а не синтетических тестах) при стандартном использовании scope?

[Fesor]

Зависит от задачи. Все что часто и много меняет DOM будет педалить, производительность падает линейно по мере роста количества ватчеров, повсеместное использование директив типа ng-click и т.д. вместо делигирования событий так же доставляет неудобства. Но решать проблемы до их появления не стоит, можно сделать только хуже.

[kriptomen]

А кстати, я там понимаю использовать делегирование в angular совсем неправославно?

[RiderSx]

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

[kriptomen]

Я неправильно выразился, я хотел сказать — «использовать делегирование императивно», аки в jQuery. Спасибо за мысль про директиву.

[Fesor]

Да, только декларативно есть православно.

[RiderSx]

Вполне реально, вывод списка >500 элементов (6 watcher'ов на элемент) уже заметно (~1s) тормозит, конечно, это если не пользоваться bind-once и иже с ним. Причем тормозит именно отрисовка, фильтрация или еще какие _внутренние_ действия над списком проходят без тормозов.

[kriptomen]

Вот к чему я и спрашивал. По-моему скромному опыту не могу вспомнить ситуацию, где необходимо было отрисовывать 500 итемов разом. Но возможно у меня все еще впереди. )

[RiderSx]

Вывод списка зарегистрированных людей на мероприятие, было грубейшей ошибкой с моей стороны выводить все это одним сплошным списком, по крайней мере в том виде, в котором я это сделал, сейчас я бы для этого использовал разбитую на страницы табличку еще и с bind-once в придачу :) Так что упереться можно, легко, но и избавиться от этого так же легко.

[Fesor]

Как только у вас появится задача добавить бесконечный скрол — сталкнетесь. Вот там уйма возможностей по оптимизации.

[GIum]

Вот годные рассуждения на тему произвоительности AngularJS от одного из его авторов. Но в общем случае, все действительно зависит от того на сколько часто будут вызываться обработчики $watch и на сколько большим будет сравниваемый scope.

[snater]

По идее, если в директиве «mover» изолировать scope, в ней же повесить вручную на элемент событие «mousemove», а внутри обработчика вызывать scope.$digest(), результат должен быть примерно такой же как в быстрой версии. Как то так fiddle

[fransua]

да, результат будет быстрее. Это как раз пример локальных улучшений, о которых я говорил в начале статьи.
В этом примере можно не использовать ангуляр, можно обойтись querySelector и innerHtml, будет наверно еще быстрее.
В большом проекте мест, где можно использовать локальные улучшения очень много и если с каждым возиться и думать, как его улучшить, уйдет очень много времени и будет очень много костылей.

[snater]

В большом проекте, рано или позно возникнут проблемы от подобного разделения, чаще всего у блоков на одной странице есть что-то общее и они должны как-то общаться, например сервисами или родительскими контроллерами. Для небольших изолированных блоков вполне подходят директивы, а если два больших блока на столько изолированы, что требуют разделения на корневые модули — их соседство на странице сомнительно. Это, конечно, имхо)

[fransua]

Согласен. Полностью изолированные бывают крайне редко.
В текущем проекте связываю модули через события в модели (неангуляровские) и дергаю $scope.$apply в обработчике. Но данный подход мне не очень нравится, поэтому не включал его в статью.
Спасибо за комментарий, становится понятно чему уделять внимание.

[Fesor]

Простите, но предложенное вами решение — тоже кастыль.

[fransua]

Смотря как его использовать. Если от случая к случаю, то да, костыль. Еще и с осложнениями (вроде $location)
Если при проектировании архитектуры разбить приложение на модули, определить между ними связи и на основе этого разрабатывать, то вполне фундаментальное решение получается.