Dojo dgrid + уведомления в WebSocket, вызывающие отключение приложения

Question

В моем приложении я использую OnDemandGrid, поддерживаемый объектом Request + Trackable dstore, для отображения моих данных пользователю.

Сервер отправляет уведомления клиенту через websocket для добавления новых записей в сетку. Для добавления новых записей в сетку, магазин непосредственно излучающий в «добавить» событие, что-то вроде следующего куска кода:

function _emitAddEvent(store, entity) { 
    store.emit('add', { 
     target: entity, 
     id: entity.id 
    }); 
} 

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

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

Answer 1

Ну, мне удалось написать обходной путь к первому выпуску. Поскольку приложение становилось невосприимчивым, потому что за короткий промежуток времени клиент получал много уведомлений, я решил добавить события в очередь и испускать их максимум один раз в секунду. dojo/throttle вместе с setInterval было достаточно для этого.

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