Progress® Telerik® UI for Blazor Feedback Portal
Back to Feed
Request a Feature Report a Bug
Declined
Last Updated: 08 Oct 2021 11:54 by ADMIN
Scott
Created on: 30 Sep 2021 16:04
Category: Grid
Type: Feature Request
5
GridState Restore After Columns Change

If a developer changes the structure of the grid in a new release, such as adding or removing columns, the restore can have very unexpected results.

We get around this by storing a version number with the grid and incrementing that number when we change the grid columns.  If the version number on the grid does not match the version number stored with the state, we don't restore it.

We would like to see this be more of an automatic feature of the grid.

Compare the columns in the saved state with the columns in the Grid declaration. You may need to change the way the Grid columns are declared, according to the the linked documentation. If there is inconsistency between the two collections, strip the column information from the saved state before restoring it.  (This was suggested by Dimo from Telerik in a support ticket)

An alternative would just be to throw away that state when it can't be safely restored.

4 comments
ADMIN
Dimo
Posted on: 08 Oct 2021 11:54

Hi Michal,

I appreciate the detailed response, thanks. It surely sounds reasonable and we are pretty much aware of the logic you presented. Still, the developers have concerns about this approach. Nevertheless, I asked them to revisit the topic and will update this thread with any new information afterwards.

Regards,
Dimo
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.

Michal
Posted on: 07 Oct 2021 14:33

Hello and thank You for info,

 but currently, grid state is maintained by ORDINAL POSITION againts the razor field declarations(am i correct?).
From the reusable perspective, gridstate-stored column definition is lacking "UniqueID", this is my analysis. 
<GridColumn Id="A"... FieldName="CanBeAnyDoubled" />
<GridColumn Id="B"... FieldName="CanBeAnyDoubled" />
<GridColumn Id="C"...FieldName="C"/>

Take a look at your previous RadGrid product HOW IT SHOULD work as the base point of usability- this applies to the most functionality of grid component. Not to mention if you want to stack/build the grid colums dynamically(all columns generated by the USER datasource/query = standard "data driven" information systems)

imagine sql interpretation:
SELECT 1 as A,55 as B,'txt' as C
againts
SELECT 55 as B,1 as A,'txt' as C
= correct, no problem with visual mapping(column "A" is still presented at the first position of the grid)

your current column identifiacion is like:
SELECT 1 as [0],55 as [1],'txt' as [2]
againts
SELECT 55 as [0],1 as [1],'txt' as [2]
= fail, mixed (column "A" acts with definition of "B")

GridState stored definition looks:

{"Index":0,"Width":null,"Visible":null,"Locked":false},
{"Index":1,"Width":null,"Visible":null,"Locked":false},
{"Index":2,"Width":null,"Visible":null,"Locked":false}...


"Index" is not enought to identify about which colum are we getting the state.
It should be at least Solution 1:

{"Id":C "Width":null,"Visible":null,"Locked":false},
{"Id":A,"Width":null,"Visible":null,"Locked":false},
{"Id":B,"Width":null,"Visible":null,"Locked":false},

Maxed version(but more complicated to code on your side) Solution 2:
{"Id":A, VisibleIndex:2, "Width":null,"Visible":null,"Locked":false},
{"Id":C, VisibleIndex:0,"Width":null,"Visible":null,"Locked":false},
{"Id":B, VisibleIndex:1"Width":null,"Visible":null,"Locked":false},


- This update "index" vs "unique column name" eliminates more of the REAL SCENARIO problems,
* add NEW column(in razor defintion) to the begining or anywhere.
* delete existing column(in razor defintion).
* reorder anything(in razor defintion).
* RENAME column ID = same as "delete+add"
- If definition by Id is not found in the stored gridstate, its not a problem to put the column at the "end of the grid", but again: do not overwrite any existing column state-definition by [index].

Maybe iam missed something, but cant get clue how to get it maintenable, EXCEPT scenario, wher you are forced to(razor):
* DO NOT REORDER columns
* ADD only at the END
* DO NOT REMOVE from the BEGING

ADMIN
Dimo
Posted on: 07 Oct 2021 13:16

Hi all,

We discussed this feature request in the team and I am afraid I have bad news.

There is no straight-forward, reliable and universal mechanism to map saved settings with the current columns in all scenarios. It is also difficult to evaluate if the saved settings still make sense even if a given column still appears to exist. For example, imagine a scenario where the developer adds, removes or changes the template of a column and its saved state is no longer adequate.

That is why our recommendation is to handle this case-by-case. For example:

  • change the local storage key when making "breaking changes" to the Grid declaration;
  • make the backend code automatically aware when the application was updated and restore the saved state only partially

Regards,
Dimo
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Michal
Posted on: 03 Oct 2021 09:55
Agree.
Restoring state also fails, when you just REORDER columns in razor declaration. Becaous gridstate is stored as "possition", not by FieldName/UniqueColumnName
Lets have 3 columns in grid:
- A,B,C
- save the grid state

add new one D:
- A,B,D,C
load the saved grid state
Create an account Log In
View
Type
Status
Category