I am trying to generate a pivot report which has thousands of records. There are more than two hundred distinct records for a dimension. So even if it is grouped by a single dimension (single value in row property in the slice object) there are more than two hundred distinct rows. It makes the UI slow. Is there any way to implement virtual scroll to avoid the performance lag.
I noticed that the virtual scroll is already implemented for drilled down that. But I need it even if the rows are not drilled down or expanded. I am using flexmonster Version 2.6.7
Thank you for writing to us.
We would like to point out that the virtualization feature is enabled by default, so there is no need to enable it manually.
In case you would like to find out more about how virtualization in Flexmonster works, please see this thread.
Our team kindly suggests migrating from 2.6 to the 2.7 major version of Flexmonster since a performance improvement has been added.
Here is our updating to the latest version tutorial for guidance.
Please let us know if this helps to solve the problem.
We are looking forward to hearing from you.
Thanks for the support. But as I mentioned the post, the virtual scroll is working for the drilled down (expanded) data, but not for the consolidated data. For example, If I am showing count of products sold, and if the number of distinct products is more than 100, all 100+ rows will be loaded in the DOM even though only 20+ rows will be visible to the user. I have attached the screenshot of the DOM elements where only 27 rows are present in the UI but all 100+ rows are loaded in the DOM(only 37 is shown the screenshot).
I think the virtual scroll is not enabled for the horizontal scroll too. This causes a huge performance issue(the UI hangs in mid range spec system) when I have more than 15+ column as HTML elements for the cells(no.of columns*27(no.of rows displayed in the UI)) are loaded in the DOM.
Thank you for your reply.
We would like to explain that the virtual scroll feature gets enabled if there are more than 500 cells.
Not enabling the virtual scroll feature when the number of cells is under 500 should in return have a good impact on the performance. This is because the browser renders such an amount of elements with ease and the HTML is not being changed.
Consider the following examples:
Please notice that both examples show reliable performance no matter if the virtual scroll is enabled or not.
You are welcome to contact us in case of further questions.
As you said, the virtual scroll is working fine in most of the cases. Please see this link where the virtual scroll is not working. I have removed the row to reproduce the issue as we were getting the issue when there’s no data. I’m not sure whether it is expected behavior.
Thank you for pointing this out to us.
The reason for this is that empty cells are not taken into account, only cells containing data are counted, therefore, the virtual scrolling feature does not get enabled for your case.
Our team has taken this into consideration and decided to enable the virtual scrolling feature if the total number of both empty cells and those containing values exceeds 500.
This will be available in the minor release version with the ETA 29th of July.
Please let us know if you have further questions.