Dojo dgrid + WebSocket notifications causing application to become unresponsive

74 views Asked by At

In my application, I'm using an OnDemandGrid, backed by a Request + Trackable dstore, to display my data to the user.

The server sends notifications to the client via websocket to add new entries to the grid. To add the new entries to the grid, the store is emiting an 'add' event, something like the following piece of code:

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

Until here, it's all good. The application receives the new entry from the server to be added to the grid, and adds it (without refreshing the grid). The problem is if there are too many notifications being sent by the server during a small time interval. The store emits all the events to the dgrid, but the grid tooks some time to render all the rows. Because there are too many entries to be added, the application goes unresponsive. If the server stops sending data to the client, after some time the application recovers and render all the rows correctly. Now comes the second (but minor) issue.

The second issue is that, after the grid renders all the new rows, it does not destroy the rows that are too far. I've set the farOffRemoval attribute, but it seems to only handle cases where a scroll happens and new data is requested to the server. I would like to know if there is a workaround, that does not rely on scroll, to destroy nodes that are too distant from the user current position on the grid.

1

There are 1 answers

0
Guilherme Fujiyoshi On BEST ANSWER

Well, I've managed to code a workaround to the first issue. Since the application was becoming unresponsive because there were a lot of notifications being received by the client in short period of time, I opted for adding the events on a queue and emit them at a maximum of one per second. dojo/throttle along with setInterval were enough for that.

The second isue, related to the farOffRemoval attribute, I wasn't able to solve. After some testing, I noticed that the browser can have a lot of DOM nodes without losing significant performance (of course, it depends on the user machine), so I just left the grid untouched.