CodeAccordion consolidations, editor UI breakout for diffs/fragments.

[sachasayan]

Context

Need: As a user, I want verbose outputs to be broken out of the chat stream so I can analyze them in more detail.

Need: As a user, I want the chat feed to have less visual clutter so I can better understand what the agent is doing.

As Roo becomes more agentic and outputs larger volumes of code (diffs, edits, reads, etc.) it becomes more important to understand what it is doing at a high level and less important for granular details to make it to the chat stream — however, these artifacts (or details) should still remain accessible to the user for closer inspection when necessary. Roo does this a bit already, but implementations vary right now — some outputs are presented as accordions, some are presented in-line, and some are presented as previews in new tabs.

This PR addresses these needs by starting a transitional sunset of the CodeAccordion component — if a code change is voluminous enough that it needs to have a mechanism for hiding it, then we don't need it in the stream at all — instead, we can prepare a preview of it in a new tab if the user needs to take a look.

Note: While this PR is in draft, basic colouring has been added to all forms of output from the user/llm to implicitly categorize them. My expectation/goal is to refine this coloring before merge — no visual work has been done yet. Right now, it's all just architectural movement, capturing all the cases, etc.

TODO

✅ Transitional state: Replace 'verbose' CodeAccordions with ViewOutputBlocks
✅ Consolidate all verbose output variants of into ViewOutputBlocks or ViewOutputBlock variants.
✅ Refine previewing function.
✅ Convert all styling to Tailwind.
✅ Refine styling.
✅ Confirm/fix tests.
✅ Build translations.

Screenshots

---

Important

Consolidates verbose outputs using ViewOutputBlock, introduces content providers for API requests and tool outputs, and updates i18n files.

• Behavior:
  • Replaces CodeAccordion with ViewOutputBlock for verbose outputs in ChatRow.tsx and MarkdownBlock.tsx.
  • Introduces ApiRequestContentProvider and ToolOutputContentProvider in extension.ts for handling API requests and tool outputs.
  • Adds new message types showApiRequestDetails and showToolOutput in webviewMessageHandler.ts.
• Components:
  • Adds ApiRequestDetailsBlock.tsx for displaying API request details.
  • Adds ViewOutputBlock.tsx for handling large code outputs.
• Mocks:
  • Adds mock for execa in src/__mocks__/execa.js and updates jest.config.js.
• i18n:
  • Updates translation files for multiple languages to include new strings related to viewing outputs and API requests.

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

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6a89cc7

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

[sachasayan]

New interim styling. We'll need a separate PR to fix spacing and introduce timeline-like formatting. I don't want this one to get too ambitious.

[sachasayan]

@cte This shouldn't have any adverse conflicts with #3019, I think, but I want to check with you — I'm taking this in a totally different direction where large code blocks are pulled out of the chat stream and into the editor.

[ellipsis-dev]

Duplicate key detected: 'directoryOperations' is defined more than once in the JSON file. Please merge the two definitions into one to avoid unexpected behavior.

[ellipsis-dev]

This pull request is quite large, with changes spanning across multiple components, including localization updates, new features, and refactoring. To make the review process more manageable, it would be beneficial to split the localization updates into a separate pull request from the feature additions and refactoring. This will help reviewers focus on each aspect more effectively and ensure a smoother integration process. Thank you for your understanding and cooperation!

[sachasayan]

@mrubens @cte Ready for review.

Context:

As Roo becomes more agentic and as models get better we care more about the broad strokes and less about the details flying by at 100tk/s. Generally, the goal here is to start pulling together the styling in the Chat Stream and to quiet the noise down a bit while still giving users access to verbose outputs if they need them.

Quick walkthrough:

ChatRow refactor and 'mildly' unified UI.

Still more work to do here but, the actions (tool use, api calls, diffs) now have unified styling and some of the components have been broken out.

View API Requests in Editor Pane

No more code accordions to view a thousand-line API request. Now we break that content out into a preview tab:

Screen.Recording.2025-04-29.at.2.31.50.PM.mov

...And the same for Diffs-within-Markdown, Diff Tools, and other code fragments:

...which means no more of this:

[elianiva]

nice, this looks wayyy better than the current one, some nitpicks though

i feel like this takes up too much space, we can reduce the whitespace IMO

i like this one a bit better (the inner padding, i mean)

btw, did you intentionally make the rounded corners different? some are more rounded than the others. i think it'll look better if they are more consistent

[sachasayan]

i feel like this takes up too much space, we can reduce the whitespace IMO

You're right. Let's nip-tuck this, I'll do a quick additional commit.

btw, did you intentionally make the rounded corners different? some are more rounded than the others. i think it'll look better if they are more consistent

I evened them up a bit after I took the screenshot. But tbh there's like fifty of these and they all had independent hard-coded styling and markup. It's going to take a few PRs to chase them all down, DRY everything, and start building a 'universal' styling language. Right now I want to get this mechanism in so there's no rebasing every 2-3 days because... this is a lot of code in a very 'hot' part of the codebase.

[samhvw8]

@sachasayan love this, sometime when view large api request will make webview crash, this pr will solve that problems as well 🙆

[mrubens]

Not sure we want to add these to common - do they already exist in chat.json?

[mrubens]

We don't need inline English fallbacks for translations - they'll just use what's in the English json file if a match isn't found.

Suggested change

	title={t("chat:apiRequest.viewDetailsTooltip") ?? "View API Request Details"}>
	title={t("chat:apiRequest.viewDetailsTooltip")}>

[mrubens]

Do you mind doing a pass over this to remove unnecessary comments? The models are so bad at leaving these in despite whatever instructions I come up with.

[sachasayan]

Yep. I have a regex I've been using, by the way. I'll throw it in the pre-commit hook or a bot or something like that when I get a chance:

\/\/[^\S\n]+(?:Add|Remove|Update|Import|Restore).{1,30}(\n)

• Two forward slashes
• One or more whitespace non-newline characters
• One of the words "Add", "Remove", "Update", "Import", or "Restore".
• Between 1 and 3 other characters (except newline)
• Newline

[mrubens]

I like the idea in general of cleaning up the chat-view and getting rid of accordions, thank you for taking this on.

I agree with the feedback around getting to consistent corner rounding if we can, though I hear you on how many conflicts a PR like this is going to have to deal with.

Getting into more fine-grained visual feedback - I find the new colored/bordered elements to be very visually prominent compared to user messages, task headers, question options, etc. It seems like most of the time they're just informational, so I wonder if we should dial back the prominence a bit.

[sachasayan]

This is good to go as long as tests are passing @mrubens @cte.

[samhvw8]

Love it, waiting it on air 💯

[hannesrudolph]

@sachasayan Thanks for your PR.

Since there's been no activity for a few weeks after changes were requested, we're moving this back to draft status. Please update the PR or let us know your plans. If you're no longer working on it, consider closing it or creating a fresh issue using our issue-first approach.

We appreciate your contribution and look forward to your updates!

[VladyslavKochetkov]

@hannesrudolph this would be an amazing feature. I'm coming from Cursor as I'm sure many other are with their recent pricing changes and this is the one bit that feels off.

[elianiva]

@hannesrudolph I am willing to take this over if no one wants to work on it yet and we still want to land this feature. Feel free to assign me! 🙂

[vjaykrsna]

Sad to see so much of progress halted for so long. Wish I knew enough of typescript to carry this on.

[elianiva]

Sad to see so much of progress halted for so long. Wish I knew enough of typescript to carry this on.

hi! sorry for the long delay, i was planning on continuing this but then i thought it'd be better to move this back to planning since it changes quite a lot of things that is core to roocode

i do have some ideas on what could be improved from the UI but most of them are "nice to have" things, i don't have the telemetry data but i would like to assume that most users won't really care about how things generally look for the chat UI, which makes me a bit hesitant on continuing this after i thought about it

i can probably write the draft for those ideas later so it's clearer to see what i'm thinking of, and then the core devs can see if it fits with the direction of roocode's development or not, instead of having me continue this big PR and have it rejected 😆

in the meantime, it's probably better to close this stale PR