I have a grid which is bound to client side data. I use pagesize and virtual scrolling to help with performance (more content in prod). I am seeing an issue with the scroll position not adjusting when a filter is applied that results in less records.
I have a plunker showing the symptom, to reproduce:
Firstly scroll to bottom of the grid.
Then apply a filter to 2011 column of greater than 10000.
Now take notice when you scroll back up the grid, the rows are not changing.
Basically the grid has reset its data page position to the first page, but the scroll bar has not updated.
Also the same thing happens when I apply a new set of data (that has less records) to the dataSource.data() method and the scroll position is at the bottom.
12 Answers, 1 is accepted
As I have mentioned in the other thread you have written about this issue, the scrollbar is "oneway" connected with the DataSource. Thus, the scrollbar controls which data should be loaded by the DataSource, however the DataSource cannot set the scrollbar position as it is nearly impossible to predict consistently what the scrollbar position should be. However, in this particular case we will consider adding logic which to reset the scrollbar when filter is applied. This improvement will be available with the next internal build.
Thank you for considering to add this reset to the filter application. I assume the DataSource would need to inform the grid that a filter has been applied, this event is not public at present which would be a nice to have as opposed to just 'change' or 'dataBound'. May you also consider, if possible that the same reset is applied when the .data() method of the DataSource api is called with new data? I understand the DataSource would need to notify the Grid via an internal event. This would make it consistent accross both, therefore any change to the bound data would cause the scroll bar to reset.
On a side note, when virtual scrolling is not enabled all of this functionality works as expected, the scroll bar follows the data correctly, no matter if it is filtered, sorted, changed... it just works. The problems appear only when virtual scrolling and pageSize are set. If the problem is with pageSize being set, then is there another way to use virtual scrolling? I thought that would be the only way to virtualize for local data binding. The other thing to note is that I have not enabled the pager... just the pageSize.
I have observed another issue related to changing the bound data with virtual scrolling. If you scroll to the bottom (last page), then bind a new smaller set of data using the DataSource api method .data(). The scrollbar dissapears.
The issue you have described is caused by the fact that the current page index is not reset when the new data is assigned. Thus, the DataSource is still at a page which is not available anymore. You should reset the page index manually either prior or after assigning the new data.
Regarding your other question. When virtual scrolling is not enabled the scrolling is handled by the browser, thus there is no virtualization of the UI and all elements are loaded at once. The pageSize is required in order wither paging or virtual scrolling to work. As this options determines how many records to be loaded.
I previously observed that the DataSource retained it's current page index when new data is loaded. I feel that is a problem when new data is loaded and the current page index is no longer valid. If the grid fails to render correctly by losing its scrollbars, I feel that is a problem with the grid. Requiring a developer to implement a manual reset of the page index does not feel like an end solution. Sure it can be done in this case, but what about all the other consumers of the grid, they also will need to implement such logic when rebinding.
Can it be done that the page index get reset on new data load? If not that then page index be adjusted to make it valid and the grid render correctly.
I'm afraid that this behavior is intentional. Non of the DataSource state (such as filtering, grouping, sorting etc.) is refreshed when data is reset. As the developer is manually resetting the data of the DataSource, it should have the knowledge to also reset the appropriate DataSource settings for the particular scenario. This allows for maximum flexibility.
I can see why grouping, filtering and sorting should not be updated. In this case with virtual scrolling and paging, it is leaving the grid invalid. Not only on a page without content but broken because the scrollbar is removed and there is no way back to a valid state unless the developer has accounted for it. That is a major difference and I believe the grid should never be able to reach such a state.
I'll implement the proposed workaround which is to reset the page and reset the scrollbar. Only doing both will leave it in a good place for the user.
I have found it must, must, must be done before the new data is loaded. If you do it afterwards the grid looks correct, but as you try to scroll down the scrollbar disappears half way through scrolling. Which is again in my mind a defect. Try it yourself on this plunker. To test scroll to the bottom, click the button then try and scroll down again. You will see the scrollbar disappear from under your mouse cursor.
As I have mentioned in my previous reply as the developer is manipulating the DataSource via its API, it is his job to code accordingly in order to properly instruct the widget how it should behave. He has the domain and business knowledge to implement most appropriate way to handle the application scenarios. Automatically resetting the state may be appropriate in some scenario but not appropriate in others. However, once reset it will be much harder to be restored afterward. Lets have filtering for example, should assigning new data, which does not match the carefully picked by the user via the filtering menu filter descriptors, clears them out, or just let them no that there are no records in this new data that matches the defined criteria.
I am not at all suggesting that filtering, grouping or sorting be affected by this. I believe they should stay set. What I am saying is that the grid should not be able to get into a state where there is data in the grid that should be displayed (no filters) and instead it is displaying nothing and has no scrollbars. That is a defect. You can dance around it by saying the developer should fix it but that is nothing but a workaround.
Please take this back to the grid team as feedback from a paying consumer of the kendo library.
I believe this issue is related to this topic, but I have a grid with virtual scrolling, server operation is false. When I apply a filter programmatically it properly positions to the row. In this case, the grid happened to be at the top, and the row positioned to via the filter was near the bottom. It moved to it very quickly.
However, when the filter was removed manually the grid returned to the original state - which is expected and desired and I guess is the default sort order.
However the grid also became highly unresponsive. There are about 1000 rows in total so not very large. However the model is large so I did not want to load everything at once - and the customer wants to scroll - not page.
Scrolling did not work, and the page remained fixed on the first page.
What should be done to alleviate this?
Based on the provided information I made an example of a virtualized Grid with 1000 rows and many columns which is working as expected. I tested the scenario and the filter was applied and cleared almost instantly on my end:
If I missed important details, please advise and modify the example to demonstrate the real scenario.
As for the scroll position, this is expected because after the filter is applied or cleared, the scroll is returned to the top of the Grid.
In general, we have an article demonstrating how to restore the scroll position, but please have in mind that it may not work as expected with virtual scrolling due to its specific rendering:
Thanks for your reply Stepfan.
I've since determined that this issue occurs after performing a datasource.add() to the virtual grid. Which, I since have learned is not supported.
So it appeared that the grid locked after I filtered on the new account, but it was the fact the virtual grid was added to, which was causing the problem. A workaround in this case would be to refresh the grid, and then perform the filter - however I decided to not use the virtual grid for now.
In the next release the virtual grid I'm told will support adding/editing.