UVE Layout: add a persistent save-state indicator (Unsaved / Saving / Saved / Failed + retry)
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 970
- Forks
- 486
- Avg merge
- 3d 33m
- Merged PRs (30d)
- 170
Description
Problem Statement
Split out of #36197, which had two halves:
- The data-loss race — the Layout canvas was never locked during a save. Fixed and QA-verified (PRs #37244 + #37480).
- The save-state feedback / trust half — this issue. Not implemented anywhere, and not tracked by any other issue.
On the UVE Layout tab, save state is still communicated only by short-lived toasts ("Saving...", "All changes Saved"), and there is no indication at all during the 5s auto-save debounce window — the interval where the user has unsaved changes. This is the originally reported "they wait and nothing happens" symptom: on a slow or unreliable connection the editor cannot tell whether their layout work has been persisted.
This is a trust/observability problem, not a data-integrity one — the canvas lock now prevents the actual loss.
Current behavior (QA-verified on main @ f95c6bf90b)
- During the 5s debounce (changes made, not yet sent): a DOM scan of the layout UI for any save-state text returns empty. No signal whatsoever.
- During the save: transient toast "Saving...", inside
p-toast. - After success: transient toast "All changes Saved". No timestamp, nothing persistent once it auto-dismisses.
- On failure (verified by forcing the layout
POSTto HTTP 500): local edits are correctly preserved and the canvas unlocks, but there is no persistentFailedstate and no retry affordance — only a transient error toast.
Acceptance Criteria
Carried over verbatim from #36197, where they were in scope but intentionally not addressed by PR #37480:
- The Layout tab shows a persistent save-state indicator with distinct states:
Unsaved changes→Saving…→Saved (timestamp)→Failed. It does not auto-dismiss while a save is pending. - On save failure, the indicator shows a
Failedstate with a retry affordance, and local edits are not discarded (the user does not lose work and is not misled into thinking the save succeeded).
Note the first criterion covers the debounce window too — "Unsaved changes" should appear as soon as an edit is made, not only once the POST is sent.
Notes
- Not covered by #36165. That issue adds a feature flag to switch the Layout tab to an explicit manual Save. Even with an explicit Save action, the editor still needs to know the current save state — these are complementary, not duplicates. If #36165 lands first, this indicator should reflect both modes.
- The lock/spinner from #37244 is a save-in-progress affordance only; it is absent during the debounce window and gone after the save settles, so it does not satisfy these criteria.
Severity
Medium — no data loss (that half is fixed), but editors on slow networks cannot confirm their work persisted.
Split from #36197.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the UVE Layout tab's existing save flow, including the 5s auto-save debounce and transient toast states, and trace how the layout POST reports success or failure. Done means the tab persistently shows Unsaved changes, Saving, Saved with a timestamp, or Failed with retry, while preserving edits after failure.
Written by the indexing model from the issue text.
Assessment
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 50/100