Manually Saving Layouts
Summary
- By default Layouts persist immediately whenever they change
- Developers can suppress that auto-save and persist Layouts only when they choose
- Unsaved Layout changes can be discarded when the user switches to another Layout
Layouts, like all AdapTable objects, save automatically as soon as they are changed.
Whenever a Column is grouped, resized, pinned etc, the change is immediately persisted to AdapTable State.
Sometimes this is not desired behaviour, and developers prefer to manually control when a Layout is saved.
In other words, run-time users can only make temporary changes to Layouts, and the actual state persistence is imperatively driven.
This is possible in AdapTable as the demo below demonstrates.
Suppressing Auto-Save
The persistState function in State Options is used to write a snapshot of last-saved Layouts instead of the running Layout State.
Other AdapTable objects (e.g. Format Columns) continue to persist automatically.
Developers can then persist Layouts on demand:
- Persist ALL Layout Changes - save every Layout in the running State
- Persist CURRENT Layout Changes - merge only the Current Layout into the snapshot
Discarding Unsaved Changes
A common requirement is that unsaved edits are lost when the user leaves a Layout.
For example:
- "First Layout" has columns
A, B, C - The user reorders them to
C, B, A - The user clones it as "Second Layout" (which keeps
C, B, A) - Switching back to "First Layout" shows
A, B, Cagain
This is implemented by listening to the Layout Changed Event and, on a LAYOUT_SELECT, restoring the abandoned Layout from the last persisted snapshot via createOrUpdateLayout in Layout API.
If the abandoned Layout is not in the snapshot (e.g. a freshly cloned Layout), it is left as-is.
Note
- This demo is a cut down version from examples provided in the Guide to Controlling AdapTable State Persistence
- See the demos there for full explanations and in-depth details of this advanced topic
- This pattern only works with a custom
persistStatehook - in a default setup there is no "last saved" Layout to roll back to
- In this demo we prevent the auto-saving of Layouts
- Changes to Layouts stay local until they are explicitly persisted; we keep a snapshot of last-saved Layouts and provide 4 Dashboard Buttons:
Persist ALL Layout Changes- manually saves every Layout to AdapTable StatePersist CURRENT Layout Changes- manually saves only the Current LayoutUndo Layout Changes- replaces any locally saved changes to Layouts with the last saved version in AdapTable StateReset Layout Changes- replaces any locally saved changes to Layouts with the initial version in AdapTable State
- Switching away from a Layout discards its unsaved changes (the Layout is restored from the last persisted snapshot). A freshly cloned Layout is left as-is because it is not yet in that snapshot
- Note: only Layouts are not auto-saved - changes to other objects (e.g. changing the back colour of the Format Column on the
Github StarsColumn) are automatically persisted