-
Notifications
You must be signed in to change notification settings - Fork 2.3k
feat[DRAFT]: Introduce structured thinking UI and total thinking time measurement #6835
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
qnixsynapse
wants to merge
24
commits into
dev
Choose a base branch
from
feat/new_combined_reasoning_tool_calling_block
base: dev
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6cee9cf to
97c9407
Compare
… thinking time - **ThinkingBlock** - Added `ThoughtStep` type and UI handling for step kinds: `thought`, `tool_call`, `tool_output`, and `done`. - Integrated `Check` icon for completed steps and formatted duration (seconds) display. - Implemented streaming paragraph extraction, fade‑in/out animation, and improved loading state handling. - Updated header to show dynamic titles (thinking/thought + duration) and disabled expand/collapse while loading. - Utilized `cn` utility for conditional class names and added relevant imports. - **ThreadContent** - Defined `ToolCall` and `ThoughtStep` types for type safety. - Constructed `allSteps` via `useMemo`, extracting thought paragraphs, tool calls/outputs, and a final `done` step with total thinking time. - Passed `steps`, `loading`, and `duration` props to `ThinkingBlock`. - Introduced `hasReasoning` flag to conditionally render the reasoning block and avoid duplicate tool call rendering. - Adjusted rendering logic to hide empty reasoning and ensure tool call blocks only appear when no reasoning is present. - **useChat** - Refactored `getCurrentThread` for clearer async flow while preserving temporary‑chat behavior. - Captured `startTime` at message creation and computed `totalThinkingTime` on completion. - Included `totalThinkingTime` in message metadata when appropriate. - Minor cleanup: improved error handling for image ingestion and formatting adjustments. Overall, these changes provide a richer, step‑by‑step thinking UI, better state handling during streaming, and expose total thinking duration for downstream components.
- Replace raw text parsing with step‑based streaming logic in `ThinkingBlock`. - Introduced `stepsWithoutDone`, `currentStreamingStepIndex`, and `displayedStepIndex` to drive the streaming UI. - Added placeholder UI for empty streaming state and hide block when there is no content after streaming finishes. - Simplified expansion handling and bullet‑point rendering, using `renderStepContent` for both streaming and expanded views. - Removed unused `extractThinkingContent` import and related code. - Updated translation keys and duration formatting. - Consolidate reasoning and tool‑call presentation in `ThreadContent`. - Introduced `shouldShowThinkingBlock` to render a single `ThinkingBlock` when either reasoning or tool calls are present. - Adjusted `ThinkingBlock` props (`text`, `steps`, `loading`) and ID generation. - Commented out the now‑redundant `ToolCallBlock` import and removed its conditional rendering block. - Cleaned up comments, unused variables, and minor formatting/typo fixes. - General cleanup: - Updated comments for clarity. - Fixed typo in deletion loop comment. - Minor UI tweaks (bullet styling, border handling).
…d step limit * Move the assistant‑loop logic out of `useChat` and into `postMessageProcessing`. * Eliminate the while‑loop that drove repeated completions; now a single completion is sent and subsequent tool calls are processed recursively. * Introduce early‑abort checks and guard against missing provider before proceeding. * Add `ReasoningProcessor` import and use it consistently for streaming reasoning chunks. * Add `ToolCallEntry` type and a global `toolStepCounter` to track and cap total tool steps (default 20) to prevent infinite loops. * Extend `postMessageProcessing` signature to accept thread, provider, tools, UI update callback, and max tool steps. * Update UI‑update logic to use a single `updateStreamingUI` callback and ensure RAF scheduling is cleaned up reliably. * Refactor token‑speed / progress handling, improve error handling for out‑of‑context situations, and tidy up code formatting. * Minor clean‑ups: const‑ify `availableTools`, remove unused variables, improve readability.
…ention This commit significantly refactors how assistant message content containing reasoning steps (<think> blocks) and tool calls is parsed and split into final output text and streamed reasoning text in `ThreadContent.tsx`. It introduces new logic to correctly handle multiple, open, or closed `<think>` tags, ensuring that: 1. All text outside of `<think>...</think>` tags is correctly extracted as final output text. 2. Content inside all `<think>` tags is aggregated as streamed reasoning text. 3. The message correctly determines if reasoning is actively loading during a stream. Additionally, this commit: * **Fixes infinite tool loop prevention:** The global `toolStepCounter` in `completion.ts` is replaced with an explicit `currentStepCount` parameter passed recursively in `postMessageProcessing`. This ensures that the tool step limit is correctly enforced per message chain, preventing potential race conditions and correctly resolving the chain. * **Fixes large step content rendering:** Limits the content of a single thinking step in `ThinkingBlock.tsx` to 1000 characters to prevent UI slowdowns from rendering extremely large JSON or text outputs.
Implement support for displaying images returned in the Multi-Content Part (MCP) format within the `tool_output` step of the ReAct thinking block. This change: - Safely parses `tool_output` content to detect and extract image data (base64). - Renders images as clickable thumbnails using data URLs. - Integrates `ImageModal` to allow users to view the generated images in full size.
- Remove legacy <think> tag parsing and accumulation of reasoning chunks in the main text buffer. - Rely exclusively on `streamEvents` to derive reasoning and loading state. - Update loading logic to account for both tool calls and reasoning events. - Adjust memo dependencies and return values to avoid stale references. - Update `useChat` and `completion.ts` to stop mutating the accumulated text with reasoning, keeping the logic purely event‑driven. - Ensure the ThinkingBlock always renders from the structured steps list, improving consistency and eliminating duplicate content.
Add more descriptive loading and finished state labels for the ThinkingBlock component. The update: - Uses new translation keys (`chat:calling_tool`, `chat:thought_and_tool_call`, etc.) for clearer tool‑call and reasoning messages. - Handles `tool_call`, `tool_output`, and `reasoning` steps explicitly, providing a fallback when no active step is present. - Adjusts the final label logic to use the new i18n keys and formats durations consistently. - Adds missing locale entries for all new keys and a trailing newline to the JSON file. These changes improve user feedback during chat interactions and make the messages easier to maintain and localize.
The update fixes how total thinking time is calculated during a chat message flow. Previously the elapsed time from the initial completion was incorrectly added to the overall thinking time, leading to inflated metrics. The new logic splits the computation into separate phases (initial completion, tool execution, and follow‑up completions) and accumulates them into `totalThinkingTime`, ensuring accurate measurement. Additionally, translation keys for chat components are now namespaced with `chat:` to avoid collisions and clearly indicate the context in which they are used. The diff also removes a stray comment line and keeps metadata updates consistent across recursive calls.
Remove the separate “Thinking…” placeholder component and embed the empty‑streaming state directly inside the main block. Adjust the click handler and button disabled logic to only allow toggling when content is available, preventing accidental collapse during loading. This change simplifies the component, eliminates duplicate markup, and improves UX by consistently showing the thinking indicator within the block.
Previously the component used an `isStreamingEmpty` flag to display a “thinking” placeholder when the block was loading but had no steps yet. The new implementation handles this case directly in the streaming block by checking `activeStep || N === 0`, removing the unused flag and simplifying the conditional rendering. In addition, the click and button‑disable logic were clarified, and extraneous comments were removed for cleaner code. These changes improve readability and maintainability without altering external behavior.
Adds a `linkComponents` prop that can be supplied to `RenderMarkdown` within `ThinkingBlock` and propagates this prop to the thread view. The change enables custom link rendering (e.g., special handling of URLs or interactions) without modifying the core component logic. It also renames the “Tool Call” label to “Tool Input” to more accurately describe the content being displayed.
Use the `MessageStatus` enum to determine when the “Generate AI Response” button should appear. Previously the visibility logic checked the last message’s role or the presence of tool calls, which could be unreliable since we moved to combined tool call/reasoning block. By checking that the last message exists and its status is not `Ready` which is that the message is finished generating when an eot token is found, the button is shown only while the AI has stopped generating before it could end properly, improving UX and aligning the UI state with the underlying message state. The change also imports `MessageStatus` and cleans up formatting for readability.
Previously the dialog simply rendered the raw JSON of the metadata, which made it hard to read and required the CodeEditor dependency. This change replaces the raw viewer with a set of semantic sections that show assistant details, model parameters, token speed, and timestamps in a clean, icon‑rich layout. The component now uses TypeScript interfaces for better type safety, memoized formatting helpers, and removes the unnecessary CodeEditor import. Locale entries were added for all new labels. The updated UI improves user experience by making metadata more accessible and readable, while simplifying the code base and reducing bundle size.
…ormatting Add import for `captureProactiveScreenshots`, correct mock response formatting, and update test expectations to match the new API. Enhance coverage by adding scenarios for screenshot capture errors, abort controller handling, and proactive mode toggling. These changes provide clearer, more robust tests for the completion logic.
The metadata prop was previously required, but callers sometimes pass null or undefined. Updating the type to allow null/undefined prevents runtime errors and simplifies usage.
Rearrange the `postMessageProcessing` signature so that `isProactiveMode` now precedes the internal `currentStepCount`. This change improves the logical flow of the API: the proactive flag is a public flag that callers should set, whereas the step counter is an internal bookkeeping value. The updated order also aligns the JSDoc comment with the implementation. All related tests were updated to reflect the new parameter order, and comments were adjusted to describe the internal counter in the correct place. No functional behavior changes occur; the change simply makes the API easier to read and maintain.
Add a helper `extractContentAndClean` that pulls out the content between `<think>` tags and removes all auxiliary tags from the final output. Update the message rendering logic to use this helper for finalized messages that lack explicit stream events, ensuring that reasoning and final output are correctly separated and displayed. Adjust the reasoning detection to consider extracted reasoning as well as stream events, clean the copy button to use the actual final output, and eliminate duplicate `StreamEvent` type definitions. These changes improve message parsing accuracy and simplify the component’s handling of legacy messages that embed both reasoning and results in the same string.
ea922ea to
2455147
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Describe Your Changes
ThinkingBlock):reasoning,tool_call, andtool_outputusing a newReActStepstructure.useChat):startTimeat message creation and computedtotalThinkingTimeupon final completion.totalThinkingTimein message metadata when reasoning or tool calls occur.ThreadContent):ThinkingBlockcomponent whenever reasoning or tool calls are present, simplifying the thread rendering logic.streamEvents) to accurately order reasoning chunks and tool steps for reliable step-by-step display.useChat&postMessageProcessing):whileloop inuseChat; agent execution is now self-contained and driven by recursive calls withinpostMessageProcessing.toolStepCounterwith a recursivecurrentStepCountparameter to accurately limit tool execution steps per message chain, fixing potential infinite loop issues.This results in a richer, step-by-step trace of the model's internal thought process, clearer visualization of tool usage, and accurate measurement of agent latency.
Fixes Issues
Self Checklist