Repository navigation
"grid.save()" returns wrong grid representation (nested and changed column count) #2493
Description
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.
Activity
adumesny commentedon Oct 5, 2023
looks like #2394 but that was addressed, so maybe not the correct fix then...
adiessl commentedon Oct 31, 2023
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
wproperty still has the value3, while itsgs-wattribute has the correct value2. When moving this item back to the grid with three columns, it spans two columns and itswproperty also has value2now.Finally, for everyone coming across this problem, there is the following workaround: as the
gs-*attributes apparently have the correct values, thesaveCBcallback parameter ofgrid.savecan be used to manipulate the widgets before they get returned. As the currentnodeis also passed in, it can be used directly to get the attribute values vianode.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
[-]"grid.save()" returns wrong grid representation[/-][+]"grid.save()" returns wrong grid representation (nested and changed column count)[/+]adumesny commentedon Mar 30, 2024
my guess has to do with having higher column count for nested grid using that instead of the current column count displayed.
waaverecords commentedon Jun 19, 2024
Solution proposed by @adiessl did the trick for me!
frankbits commentedon Jun 20, 2024
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._layoutsofGridStackEngine, that doesn't get cleared when resizing the widget manually.The following
saveCB-callback-function works for me without accessingnode.el, as the width innode.wis also correct:adumesny commentedon Jun 20, 2024
| caused by using the cached value in this._layouts of GridStackEngine, that doesn't get cleared when resizing the widget manually
_layoutsis 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 commentedon Jun 20, 2024
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 commentedon Jun 21, 2024
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 since technically you could edit and save 12 column separatedly).
jolo-dev commentedon Sep 13, 2024
I also had this issue and this helped.
mahdiabderraouf commentedon Jun 11, 2025
For anyone having the problem, this worked for me:
grid.engine.nodessave() now takes optional column count
adumesny commentedon Aug 12, 2025
should be fixed in 12.3.1 - limited testing but ran into issue while debugging that was related. Adding 'column' option to save.
grid.save(false,false,null, this.column())will save the displayed layout, whatever that responsive column count happens to be. not passing column count will save the largest layout, but force nested grid to match that parent layout to match.don't forget to donate if you find this lib useful!
tweaks on save() takking column option