fix UI/UX: Mode switch performance from 1 sec -> instant

[dlab-anton]

Context

Switch mode performance is very bad now (1 sec per change tag) which leads to poor UX. This PR makes it instant.

I looked but can not find any reason to keep it depending on full state update since the data is already loaded for presentation. I may be missing a reason for this architectural choice so please check.

There is also an issue I noticed Settings has a Save button but "Prompts" does not, can we standardize this? I prefer save button for clarity, autosave is OK too but would need user feedback. Either way we should standardize saving behavior across all tabs.

The other thing is, are we sending full convo history because we intend to actually change the mode in conversation or is that a bug? I neither believe users have this expectation nor do they really want that to happen. It's much better for users to have good UX on the modes page than trade-off bad UX for mode change for feature which user probably do not want. But I'm making a lot of assumptions here and maybe switching Mode here was never intended to influence the chat conversation... In that case we could turn off all backend updates until the user presses the save button which would be optimal from a cursory glance.

Screenshot

Details

For this PR:

The issue occurs because the UI waits for a complete round-trip:

1. Frontend sends mode change to backend
2. Backend processes it and updates global state
3. Backend sends back a complete state object (including conversation history)
4. Frontend deserializes this large state object and only then updates the UI

Solution

Implemented an "optimistic UI update" pattern that makes mode switching feel instant:

1. Added a local visualMode state that's initialized with the global mode state
2. Updated all UI components to use visualMode instead of mode
3. Updated visualMode immediately when a mode is clicked
4. Still sent the mode change to the backend for persistence

This approach provides instant feedback to the user while maintaining proper state synchronization with the backend. The key insight is that we don't need to wait for the backend to update the UI - we can update it immediately and let the backend catch up in the background.

Implementation Details

The changes are minimal and focused on the frontend only:

• Added a visualMode state in PromptsView.tsx
• Updated all UI components to reference visualMode instead of mode
• Modified the handleModeSwitch function to update visualMode immediately

Testing

• Manually tested mode switching between all available modes
• Verified that the UI updates instantly when clicking on mode tabs
• Tested rapid mode switching to ensure no flickering occurs

Impact

This change significantly improves the user experience when switching modes in the PromptsView component. What previously took 1-2 seconds now happens instantly, making the interface go from annoying to usable.

The changes are isolated to the frontend and don't modify any backend code, making this a lower-risk improvement.

---

Important

Optimizes mode switching in PromptsView.tsx by implementing an optimistic UI update pattern using a local visualMode state.

• Behavior:
  • Implements optimistic UI updates for mode switching in PromptsView.tsx using a new local state visualMode.
  • Updates visualMode immediately on mode click, providing instant feedback.
  • Backend state update still occurs for persistence.
• Functions:
  • Modifies handleModeSwitch to update visualMode immediately.
  • Updates all mode-related UI components to use visualMode instead of mode.
• Testing:
  • Manually tested mode switching for instant UI updates and no flickering.

^{This description was created by for d57e64e. You can customize this summary. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 9a7ee33

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[adamhill]

Thanks for your detailed explanation and consideration of PR size. Hopefully this will make the approval quick.

This will make the agentic coders happy and make the Boomerang move even faster 🦘 ❤️

cc: @InElement @elianiva for the UX suggestions up top

[mrubens]

Nice, thank you! ⚡