Hi Srihari,

I will go straight to the questions.

1) Yes, we are listening the scroll event. Based on the scroll position and the cells visibility within the Grid content area we perform our virtualization logic. With 2.29 release our source code is shipped to our customers, so if it is interesting for you you could further look into the actual code.

2) We further evaluated the feature request for adding debounce delay for the scroll event. By default, we use 180ms debounce delay of the scroll. It needs additional research, but we might be able to expose a public configuration parameter for it. Currently, our code base rely on this delay and we need to thoroughly test what values of this delay would be reasonable. Thus, I am moving the status of this item to unplanned, but have in mind that we will release this feature only if the research is successful and we can deliver good quality with it. 

Regarding, the amount of visible columns I am adding it in the description of this request to be considered. However, I think that if we are able to expose the delay this configuration will be redundant.

Regards,
Joana
Progress Telerik

Hi,

Thank you for the clarifications.

I have done two things:

• update the title of this page to reflect its actual purpose
• marked it as "declined" because this is not how the feature is supposed to work

First and foremost, column virtualization is a UI rendering optimization technique, not a data loading optimization technique. It expects that you have all the fields in the model from the start (say, all the 100 fields in the provided scenario). There is no event when the user scrolls, and so no suitable event for additional data loading/processing.

The optimization this feature brings is related to how much and how fast Blazor can render many DOM elements and strives to optimize this by only rendering a small subset of the columns. In the provided example, let's assume the default page size of 10 - with 100 columns there would be 100 <td> elements by default, while with virtualized columns only 100 of those would render. This would speed up any operation such as paging, filtering, grouping and so on because the framework would have to do 10 times less work. The data for all 100 columns needs to be available, however, the grid will query the model when it has to render the cells.

I hope this explains the situation and why any delays are not a feature that can fit in the current model of the column virtualization feature.

Regards,
Marin Bratanov
Progress Telerik

Hi Srihari,

As a follow-up to my previous answer, I would like to share that we already have a public item for the described feature on our Public Feedback Portal:

Add Debounce property for grid filtering

That said, I will hereby mark this thread as "Duplicated" to the older one linked above. I also added a vote to it on your behalf to increase its popularity as we are prioritizing the feature requests implementation based on the community interest and demand. You can subscribe to the older item to receive email notifications when its status changes.

Thank you for your understanding.

Regards,
Hristian Stefanov
Progress Telerik

Hi Srihari,

Thank you for raising a question about such a feature.

I'm marking this public item as "Unplanned". This means that this is a valid feature request with no scheduled date for implementation yet. Since you are the creator of this request, you are automatically subscribed to receive email notifications on status updates.

A possible alternate is coming with the following feature request in our 2.29.0 release, mid-November:

Make source code available to paid license holders

With the source code available, you will be able to implement the desired result on your own.

If you have any other questions, I would be glad to help.

Regards,
Hristian Stefanov
Progress Telerik