Fix: persist sidebar reorder on drag end#1050
Conversation
|
Caution Review failedThe pull request is closed. 📝 WalkthroughWalkthroughAdds originalIndex tracking and end handlers to project and workspace drag sources; performs optimistic in-memory reordering on hover and calls reorderProjects / reorderWorkspaces mutations on drag end when index changed, with error toasts and cache invalidation on settle. Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant UI as ProjectSection/<br/>WorkspaceListItem
participant Drag as Drag Monitor
participant Memory as In-Memory Data
participant API as reorderProjects/<br/>reorderWorkspaces
User->>Drag: Start drag (store originalIndex)
Drag->>UI: Provide drag item & monitor
UI->>Drag: Track hover position
alt Index changed while hovering
UI->>Memory: Optimistically reorder grouped data
Memory-->>UI: Update visuals
end
User->>Drag: Release (drop)
Drag->>UI: Trigger end handler
alt monitor.didDrop() is false AND index changed
UI->>API: Call reorder mutation (from originalIndex to current index)
alt Success
API-->>UI: Mutation success
UI->>Memory: Ensure persisted order / invalidate cache
else Failure
UI-->>User: Show error toast
UI->>Memory: Revert optimistic changes
end
else monitor.didDrop() true OR no index change
UI->>Memory: Discard or keep optimistic state (no server call)
end
Estimated Code Review Effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In
`@apps/desktop/src/renderer/screens/main/components/WorkspaceSidebar/ProjectSection/ProjectSection.tsx`:
- Around line 66-79: The drop handler in the drag source is not returning a
value so monitor.didDrop() stays false and the end handler in ProjectSection
(which calls reorderProjects.mutate) fires a second time; update the drop
handler for the relevant drag source to return a non-undefined result object
(e.g., { fromIndex, toIndex, handled: true }) so monitor.didDrop() will be true
and the end handler in ProjectSection (the end: (item, monitor) => { ...
reorderProjects.mutate(...) }) will skip its mutate call; ensure the returned
shape is minimal and documented where reorderProjects.mutate is invoked.
…order Return value from drop handlers so didDrop() returns true, preventing both drop and end handlers from firing mutate(). Add onSettled callback to invalidate query cache, ensuring UI syncs with server state on mutation failure.
Hi maintainers,
Summary
drop. When the mouse was released outside a registered drop target,didDropwas false, so the reorder never hit the database.endhandler when indices actually changed, while keeping the existing drop path intact.Reproduction steps
Actual result
Order changes only in UI and resets after restart.
Expected result
Order should be persisted and remain after restart.
Testing
Not run (manual drag/drop verified locally).
Thank you for reviewing!
Summary by CodeRabbit