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

17

Мы разрабатываем магистральное приложение, в котором каждая серверная коллекция может содержать десятки тысяч записей. Как аналогия - подумайте о переходе к представлению «Отправленные» в приложении электронной почты.

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

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

  • Сталкивались ли вы с проблемами производительности (особенно на мобильных устройствах) при определенном размере коллекции?
  • Какое решение (ы) вы приняли, сколько нужно извлечь с сервера?
  • Вы загружаете все или только подмножество?
  • Где вы размещаете логику вокруг какого-либо специального механизма (например, прототипа Collection)
задан isNaN1247 27.09.2011 в 11:12
источник

2 ответа

11
  1. Да, при количестве элементов около 10000 старые браузеры не могли хорошо обрабатывать отображение. Мы думали, что это проблема пропускной способности, но даже локально, с такой пропускной способностью, которую может создать высокопроизводительная машина, Javascript просто потерял сознание. Это было верно для Firefox 2 и IE7; С тех пор я не тестировал его на более крупных системах.

  2. Мы пытались получить все . Это не сработало для больших наборов данных. Это было особенно пагубно для браузера Android.

  3. Наши данные были в древовидной структуре, а другие данные зависели от наличия данных в древовидной структуре. Данные могут измениться из-за действий других пользователей или других частей программы. В конце концов, мы заставили древовидную структуру извлекать только видимые в данный момент узлы, а другие части системы проверяли достоверность наборов данных, от которых они зависят независимо. Это условие гонки, но в реальном развертывании мы никогда не видели никаких проблем. Я бы хотел использовать socket.io здесь, но руководство не понимало и не доверяло ему.

  4. Поскольку я использую Coffeescript, я просто унаследовал от Backbone.Collection и создал свой собственный суперкласс, который также создал пользовательский вызов sync() . Синтаксис для вызова метода суперкласса здесь действительно полезен:

    class Dataset extends BaseAccessClass
        initialize: (attributes, options) ->
            Dataset.__super__.initialize.apply(@, arguments)
            # Customizations go here.
    
ответ дан Elf Sternberg 27.09.2011 в 18:36
  • Спасибо за это, очень полезно –  isNaN1247 29.09.2011 в 20:45
2

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

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

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

Я создаю PerfView for Backbone, который может отображать 1 000 000 моделей и прокручивать их со скоростью 120 FPS в Chrome. Весь код находится на Github Ссылка . Он прокомментирован, поэтому есть много других оптимизаций, которые вам понадобятся для отображения больших наборов данных.

    
ответ дан puppybits 22.10.2013 в 06:18