Change Ag-Grid infinite scroll block size? - javascript

Is there a way to change the block size when the row model used is "infinite" and a datasource is set?
I.e. when the datasource's getRows() is called, is there a way to set startRow and/or endRow? Default behaviour is to fetch 100 rows at a time which results in blank rows for me, since I only have about ~12 new data rows coming in at a time with infinite scroll. So, when getRows() is triggered, it'll try to fetch rows 100 to 200 (as an example) when there are only 45 data points in the first place. To compensate it adds a bunch of blank rows.
I've tried the following two additional grid options without success:
cacheOverflowSize: 2
infiniteInitialRowCount: 32
Fetching 100 rows at a time instead of 12 solves the issue, but I'd reeeeeally rather not do this (due to some design constraints of the product I'm working on).

Shoutout to #kamil-kubicki for their comment. cacheBlockSize was indeed what I was looking for. It didn't solve my whole problem though, so I'll outline my complete solution below.
I had ag-grid's row height set to the default 25px max. That meant that on load, when it was populating the initial data, it was coming close to rendering my entire initial data set of 32 items. On scroll, getRows() would then look for rows outside of the total data collection's bounds, so it added blank rows.
I changed how many data results are loaded on each scroll to 50. This is relatively large but it works and is performant for now, so I think I'll keep it.
For those with a similar problem:
Use cacheBlockSize in gridOptions
Make sure that your ag-grid isn't rendering anything close to your full initial data collection (e.g. if your collection is 32 items, don't render anything above like 16 items - control this by changing the height of your rows and the size of your grid)
Change how many data items are loaded in to your collection on scroll to a larger number; something that can populate data faster than the user can scroll. For me it was 50. For you it might be more, or less.

Related

How Do I Make Ctrl-f Always Work in Tabulator Plus Questions on Pagination and Height?

How do you make it possible to search for any item in the table regardless of the number of rows loaded using ctrl-f?
I have a large table consisting of over 10,000 rows.
So, far I have tried using Pagination. This works regardless of how large I change the "paginationSize".
Is there a way to make the pagination controls always visible regardless of paginationSize?
Right now setting the paginationSize to certain amounts will need a scroll bar to view the pagination controls.
Also when using pagination if I include a height to the table then ctr-f cannot find everything on any page.
How does the height setting affect the number of rows loaded?
How do I figure how many rows the table will load based on the height setting?
With both of those questions in mind, how do you know how many of the loaded rows will be searchable with ctrl-f
It says in the documentation "The virtual DOM renders a number of rows above and below the visible rows to ensure a smooth scrolling experience." What determines the number of rows above and below the visible rows?
Finally is there a better way to make ctrl-f always work on the table besides using pagination?
// Creating the tabulator table
var table = new Tabulator('#themeTestCaseMetricsTable', {
height:"100%",
pagination:"local",
paginationSize:100,
layout: "fitDataFill",
cssClass: "column data",
responsiveLayout: true,
tooltips: true,
// "safe" turns off auto-escaping
columns: {{columns|safe}},
data: {{rows|safe}},
persistenceMode: "local",
persistence: {
columns: true
}
});
Appreciate any help and feedback
Ctrl+f
Tabulator uses a virtual DOM to improve render efficiency on large data sets, this means that only the visible rows actually exist, as you scroll rows are created and destroyed in realtime as they become visible. therefore you cannot search the table in that way.
The ctrl+f feature of browsers is more of a convenience feature of browser and it is bad UX to expect your users to use this to find things, if you want users to be able to search a table, you should add a search input and use the built in table Filter Functionality. you can see an example of this on the Tabulator Home Page where it lets you filter the table by the name column
That being said you can disable the virtual DOM by setting the virtualDom property to false although this will result in the table no longer scrolling and the table will take a long time to load if displaying large data sets
var table = new Tabulator("#example-table", {
virtualDom:false, //disable virtual DOM rendering
});
paginationSize
You are having this issue because you are setting both a page size and a height, if you want the table to resize to fit the height of a page of data you should not set the height. if you would like the page to take up the height of the table you should not set the page size

Performant data-tables with JavaScript

Introduction
I am making a request to a backend and getting a list of objects in JSON. Then I change it into an HTML table (it is a Vuetify data-table) where every object is a row.
Each row contains an array of exactly 72 ones and zeros ([1, 1, 1, 1, 0, ...]). They indicate activity back in time (72 hours).
In each row I have a for loop (kind of. It is Vue.js v-for directive) that goes through that array and loads an image 1.svg or 0.svg accordingly, to make a chart.
With 40 rows only, the table becomes to lag a little. Now, the table is quite wide and so it goes off screen (overflow: scroll or whatever).
TL;DR
Is it possible in JavaScript to somehow fluently hide DOM elements (in this case table cells (and rows)) (hide means remove from DOM, so that the browser doesn't have to render all of them) when they are off the screen?
Is there a literature you could recommend? Any tutorials? What to look for?
I remember seeing a Google talk on a list of thousands of elements scrolling smoothly on mobile, but can't seem to find it.
Demo
https://codepen.io/DCzajkowski/pen/yPbPqy
Hi Czajkowski Dariusz,
Yes it is certainly possible to fluidly handle large amounts of DOM nodes. The trick is to go one step past "hiding" the DOM nodes and to instead not render them at all.
A simplified view of this process could be broken into these steps:
Measure the size of the area in which you are rendering these nodes. -> RenderingHeight
Measure the size of one visible DOM node -> NodeHeight
Render only as many DOM nodes as will fit in the total plus a couple of extra which are used as a buffer -> ( RenderingHeight / NodeHeight) + 2 = NumberOfNodes
Create a subset of your data that should be populating these DOM nodes with values
When an action on the page occurs (scroll, click, etc..) update the subset of your data that should be displayed according to the action. Re-render the visible nodes with this new set of data.
Example: If your render a list of height 1000px and each list item will have a height of 100px and you have 1000 data points.
RenderingHeight = 1000px
NodeHeight = 100px
NumberOfNodes = 12
Render ten list item nodes using DataPoints[0] - DataPoints[11]. When a scroll event has moved the container down at least 100px you should update your selected subset of data to be DataPoints1 - DataPoints[12]. Then rather than delete nodes or append new ones, just update the data in the existing 12 nodes to use this new subset of data points.
This explanation is definitely a simplification of what you will end up doing in practice in your own applications but I hope it conveys the basic idea.
I believe the talk that you are thinking of might be this one from Google I/O this year: https://www.youtube.com/watch?v=mmq-KVeO-uU. Start at timestamp 15:45 to catch the example.
In this talk he uses the react-virtualized library as an example. Since you are working in Vue.js this library won't directly solve your problem but reading through the code might provide insight into how you might achieve this. I have used this library a couple of times and it has worked well for me.
A quick google search for virtualized lists in js yields some other vanilla js implementations that might also be helpful.
This is not a trivial mechanism which you are aiming to implement but it is amazingly powerful for managing performance when rendering large amounts of data.
Best of luck!
Example of Vue application with Polymer element canvas-datagrid with 5000 rows dataset.
new Vue({
el: '#app',
data: {
data: []
},
async created () {
var response = await fetch('https://jsonplaceholder.typicode.com/photos')
this.data = await response.json()
}
})
html, body, #app {
margin: 0;
padding: 0;
height: 100%;
}
<div id="app">
<canvas-datagrid>
{{ data }}
</canvas-datagrid>
</div>
<script src="https://unpkg.com/vue#2.5.3/dist/vue.min.js"></script>
<script src="https://unpkg.com/canvas-datagrid#0.18.12/dist/canvas-datagrid.js"></script>

React.js FixedDataTable - Row heights are not evaluated when table is re-rendered - scrollbar is missing

I have dynamic data in my table. The amount of data in a cell may change. I have implemented a rowHeightGetter method to calculate the height of a row. When I add content to a cell and rerender my table, the content appears and the cell is larger, but if the additional content caused overflow, scrollbars do not show up. Please see the jsfiddle and click on a row. You'll see that you can no longer access the bottom row of the table until you click a second time.
https://jsfiddle.net/3cooper/ed7Ltc6o/1/
It appears that _calculateState() is not getting the actual row heights from the rowHeightGetter methods when it calls
var scrollContentHeight = this._scrollHelper.getContentHeight()
At this point it is getting the height of the rows by checking the rowHeight property on the table. I see in _calculateState() there are other calls that eventually call this._scrollHelper._updateHeightsInViewport() to properly get the height. Should this be done again. Just really started looking into this today - so I could be missing something obvious. Thanks.
Is there a better way to handle this?
Update:
Also, I notice that once a scrollbar appears so that the contents can scroll, if you click a row again, the table with shift down but the scrollbar will not adjust. Then once you start to scroll up the scroll jumps to the correct position and allows you to scroll the entire table correctly.

How to add empty, non-selectable rows to a slickgrid?

I'm using Slickgrid to display tabular data retrieved via JSON. The number of the grid items varies greatly (approx. 1 - 50 grid rows) and the grid is reloaded often with new data during the page lifecycle.
To make my grid less "jumpy" (i.e. to avoid frequent changes of the grid height), I'd like to display the grid with a constant height of 10 rows. If the JSON resultset is less than 10 items, the grid should be filled up with empty rows. If it is more than 10 rows, I want to activate paging.
I already figured out how to fill up the grid with empty rows, however I don't want these to be selectable or editable. How can I achieve this?
Instead of loading it up with empty rows, why don't you just use a little bit of CSS?
div.slick-viewport {
height: 100px; /* or whatever 10*row_height is */
}

jqGrid - how to reset grid column widths?

If users manually resize jqGrid columns, how can you reset the column width back to whatever the original values were?
I don't believe that there are any built in methods for reseting the widths, leaving the option of recording them at creation and restoring them at a later point. Unfortunately, this functionality is the same as it was 10 months ago with column width being one of the few options that cannot be changed once the grid has been created. I even tried the newest version of the grid just to be sure (3.8.2) and it does not allow you to change the column sizes.
$('#jqGrid').getColProp(colName).width; //Properly retrieves value of column width
$('#jqGrid').setColProp(colName, {width: newWidth}); //Does nothing visually
$('#jqGrid').getColProp(colName).width; //Returns newWidth, although it doesn't show it on page
I don't know if it would be worth it, but you could try Oleg's solution here of destroying the current grid and creating a new one in its place. The practicality of this solution I suppose would be dependent upon how you are getting the data and how long it would take to re-bind the data to a new grid.

Categories