"grid.save()" returns wrong grid representation (nested and changed column count)

[adiessl]

Subject of the issue

When using grid.save() after particular changes, the grid representation that gets returned is incorrect.

Your environment

• version of gridstack.js: 9.3.0
• which browser/OS: Windows 11, Google Chrome 117

Steps to reproduce

https://jsfiddle.net/vs81frby/

This Fiddle contains two grids, each one having two columns. The grids use the same options:

var options = {
  disableOneColumnMode: true,
  column: 2,
  row: 5,
  cellHeight: "50px",
  acceptWidgets: true,
  float: true
};

The grid on the right contains two items initially, labeled A and B. B is dragged to the left grid to position x: 1, y: 2. Item A is then resized to span the whole width of the right grid, thus having w: 2. It is then also moved to the left grid to position x: 0, y: 4. grid.save() returns x: 1, y: 2 in this case, however (the width returned is still correct: w: 2). A is then resized to be one column wide again – grid.save() incorrectly returns w: 6 now. Moving A to the top left position in the left grid should see grid.save() returning x: 0, y: 0, but it returns x: 1, y: -2.

The following GIF shows this behavior as well:

Expected behavior

x, y, w and h should reflect the real values.

This might only be a bug in the grid.save() method, as the attributes gs-x, gs-y and gs-w on the actual DOM nodes do have the correct values.

[adumesny]

looks like #2394 but that was addressed, so maybe not the correct fix then...

[adiessl]

Quick update: the problem is still present in version 9.5.0.

Another, potentially related issue (that might help in diagnosing the cause of this issue?) can be seen in the following fiddle: https://jsfiddle.net/4Lpum5f2/

The left grid has two columns, the right three. If an item spanning three columns is dragged to the grid spanning two columns, its w property still has the value 3, while its gs-w attribute has the correct value 2. When moving this item back to the grid with three columns, it spans two columns and its w property also has value 2 now.

Finally, for everyone coming across this problem, there is the following workaround: as the gs-* attributes apparently have the correct values, the saveCB callback parameter of grid.save can be used to manipulate the widgets before they get returned. As the current node is also passed in, it can be used directly to get the attribute values via node.el.

This callback is not documented here, however ...:
https://github.com/gridstack/gridstack.js/tree/master/doc#savesavecontent--true-savegridopt--false-gridstackwidget--gridstackoptions

... but it can be seen in the source code:

gridstack.js/src/gridstack.ts

Line 597 in 599965a

public save(saveContent = true, saveGridOpt = false, saveCB = GridStack.saveCB): GridStackWidget[] | GridStackOptions {

[adumesny]

my guess has to do with having higher column count for nested grid using that instead of the current column count displayed.

[waaverecords]

Solution proposed by @adiessl did the trick for me!

[frankbits]

my guess has to do with having higher column count for nested grid using that instead of the current column count displayed.

That seems to be the case, as for me the wrong width gets saved after I've resized the window.
That may make sense if the widget didn't get resized after the dashboard-resize, but if I want to make it even smaller than the smaller number of available columns, it does not get saved correctly.

It seems to be caused by using the cached value in this._layouts of GridStackEngine, that doesn't get cleared when resizing the widget manually.

The following saveCB-callback-function works for me without accessing node.el, as the width in node.w is also correct:

(node: GridStackNode, w: any) => {
	w.w = node.w;
});

[adumesny]

| caused by using the cached value in this._layouts of GridStackEngine, that doesn't get cleared when resizing the widget manually

_layouts is there to save the highest possible column layout (from which smaller layout can be calculated) by design, so if you save under 6 column, the 12 column isn't forgotten - the opposite issue would be there otherwise. the problem may be with nested grid not restoring correctly. would have to debug it. making it work in all casses is difficult. we might even need to save layouts at all shown sizes possibly, now that responsive is built in, you could have different layouts for each breakpoint.

[frankbits]

But if I have opened my dashboard in a smaller size for any reason, shouldn't i be able to for example make a widget be only one column wide?
I understand the reason for it to save the highest possible column count, but it's counter-intuitive if it just ignores any changes you make while not in all-columns-mode.

[adumesny]

edits in one size will try to propagate to the other larger sizes (with possible scale factor between column count). but it's not an exact science. short of saving for all ever displayed layouts you're not going to have a perfect solution, and even that might not what you want (should editing in 6 column also change 12 column or leave unchanged sicne techinially you can now edit and save 12 column separatedly).