If I understood everything correctly.
In my opinion, the logic of RadzenDataGrid Settings was created without taking into account real use cases. DataGrid, it is not intended for fixed lists. It is designed to work with dynamically changing data. This means that both the composition of the rows and the position of the current element that needs to be selected are unknown at the time of grid formation. And Settings contains the current page number. Accordingly, two errors occur: when changing the current page, the entire Settings object is written, which is redundant and makes no sense, since when restoring Settings we will not necessarily get to the current element and there may even be a different number of pages. And this redundancy of Settings write operations also makes it impossible to work normally with the settings of columns and groupings. Which require separate complex algorithms and events. It is not possible to bind this RadzenDataGrid Settings with simple code and make it work normally. We need a separate servicing object that, by brute force and comparisons, would determine which part of Settings has changed and which has not, and accordingly would call different servicing procedures.
Areas to consider:
- Remove from Settings CurrentPage property
- Page-oriented persistence can only be align first - align last, instead of the current page. What would define the behavior when opening the DataGrid. This persistence may be related to table settings.
- If persistence of the current page is needed, then this should not be the page number, but can only be the anchor of the element. But in any case, this persistence should not be tightly coupled with column settings and other DataGrid settings.
Any comments are welcome