Task: Concept: Provide immediate feedback for user actions

[andreaskienle]

Problem

Right now, when users perform a mutating action (e.g. create/delete a project, workspace, or MCP), we only show a toast like “Project creation triggered. The list will refresh automatically once completed.” Then we wait for the next polling cycle to update the UI. This creates a poor user experience.

The following discussion uses the “delete project” flow to illustrate the improvements. The same approach applies to other actions.

Current flow when deleting a project

• We send a delete request to the server.
• We show a toast saying the change is in progress and the UI will update later via polling. (For deleting projects we actually don’t show this, but we do for other resources.)
• Meanwhile (even if the user refreshes the page manually via the browser) the project still appears in the list while deletion is happening in the background.
• On the server, the project moves through states (e.g., it gets a deletion timestamp first, and only later is fully removed).
• Eventually, the project also disappears from the UI.

Ideal behavior (from the user’s perspective) when deleting a project

• The user clicks delete.
• We immediately show the project as “being deleted” via an optimistic update (e.g. show a spinner/loading state, disable navigation, grey out the item, …)
• We immediately refetch from the server so fast operations complete “instantly” in the UI.
• Longer operations continue to show as “being deleted” until polling picks up the final state.

What we need to implement

1. UI can represent transition states: If a project has a deletion timestamp, show it as “being deleted” (spinner, disabled navigation, greyed out, etc.). (related backlog item: Improve Workspace creation experience #220)
2. Optimistic updates on mutate: When a delete is triggered, optimistically update the SWR cache to a transition state (e.g. set deletion timestamp to “now”).
3. Invalidate the SWR cache right away to fetch fresh data. The server response will replace the optimistic state (either still deleting or already gone), and the UI re-renders accordingly.
4. Direct navigation handling: If a user opens a resource that’s in an unusable transition state (e.g. via bookmark), the UI should detect this and show an appropriate state (e.g. “being deleted,” disabled actions).

Suggested approach

• Steps (2) and possibly (3) might not be so easy with our current SWR implementation (only 1 mutation hook for all resources). Since we plan to move to GraphQL soon (which will replace SWR), we may skip these for now.
• Steps (1) and (4) are valuable regardless and can be implemented now.
• Unfortunately only with (2) the feedback will be immediate, so we might still have a toast.

Alternatives

We can also think about filtering out projects with a deletion timestamp. Depends on how transparent we want to be with what’s going on behind the scenes.