Работа с большими коллекциями Backbone

Мы разрабатываем базовое приложение, в котором каждый серверный сборник может содержать десятки тысяч записей. В качестве аналогии - подумайте о том, как войти в представление "Отправленные" приложения электронной почты.

В большинстве примеров Backbone, которые я видел, в собраниях участвуют не более 100-200 записей, и поэтому получение всей коллекции и работа с ней в клиенте относительно просто. Я не верю, что это будет иметь место с гораздо большим набором.

Кто-нибудь выполнял какую-либо работу с Backbone на больших коллекциях на стороне сервера?

У вас возникли проблемы с производительностью (особенно на мобильных устройствах) с определенным размером коллекции?
Какое решение вы взяли на себя, сколько нужно получить от сервера?
Вы загружаете все или только подмножество?
Где вы помещаете логику в любой пользовательский механизм (например, прототип коллекции?)

Ответ 1

Да, около 10 000 элементов, старые браузеры плохо справляются с отображением. Мы думали, что это проблема с пропускной способностью, но даже локально, с такой же пропускной способностью, как высокопроизводительная машина, можно было бы на нее наброситься, Javascript просто потерял сознание. Это было верно для Firefox 2 и IE7; Я не тестировал его на более крупных системах с тех пор.
Мы пытались забрать все. Это не сработало для больших наборов данных. Это было особенно вредно для Android-браузера.
Наши данные были в древовидной структуре, а другие данные зависели от наличия данных в древовидной структуре. Данные могут измениться из-за действий других пользователей или других частей программы. В конце концов, мы сделали древовидную структуру выборкой только видимых в настоящее время узлов, а другие части системы проверили достоверность наборов данных, на которых они зависят независимо. Это состояние гонки, но при фактическом развертывании мы никогда не видели никаких проблем. Мне бы хотелось использовать socket.io здесь, но руководство не понимало и не доверяло ему.
Так как я использую Coffeescript, я просто унаследовал от Backbone.Collection и создал свой собственный суперкласс, который также создал экземпляр sync(). Синтаксис для вызова метода суперкласса действительно полезен здесь:
```
class Dataset extends BaseAccessClass
    initialize: (attributes, options) ->
        Dataset.__super__.initialize.apply(@, arguments)
        # Customizations go here.
```

Ответ 2

Как и Эльф сказал, что вы должны действительно разбивать на страницы данные загрузки с сервера. Вы сохранили бы большую нагрузку на сервере от загрузки элементов, которые вам могут не понадобиться. Просто создайте коллекцию с 10k-моделями локально в Chrome, займите полсекунды. Это огромная нагрузка.

Вы можете поместить работу в другой физический поток ЦП с помощью рабочего, а затем использовать переходные объекты, чтобы отправить его в основной поток, чтобы отобразить его на DOM.

Как только у вас будет коллекция, большая рендеринг в ленивом рендеринге DOM будет только доведена до вас. Память будет медленно увеличиваться, пока она не выйдет из строя в браузере (это будет быстро на планшетах). Вы должны использовать объединение объектов по элементам. Это позволит вам установить небольшой максимальный размер для памяти и сохранить его там.

Я создаю PerfView для Backbone, который может отображать 1,000,000 моделей и прокручивать 120FPS в Chrome. Код находится на Github https://github.com/puppybits/BackboneJS-PerfView. Он прокомментировал так, что у вас много других оптимизаций, которые вам нужны для отображения больших наборов данных.