At the JCrete conference last week we had some DukeScript hacking sessions, and we were was asked for best practices when you have large data sets to display in a grid. One solution is paging. If you want to load all the data at once, here’s another solution.
Let’s assume we have a model like this:
The first thing you can do in order to improve performance is to check if your table data needs to be mutable. Very often it’s an easy win to add a simple attribute to your tabular data:
This “mutable=false” will create a plain value instead of an Observable and thus save memory and construction time. It makes sense even if you want to edit the data in the table. (You would then create also a mutable version of “Row”, copy the data of the selected element to this “EditableRow”, edit it, and replace the old Row in the BigData ViewModel with an updated new one).
But the main problem with displaying large datasets is a slow UI. If you want to, for example, display a table with 100.000 rows, your DOM will get really big and this will kill performance.
One way to deal with that is to “virtualize” your table. That means the table will behave as if it actually has 100.000 rows, while it only displays the 20 rows that are currently visible. The best way to model that in DukeScript is to register a custom component like this:
A component consists of a ViewModel and a template. Our ViewModel has only four properties, the original values of our BigData object, the index of the first visible row, and the number of visible rows. The fourth is a computed property derived from the other three. It contains the values of the rows that are currently visible.
The template is loaded from an element in the page. This way we can modify the layout when we add more properties, or if we e.g. want to switch from a table to a list. Here’s a simple example:
There’s a div that wraps everything. We can set a fixed height on it. In our case it’s 100px. It contains another div that acts as a “scroll-dummy”. The only purpose of this is to make the scrollbar behave as if we have lots of elements in our table. We’ll resize it later to match the height of all rows. On top of it there’s an element that wraps the rows. It can be a list, a table, or in this case, a simple div. It uses the foreach binding to display the visible rows.
Now we need to make this dynamic. You can use a custom binding for this. It calculates how many elements are visible and listens to scroll events in order to update the firstIndex property of our components ViewModel. And it moves our “big-table-table” to the view port of our virtualized control.
As a result, you will only have DOM nodes for the nodes that are currently visible and a nice and responsive UI.
In order to make this work, you will need to register the custom binding and custom component. I’ve put them together in a file called “bigtable.js” and register them like this:
Now you only need to make sure you call the init method before you bind the data:
Enjoy coding DukeScript!