setState when structure of datatable was changed

Webix JS
#1

When I try to restore the state of the table after changing the structure, I get strange behavior.

  1. The column with “rank2” is rendered wider (probably the width corresponds to the width of the “rank” column);
  2. A non-existent column “Film title” is rendered;
  3. A column without an ID keeps its dimensions

What this is designed to do:

  1. The state of the table is saved on the server.
  2. When you update the application, the current state and the stored state should bee merged and not break the application.

https://snippet.webix.com/q07twx0y

#2

In addition, when the “headermenu” is enabled, i get an error.
https://snippet.webix.com/e5e16g7c

#3

Up.

#4

This is because you use one ID (dt1) in 2 different views datatable, try define different ID on different view.

#5

@vickypaulantono If I understand the webix concept correctly, there can’t be two views with the same ID on the page at the same time. But if you delete a view, you can create another one with the same ID.

#6

There are also problems in state restoring if hidden columns are present:

https://snippet.webix.com/7n3709p9

#7

Hi @lBeJIuk

But if you delete a view, you can create another one with the same ID

You are correct, the IDs should be unique only within the scope of existing views.
At the same time, please note that the reusable configuration objects should be always used indirectly (as [copy](copy of common helpers, Methods Webix Docs, extended config, etc.) to avoid any conflicts (the objects passed to webix.ui() or addView() will be modified during init).

Regarding the most important mentioned requirement:

When you update the application, the current state and the stored state should be merged and not break the application.

Unfortunately, there is no ready to use solution for the datatable where the columns may vary.

The state applied to the datatable should always correspond to the columns that really exist in it. The main reason is that this object stores only IDs of columns, their order and visibility, but not their full configuration.
With that said, if the state contains some extra columns or lacks some of the existing ones, it may lead to errors similar to this (the datatable can’t recognize and treat them as valid).
The headermenu relies on the same rules and may fail while gathering columns IDs and visibility state.

Perhaps the safest option is to compare and merge manually the current/stored states before applying.
To make this process more consistent, we are currently working on a neater way to add/remove columns. I must admit that there is a related bug that has an impact on this use-case and will be improved in one of the nearest releases (currently, refreshColumns() does not fully update the obtainable state).