Hi, for an example, check out how the devxtreme datagrid uses a datasource object to manipulate the data in the grid in real time. Which means, instead of loading all the data into the grid before it is rendered at the time of declaration, the data can be appended, updated or deleted as it streams from a backend.
My issue with most grids (and charting libraries for that matter) is that the API is push based (ie they all have some kind of API like setData, etc), instead of pull based (where the grid utilizes an adapter model with simple functions like getRowCount, getColumnCount, getData(row, column) and you can build subclasses that adapt to any data model you have). This means that it's really difficult to implement highly performant grids that support changing data, more data than can fit in the current viewport, etc. It also makes it difficult to share large datasets between different views - ie a chart and table both showing the same data, or two tables showing different sections of the same dataset, without multiple copies of the data in memory.
Not 100% sure what you mean, but it sounds like a "server-side first" approach (if that word exists). As grid & chart libs are always built by (front-end) Javascript experts, you'll always see a front-end first approach.
Ah, sounds good. Do you mean the grid keeps front-end and back-end data synced? DGXL does not offer that at this moment. You could probably recreate something like it by using getData and setData methods and implement some kind of AJAX communication.
The grid itself doesn't proactively try to equalize frontend and backend data, but I utilize backend orm signals to generate websocket events which are then captured by a javascript callback in the frontend and sent to the grid. The grid then updates immediately reflecting the changes. There is no need to send the entire dataset, though, just the changes.
I don't know DevExtreme and I have to admit that I find the API Reference a little overwhelming. If I can introduce more ways to communicate between back-end and front-end, I am all for it of course.
Do you think the websocket approach for grid/tables is a common one among web devs? A link to a specific code example would help me understand the approach better.
The data source is an observable which triggers changes in the widgets that listen to it. A nice way of avoiding slow widget updates is to disable animations while making big changes to the data source. It also helps decouple UI code from business code. It even gives you the opportunity to react to widget changes such as adding a row or changing a cell without reading code directly from the widget's internal data structures or DOM.
This is a common theme among many widget providers. If you work a little bit with lazarus or delphi, you will understand throughly what I mean.
Now how common is streaming backend changes to frontend using websockets? I would say it is pretty common among the financial industry, streaming trades and quotes directly to the UI. Bloomberg, investing.com and many in-house systems that require live updates probably use this.
I see. I did spend a few months on a crypto trading platform and they had this frequent-updating table to display latest prices for each currency. DGXL really is an input-first component, so I haven't thought of this websocket approach.
Still, DGXL has methods like setCellValues, among others, that let's you update a part of the grid, not the entire grid. And it's super fast because of DGXL's virtual DOM.
