Description
Moves should take effect in the UI immediately and be persisted in the background, rather than the
view waiting on the vault round-trip before it changes.
Today a drag-and-drop move awaits UpdateItemAsync, then a full SyncAsync() +
GetItemsAsync() reload, then rebuilds the folder tree and re-filters the list. Against bw serve
that is several hundred milliseconds during which nothing visibly happens, and the reload is what
causes #2 and #3. The user has already expressed the intent by dropping the item; the UI should
reflect it at once.
Usage Example
Drag an item onto a folder:
- The item leaves the current list and the folder counts update immediately.
- The write happens in the background; a subtle indicator shows it is in flight.
- On success, nothing further moves — the optimistic state was already correct.
- On failure, the change is rolled back visually and the error banner explains what happened.
The same applies to folder create, rename, delete and folder-to-folder moves.
Alternative
The current behaviour: block on the round-trip, then reload everything. It is correct but it feels
unresponsive, and the full reload is what discards tree state (#2) and appears not to refresh the
list (#3).
Notes
This mostly subsumes #2 and #3 — an optimistic update mutates the existing view-model objects
instead of rebuilding the tree, so expansion state survives by construction and the list updates
because the item's own FolderId changed.
One thing to get right: optimism must not extend to the outcome. The merge path deliberately
writes, verifies, and only then deletes, and none of that should be short-circuited. This is about
moves, which are a single reversible field change on one item — not about anything that deletes.
Worth pairing with in-place tree reconciliation so a background refresh can land without
disturbing what the user is looking at.
Description
Moves should take effect in the UI immediately and be persisted in the background, rather than the
view waiting on the vault round-trip before it changes.
Today a drag-and-drop move awaits
UpdateItemAsync, then a fullSyncAsync()+GetItemsAsync()reload, then rebuilds the folder tree and re-filters the list. Againstbw servethat is several hundred milliseconds during which nothing visibly happens, and the reload is what
causes #2 and #3. The user has already expressed the intent by dropping the item; the UI should
reflect it at once.
Usage Example
Drag an item onto a folder:
The same applies to folder create, rename, delete and folder-to-folder moves.
Alternative
The current behaviour: block on the round-trip, then reload everything. It is correct but it feels
unresponsive, and the full reload is what discards tree state (#2) and appears not to refresh the
list (#3).
Notes
This mostly subsumes #2 and #3 — an optimistic update mutates the existing view-model objects
instead of rebuilding the tree, so expansion state survives by construction and the list updates
because the item's own
FolderIdchanged.One thing to get right: optimism must not extend to the outcome. The merge path deliberately
writes, verifies, and only then deletes, and none of that should be short-circuited. This is about
moves, which are a single reversible field change on one item — not about anything that deletes.
Worth pairing with in-place tree reconciliation so a background refresh can land without
disturbing what the user is looking at.