Для полноты картины дискуссии переделал ваш пример для сложного объекта и увеличил размер массива до 3000. Теперь уже значение меняется с заметным запозданием.
Почитал ваш диалог с aav. На самом деле вы сейчас ведете разговор об архитектурных ограничениях Angular, а конкретнее, об ограничениях связанных с dirty checking, и я уверен, что и вы об этих ограничениях тоже не сразу узнали.
Вот абстрагируйтесь от Angular и поясните, почему в объекте, которую контролирует модель, вместо всех 5000 событий должно лежать только 50 текщих отображаемых? Почему, если я хочу отобразить список этих событий, я должен морочится с копирование туда/сюда 50 событий? Это имеет смысл только в контексте Angular, потому что на dirty checking 5000 событий уходит много времени. Как я писал выше, первый прототип приложения на jQuery легко пережовывал и 50 000 и 80 000 событий в этом списке, потому что список-то простой и отображаемая нода в DOM-дереве была простая. Хоть и не было там модели и контроллера. И, скорее всего, то же самое на backbone решилось бы без всяких вопросов: «А где храненить 5000 событий?».
Сейчас я тоже так могу ответить, но когда начинал работать с Angular, я этого не знал, как и многие другие, я уверен. Ведь нигде в документации не написано: «Attention! Do not place in scope over 3,000 objects»
У меня есть определенные сомнения, что в scope одновременно для каких-то задач требуется держать более такого количества элементов
Задачи бывают ооочень разные. И не нужно мне сейчас говорить, что если на странице больше 1000 элементов, то это плохой UX, знаю, слышал, но не раз видел обратное.
В случае бесконечного списка в scope его вообще лучше не держать, потому как память все равно забъет.
В моем случае, мне нужно было отобразить список событий за произвольный интервал времени. Каждое событие — это состояние удаленного контролируемого объекта. Выбор элемента списка приводил к отображению этого состояния. В день событий скапливается 25 000 ± 5 000. Получал я их с сервера пачками по 1 000. Первая реализация на jQuery позволяла без труда просметривать события за несколько дней, навигация по списку с помощью клавиатуры: Up/Down — пред/след, PageUp/PageDown — прыжок через 10 событий, End/Home — конец/начало списка. Нажал кнопку, держишь и смотришь, как меняется состояние объекта.
Angular же после третьей тысячи событий начинал тормозить, потому что весь массив событий лежал в scope. Держать его в scope было удобно, но когда начались тормоза, пришлось переносить его в сервис, а ngRepet заменять кастомной директивой, потому что он работать умеет только с тем, что лежит в scope.
Вы попробуйте свой пример с таким объектом вместо простых чисел.
Спсибо, ваш редактор очень хорош. Возникло только одно пожелание: было бы здорово, если бы на линейке отображалось местоположение мыши, например, как в фотошопе. Иногда очень выручает.
Тормоза точно из-за количества scope, потому как $digest заставляет пробежаться по всей иерархии scope, начиная с rootScope. Когда я это понял я и пытался сделать repeater без создания новых scope, просто с компиляцией шаблона, чего у меня, как я уже говорил, не вышло.
Напрямую ngRepeat рендерингом не занимается, но начиная с этой строчки ngRepeat генерирует новый $scope для каждого элемента списка, и отдает его для компиляции.
после пары-тройки тысяч записей в ng-repeat при взаимодейсвии с элементом списка весит страницу, потому что при каждом взаимодействии вызывается $digest, котоый заставляет проверять каждый забинденный элемент
Просто ng-repeat, то бишь список, — это самый сапространенный способ отобразить какой-то набор данных. И он не просто клонирует шаблон, он также производит привязку данных. Т.е., по-хорошему, к ng-repeat было бы круто добавить опцию «сделай просто рендеринг».
Смотрел я исходники ng-repeat — я же упомянул, что на основе нее хотел сделать, только не добавлять «что-то» свое, а убрать лишнее, оставив лишь рендеринг. За ваш ответ на so спасибо, подумаю, если вдруг понадобится вновь.
Другое дело куча отдельных watcher-ов на каждый {{..}} внутри ng-repeat
Именно в них дело
Только ng-repeat свой делать все же, наверное, не стоит, лучше какую-нибудь директиву
ng-repeat — это и есть директива, только встроенная в фреймворк. Я попытался сделать на ее основе что-то типа ng-static-repeat, но не хватило у меня толи времени, толи терпения. Там все в итоге все равно заваязано на $compile, который в свою очередь привязан к $scope. В итоге сделал тупо hardcoded template.
Data-binding очень ресурсоемок, особенно вкупе с ng-repeat, проверено. При всех достоинствах angular, у него есть огромный недостаток в работе с большими объемами данных, разработчики фрейморка это знают, но пока до сих пор нет какого-то более или менее пригодного решения. В итоге, каждый кто сталкивается с необходимостью обратотать большой датасет, выкручивается как может.
Возьмем, например, бесконечный скроллинг. При относительно сложном единичном объекте для отображения — со вложенными в массивы объектами, в которые вложены другие массивы с объектами — после пары-тройки тысяч записей в ng-repeat при взаимодейсвии с элементом списка весит страницу, потому что при каждом взаимодействии вызывается $digest, котоый заставляет проверять каждый забинденный элемент. Иногда нужен какой-то ng-static-repeat, который просто отображает данные, потому что эти данные не меняются.
Почитал. Ничего особого не вычитал. Мне кажется, Path нет смысла «идти по тому же пути», не покатит. Они просто идут рядышком со своей идеей. Кому-то это очень нравится. А кто-то кричит, что мало друзей, нет поиска, пабликов и лайков. Само собой чо.
А как же новомодная фишка, которую поддерживают Disqus и Livefyre, — Social Reaction? Пока что на сайтах Cackle и HyperComment о ней ни слова. А она по сути своей довольно интересна — добавление в дерево комментариев диалогов из соц.сетей, порожденных расшаренным в них комментарием.
Как странно, что вам никто до сих пор не написал в комментариях про Path. Все известные соц.сети делают ставку на открытость для окружающего мира. Path же, напротив, ориентирован лишь на ограниченный круг близких и знакомых. Единственный его недостаток — на данный момент он доступен только на мобильных телефонах, у него нет полноценной веб-версии.
Вот абстрагируйтесь от Angular и поясните, почему в объекте, которую контролирует модель, вместо всех 5000 событий должно лежать только 50 текщих отображаемых? Почему, если я хочу отобразить список этих событий, я должен морочится с копирование туда/сюда 50 событий? Это имеет смысл только в контексте Angular, потому что на dirty checking 5000 событий уходит много времени. Как я писал выше, первый прототип приложения на jQuery легко пережовывал и 50 000 и 80 000 событий в этом списке, потому что список-то простой и отображаемая нода в DOM-дереве была простая. Хоть и не было там модели и контроллера. И, скорее всего, то же самое на backbone решилось бы без всяких вопросов: «А где храненить 5000 событий?».
Сейчас я тоже так могу ответить, но когда начинал работать с Angular, я этого не знал, как и многие другие, я уверен. Ведь нигде в документации не написано: «Attention! Do not place in scope over 3,000 objects»
Задачи бывают ооочень разные. И не нужно мне сейчас говорить, что если на странице больше 1000 элементов, то это плохой UX, знаю, слышал, но не раз видел обратное.
В случае бесконечного списка в
scopeего вообще лучше не держать, потому как память все равно забъет.В моем случае, мне нужно было отобразить список событий за произвольный интервал времени. Каждое событие — это состояние удаленного контролируемого объекта. Выбор элемента списка приводил к отображению этого состояния. В день событий скапливается 25 000 ± 5 000. Получал я их с сервера пачками по 1 000. Первая реализация на jQuery позволяла без труда просметривать события за несколько дней, навигация по списку с помощью клавиатуры:
Up/Down— пред/след,PageUp/PageDown— прыжок через 10 событий,End/Home— конец/начало списка. Нажал кнопку, держишь и смотришь, как меняется состояние объекта.Одно событие имело примерно следующую структуру:
Angular же после третьей тысячи событий начинал тормозить, потому что весь массив событий лежал в scope. Держать его в
scopeбыло удобно, но когда начались тормоза, пришлось переносить его в сервис, аngRepetзаменять кастомной директивой, потому что он работать умеет только с тем, что лежит вscope.Вы попробуйте свой пример с таким объектом вместо простых чисел.
ngRepeatрендерингом не занимается, но начиная с этой строчкиngRepeatгенерирует новый$scopeдля каждого элемента списка, и отдает его для компиляции.Просто ng-repeat, то бишь список, — это самый сапространенный способ отобразить какой-то набор данных. И он не просто клонирует шаблон, он также производит привязку данных. Т.е., по-хорошему, к ng-repeat было бы круто добавить опцию «сделай просто рендеринг».
Именно в них дело
ng-repeat — это и есть директива, только встроенная в фреймворк. Я попытался сделать на ее основе что-то типа ng-static-repeat, но не хватило у меня толи времени, толи терпения. Там все в итоге все равно заваязано на $compile, который в свою очередь привязан к $scope. В итоге сделал тупо hardcoded template.
Data-binding очень ресурсоемок, особенно вкупе с ng-repeat, проверено. При всех достоинствах angular, у него есть огромный недостаток в работе с большими объемами данных, разработчики фрейморка это знают, но пока до сих пор нет какого-то более или менее пригодного решения. В итоге, каждый кто сталкивается с необходимостью обратотать большой датасет, выкручивается как может.
Возьмем, например, бесконечный скроллинг. При относительно сложном единичном объекте для отображения — со вложенными в массивы объектами, в которые вложены другие массивы с объектами — после пары-тройки тысяч записей в ng-repeat при взаимодейсвии с элементом списка весит страницу, потому что при каждом взаимодействии вызывается $digest, котоый заставляет проверять каждый забинденный элемент. Иногда нужен какой-то ng-static-repeat, который просто отображает данные, потому что эти данные не меняются.