feat(reasoning): default expand thinking bubble and update docs#311
feat(reasoning): default expand thinking bubble and update docs#311gene9831 wants to merge 6 commits intoopentiny:developfrom
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughDocs updated for BubbleList rendering, prop vs provider renderer behavior, new CSS variables for reasoning bubble side border; Reasoning renderer now defaults to open; thinkingPlugin syncs Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 Tip You can get early access to new features in CodeRabbit.Enable the |
|
✅ Preview build completed successfully!
|
📦 Package Previewpnpm add https://pkg.pr.new/@opentiny/tiny-robot@6385a2a pnpm add https://pkg.pr.new/@opentiny/tiny-robot-kit@6385a2a pnpm add https://pkg.pr.new/@opentiny/tiny-robot-svgs@6385a2a commit: 719dd5a |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/kit/src/vue/message/plugins/thinkingPlugin.ts`:
- Around line 23-25: The code clears flags by setting lastMessage.state.thinking
and lastMessage.state.open to undefined, which triggers Reasoning.vue's
open-by-default fallback; change those assignments in thinkingPlugin (the block
that checks lastMessage?.state?.thinking) to explicitly set
lastMessage.state.thinking = false and lastMessage.state.open = false so the
panel stays closed at turn end instead of re-opening.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 396b5e6a-22da-4e1c-bf9c-609bff8a64a2
📒 Files selected for processing (4)
docs/src/components/bubble.mddocs/src/tools/message.mdpackages/components/src/bubble/renderers/Reasoning.vuepackages/kit/src/vue/message/plugins/thinkingPlugin.ts
…ubble in quick start guide
…eflect updated naming conventions
…e and auto continuation parameters
There was a problem hiding this comment.
🧹 Nitpick comments (1)
docs/src/tools/message.md (1)
406-408: Add defensive handling forargumentsparsing to match the basic example.The basic example (line 322) uses
toolCall.function?.arguments || '{}'with optional chaining and a fallback, but this MCP example directly accessestoolCall.function.argumentswithout guards. Ifargumentsis undefined or malformed,JSON.parse()will throw.🔧 Suggested fix for consistency
callTool: async (toolCall) => { - return await callTool(toolCall.function.name, JSON.parse(toolCall.function.arguments)) + return await callTool(toolCall.function.name, JSON.parse(toolCall.function?.arguments || '{}')) },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/src/tools/message.md` around lines 406 - 408, The callTool handler currently calls callTool(toolCall.function.name, JSON.parse(toolCall.function.arguments)) with no guards; update the callSite in the callTool async function to safely access toolCall.function?.arguments with a fallback (e.g. '{}' or '') and wrap JSON.parse in a try/catch (or use a safe-parse helper) so malformed or missing arguments don't throw; ensure you still pass the parsed object to callTool and log or handle parse errors appropriately.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@docs/src/tools/message.md`:
- Around line 406-408: The callTool handler currently calls
callTool(toolCall.function.name, JSON.parse(toolCall.function.arguments)) with
no guards; update the callSite in the callTool async function to safely access
toolCall.function?.arguments with a fallback (e.g. '{}' or '') and wrap
JSON.parse in a try/catch (or use a safe-parse helper) so malformed or missing
arguments don't throw; ensure you still pass the parsed object to callTool and
log or handle parse errors appropriately.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: b88e8425-a2c4-49fe-b357-a6831b6a6daf
📒 Files selected for processing (2)
docs/src/tools/message.mdpackages/kit/src/vue/message/types.ts
…rer usage and clarify fallback renderer configuration
gene9831
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
docs/src/tools/message.md (1)
321-324: Consider showingcontextincallToolexample for consistency.The API table documents
callTool(toolCall, context), but the example only shows one parameter. Even if unused, including_contextwould reduce confusion.✏️ Suggested doc tweak
- callTool: async (toolCall) => { + callTool: async (toolCall, _context) => { const args = JSON.parse(toolCall.function?.arguments || '{}') return `Weather of ${args.city}: Sunny.` },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/src/tools/message.md` around lines 321 - 324, The example for callTool should include the second parameter to match the API: update the async function signature from callTool: async (toolCall) => { ... } to include the context param (use a named unused param like _context) so it reads callTool: async (toolCall, _context) => { ... }; keep the body unchanged but accept the _context parameter to remove confusion and align with the documented callTool(toolCall, context) API.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/src/tools/message.md`:
- Around line 349-352: The docs example is exposing a client-side secret via
import.meta.env.VITE_MCP_API_KEY in the headers object; replace this with a
server-side pattern: remove direct use of import.meta.env.VITE_MCP_API_KEY and
instead show calling a server proxy endpoint (e.g., POST /api/proxy-mcp that
injects the Bearer token) or a short-lived token flow (e.g., fetch a one-time
token from /api/token then set Authorization: `Bearer <token>`), and update the
example to use a placeholder like Authorization: 'Bearer
<SERVER_PROVIDED_TOKEN>' and a brief note recommending server-side storage of
the key.
---
Nitpick comments:
In `@docs/src/tools/message.md`:
- Around line 321-324: The example for callTool should include the second
parameter to match the API: update the async function signature from callTool:
async (toolCall) => { ... } to include the context param (use a named unused
param like _context) so it reads callTool: async (toolCall, _context) => { ...
}; keep the body unchanged but accept the _context parameter to remove confusion
and align with the documented callTool(toolCall, context) API.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 3001f005-5313-4164-a7cf-1e2c8f3861cb
📒 Files selected for processing (2)
docs/src/components/bubble.mddocs/src/tools/message.md
| url: 'https://dashscope.aliyuncs.com/api/v1/mcps/amap-maps/sse', | ||
| headers: { | ||
| Authorization: `Bearer ${import.meta.env.VITE_MCP_API_KEY}`, | ||
| }, |
There was a problem hiding this comment.
Avoid documenting browser-side Bearer API keys directly.
This example places a credential in client-side headers (import.meta.env.VITE_MCP_API_KEY), which is exposed to end users and risks key leakage. Recommend documenting a server-side proxy or short-lived token flow instead.
🔐 Safer documentation direction
- headers: {
- Authorization: `Bearer ${import.meta.env.VITE_MCP_API_KEY}`,
- },
+ // 建议：不要在前端直接放置长期 API Key。
+ // 通过后端代理注入 Authorization，或使用短时令牌方案。🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/src/tools/message.md` around lines 349 - 352, The docs example is
exposing a client-side secret via import.meta.env.VITE_MCP_API_KEY in the
headers object; replace this with a server-side pattern: remove direct use of
import.meta.env.VITE_MCP_API_KEY and instead show calling a server proxy
endpoint (e.g., POST /api/proxy-mcp that injects the Bearer token) or a
short-lived token flow (e.g., fetch a one-time token from /api/token then set
Authorization: `Bearer <token>`), and update the example to use a placeholder
like Authorization: 'Bearer <SERVER_PROVIDED_TOKEN>' and a brief note
recommending server-side storage of the key.
1 participant
Summary by CodeRabbit
New Features
Documentation
Public API