setState when structure of datatable was changed

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
https://imgur.com/a/CYWx4q0

Comments

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

    https://imgur.com/a/2y4eh2R

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

  • @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.

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

    https://snippet.webix.com/7n3709p9
    https://imgur.com/a/ltkVWMz

  • 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](https://docs.webix.com/api___copy.html, 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).

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!