Conversation
- Move Result.unwrap() into Result.pipe() chains to eliminate intermediate variables - Apply same pattern used for sessionCost to todayCost, blockInfo/burnRateInfo, and contextInfo - Improves code consistency and follows functional programming pipeline pattern
- Move display logic back into Result.pipe for better consistency - Return formatted string directly from pipeline instead of raw data - Simplify status line construction with cleaner contextInfo display - Use N/A fallback pattern similar to sessionDisplay
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. Caution Review failedThe pull request is closed. WalkthroughRefactors src/commands/statusline.ts to use @praha/byethrow’s Result-based pipelines for data loading, error handling, and formatting of the status line. Updates package.json to bump @praha/byethrow from ^0.6.2 to ^0.6.3. No public API or export signature changes. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant StatuslineCmd
participant Session as SessionData
participant Usage as DailyUsage
participant Blocks as BlockManager
participant Context as ContextAnalyzer
participant Result as Result.pipe
participant Log as Logger
participant UI as Renderer
User->>StatuslineCmd: run
StatuslineCmd->>Result: pipe(Session.load)
Result-->>Log: inspectError(err)
Result-->>StatuslineCmd: sessionCost | undefined
StatuslineCmd->>Result: pipe(Usage.loadToday -> sum)
Result-->>Log: inspectError(err)
Result-->>StatuslineCmd: totalCost (default 0)
StatuslineCmd->>Result: pipe(Blocks.active -> compute info)
Result-->>Log: inspectError(err)
Result-->>StatuslineCmd: {blockInfo, burnRateInfo}
StatuslineCmd->>Result: pipe(Context.measure -> format)
Result-->>Log: inspectError(debug)
Result-->>StatuslineCmd: contextInfo | undefined
StatuslineCmd->>UI: render status line
UI-->>User: status output
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
ccusage-guide | 6c6d463 | Aug 13 2025, 12:05 PM |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @ryoppippi, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request refactors the statusline command to enhance its functional programming paradigm by consistently utilizing the Result.pipe pattern. The primary goal is to improve code clarity, error handling, and maintainability by inlining Result.unwrap() calls and eliminating intermediate variables. This change applies to various data calculations within the command, such as session costs, daily usage, block information, and context token processing, ensuring a more streamlined and robust data flow with proper fallback mechanisms.
Highlights
- Consistent Functional Pipeline Adoption: The core logic for calculating
sessionCost,todayCost,blockInfo,burnRateInfo, andcontextInfohas been rewritten to leverage theResult.pipepattern. This streamlines error handling and data transformation by chaining operations, making the code more readable and robust. - Reduced Boilerplate and Inlined Unwrapping: Intermediate variables previously used to store results before unwrapping them have been eliminated.
Result.unwrap()calls are now directly integrated into theResult.pipechains, reducing boilerplate and improving conciseness. - Improved Context Information Display and Fallback: The handling and display of
contextInfohave been refined. The logic now explicitly includes a 'N/A' fallback for cases where context data is unavailable, ensuring a consistent user experience. - Dependency Update: The
@praha/byethrowlibrary, which provides theResulttype andpipemethod, has been updated to version0.6.3. This update supports the refactoring changes and ensures compatibility.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
commit: |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
There was a problem hiding this comment.
Code Review
This pull request successfully refactors the statusline.ts command to consistently use the Result.pipe functional pattern, which is a great improvement for readability and error handling. The logic for calculating session cost, daily cost, block info, and context info has been cleanly migrated from try...catch blocks to functional pipelines. I have a few minor suggestions to further enhance the conciseness of the new code. Overall, this is a solid refactoring.
| Result.map((sessionCost) => { | ||
| return sessionCost?.totalCost; | ||
| }), |
There was a problem hiding this comment.
This mapping function can be simplified to a concise arrow function for better readability.
Result.map(sessionCost => sessionCost?.totalCost),| Result.map((dailyData) => { | ||
| if (dailyData.length > 0) { | ||
| const totals = calculateTotals(dailyData); | ||
| return totals.totalCost; | ||
| } | ||
| return 0; | ||
| }), |
There was a problem hiding this comment.
This mapping logic can be expressed more concisely using a ternary operator, which simplifies the code and aligns well with the functional pipeline style.
Result.map(dailyData => (dailyData.length > 0 ? calculateTotals(dailyData).totalCost : 0)),| const burnRateInfo = burnRate != null | ||
| ? (() => { | ||
| const costPerHour = burnRate.costPerHour; | ||
| const costPerHourStr = `${formatCurrency(costPerHour)}/hr`; | ||
|
|
||
| // Apply color based on burn rate (tokens per minute non-cache) | ||
| const coloredBurnRate = burnRate.tokensPerMinuteForIndicator < 2000 | ||
| ? pc.green(costPerHourStr) // Normal | ||
| : burnRate.tokensPerMinuteForIndicator < 5000 | ||
| ? pc.yellow(costPerHourStr) // Moderate | ||
| : pc.red(costPerHourStr); // High | ||
|
|
||
| return ` | 🔥 ${coloredBurnRate}`; | ||
| })() | ||
| : ''; |
There was a problem hiding this comment.
The nested ternary operator inside the IIFE for burnRateInfo can be simplified for better readability. Using an if check at the beginning of the IIFE makes the logic clearer and flatter.
const burnRateInfo = (() => {
if (burnRate == null) {
return '';
}
const costPerHourStr = `${formatCurrency(burnRate.costPerHour)}/hr`;
const color = burnRate.tokensPerMinuteForIndicator < 2000
? pc.green
: burnRate.tokensPerMinuteForIndicator < 5000
? pc.yellow
: pc.red;
return ` | 🔥 ${color(costPerHourStr)}`;
})();
1 participant
Summary
Changes
Test plan
Summary by CodeRabbit