#Server data

Ways to get rows from a backend into the grid, besides setData():

WebSocket and Server-Sent Events are alternatives to fetch, not replacements. They need sorla-db 1.7.1 or later.

#Server-Sent Events: loading in blocks

⧉const stream = grid.loadStream('/api/orders/stream', {
    headers: { Authorization: `Bearer ${token}` },
    onProgress: ({ loaded, total }) => (bar.value = total ? loaded / total : 0)
});
const state = await stream.done;   // { loaded, total, blocks, errors, ... }
stream.close();                    // stops early

The server sends the rows in named events (the sorla-db stream protocol):

⧉event: meta
data: {"total": 100000}

id: 1
event: rows
data: [{"id": 1, ...}, ... 5000 rows ...]

event: end
data: {}

• Rows show up as each block arrives; the user can scroll, sort and filter while it loads. Sorting and filters are applied again a few times per second and once more at the end.
• The status bar shows "Loading 20,000 of 100,000 rows…".
• After a dropped connection the client reconnects with Last-Event-ID, so the server can continue with the next block. A row sent twice updates the row instead of duplicating it.
• delete events ([ids]) remove rows. ops events are not supported by the grid.
• replace: false adds to the current rows instead of replacing them.
• Rows from the stream are not unsaved changes and cannot be undone.
• Options: transport ('fetch', default, or 'eventsource'), headers, method, body, credentials, withCredentials, retry, maxRetries, lastEventId, onProgress, onError.

Events: streamEnd (the final state) and streamError ({ error }).

A Node example of the endpoint is in scripts/demo-api.ts (/api/orders/stream): it waits for drain when the browser reads slower than the server writes.

#applyServerChanges

⧉grid.applyServerChanges({ rows: [{ id: 7, qty: 3 }, { id: 9001, name: 'New', qty: 1 }] });
grid.applyServerChanges({ type: 'delete', ids: [12, 13] });
// → { inserted: ['9001'], updated: ['7'], removed: ['12', '13'] }

• A row whose id exists is updated with the fields it has; the others are added.
• Server changes are not unsaved changes (change tracking) and cannot be undone.
• A field the user changed and did not save keeps the user's value. The other fields of that row follow the server, and the server values become their originals, so they are not reported as changes of the user.
• Calculated columns are recalculated; new rows follow the local sort and filters.
• Emits serverChange with the same result.

#Try it

npm run demo starts a backend with 100 000 orders kept in a sorla-db collection on the server:

Edit this page on GitHub