Dashboard bug on serialize => restore

Webix JS
#1

The problem is that the dashboard serialization is not ordered to be from top to down, which means the fields mix up depending on which order they are stored, because the factory is adding one by one, so if there is a “hole” in the dashboard, the new widget will “jump higher” and then get pushed away with the original widget at this place. We had big troubles here till i now do:

state.sort(function(a,b){
  return ((a.y * 100) + a.x) - ((b.y * 100) + b.x)
});

with the dashboard state before I give it to restore(). This should be fixed in the core code. (Although i am not using total recent webix pro 6.3.6, so sorry if it is already fixed)

#2

Hey @Getty, this is actually the intended behaviour by default. Even without performing a restore you can try and make an empty row at the top, and the panels will get autoadjusted to fill the empty space. This is happening because of the autoplace property, which is set to true by default.

You can disable that behaviour and the restore functionality will work properly for you: https://snippet.webix.com/mh7t6w4b.

#3

No no no, you talk about the case of adding one by one, but i talk about if its already there. Please see my bug correction to understand the error in your system. If you have the wrong order in the serialized state then you will NOT get back the same state again, cause the order will rearrange them. We do NOT talk about NORMAL adding behavior, we talk about behavior happening WHILE we restore a fixed list of state.

This autoplace feature might make sense for regular adding behavior, but how does that make any sense on restore? I have a specific state in hand and why it should be modified when I add it? No matter if i use autoplace or not.

The biggest joke for me now is the fact that there is no way you can define the order of the elements, so everyone has a TOTAL RANDOM behavior on restore with that, that can’t be a serious planned feature set.

#4

Yes, I am talking about restore here. Please try this snippet: https://snippet.webix.com/8aqyem9a.

Save your state with autoplace: false and then change it to true and try to restore the state (the placement will be off).

#5

And this still makes no sense. So you tell me, to actually use restore at all, i have to deactivate autoplace before every restore and reactivate afterwards?

If what you say is officially how this all should go, then this means that no one with autoplace: true can actually use the serialize/restore function without risking breaking this complete layout. Why? This makes no sense. Especially it makes no sense when the fix to it is kinda ultra trivial and there is no possible positive use case of the current (broken) situation, there is no drawback to removing the crazy behavior. There is no case where you want that your layout is suddenly different after restore than it was on serialize.

#6

Wow, without autoplace it is even worst, cause it expect me to actually set the amount of rows that we have.