Usage visibility #30
Usage visibility #30
Conversation
WalkthroughThis pull request expands the billing token information across the frontend. The Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant AccountMenu
participant CreditUsage
participant LocalState
User->>AccountMenu: Open Account Menu
AccountMenu->>CreditUsage: Render CreditUsage component
CreditUsage->>LocalState: Retrieve billingStatus (total_tokens, used_tokens)
LocalState-->>CreditUsage: Return token data
CreditUsage->>User: Display progress bar with token usage
sequenceDiagram
participant User
participant BillingDebugger
participant State
User->>BillingDebugger: Input values for total_tokens/used_tokens
BillingDebugger->>State: Update debugStatus state via onChange handlers
User->>BillingDebugger: Click "Test Pro + No Chats" button
BillingDebugger->>State: Create newStatus with total_tokens=20000, used_tokens=18500
BillingDebugger->>User: Display updated token status
Possibly related PRs
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Deploying maple with
|
| Latest commit: |
8780683
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://12adecf6.maple-ca8.pages.dev |
| Branch Preview URL: | https://usage-visibility.maple-ca8.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
frontend/src/components/ChatBox.tsx (1)
302-304: Consider consolidating duplicate threshold constants.The
STARTER_LIMIT_THRESHOLDconstant is defined in three different places (lines 44, 111, and 303) with the same value of 7000. This violates the DRY principle and could lead to maintenance issues if one value needs to be changed but others are forgotten.Consider moving these constants to a shared location, either at the top of the file or in a separate constants file:
+ // Token thresholds for different plan types + const STARTER_WARNING_THRESHOLD = 4000; + const STARTER_LIMIT_THRESHOLD = 7000; + const PRO_WARNING_THRESHOLD = 10000; + function TokenWarning({ messages, currentInput, chatId, className, billingStatus }: { messages: ChatMessage[]; currentInput: string; chatId?: string; className?: string; billingStatus?: BillingStatus; }) { const totalTokens = messages.reduce((acc, msg) => acc + estimateTokenCount(msg.content), 0) + (currentInput ? estimateTokenCount(currentInput) : 0); const navigate = useNavigate(); // Check if user is on starter plan const isStarter = billingStatus?.product_name.toLowerCase().includes("starter") || false; - // Token thresholds for different plan types - const STARTER_WARNING_THRESHOLD = 4000; - const STARTER_LIMIT_THRESHOLD = 7000; - const PRO_WARNING_THRESHOLD = 10000;And then remove the other duplicate constant declarations in the other components.
Also applies to: 44-45, 111-112
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
frontend/src/billing/billingApi.ts(1 hunks)frontend/src/components/AccountMenu.tsx(2 hunks)frontend/src/components/BillingDebugger.tsx(3 hunks)frontend/src/components/ChatBox.tsx(5 hunks)frontend/src/components/CreditUsage.tsx(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Cloudflare Pages
🔇 Additional comments (13)
frontend/src/components/AccountMenu.tsx (2)
17-17: LGTM: Clean import of the new CreditUsage component.The import is correctly placed with other component imports.
133-133: LGTM: Good placement of the CreditUsage component.The CreditUsage component is appropriately placed after the billing plan badge and before the account dropdown menu trigger, creating a logical grouping of billing-related information.
frontend/src/billing/billingApi.ts (1)
11-12: LGTM: Appropriate addition of token tracking fields.The new properties
total_tokensandused_tokensare correctly typed asnumber | null, consistent with the typing pattern of other nullable numeric properties in the BillingStatus type (likechats_remaining).frontend/src/components/BillingDebugger.tsx (3)
25-26: LGTM: Correctly added new token fields to debugStatus initialization.The new token properties are properly initialized from currentStatus with null fallbacks, maintaining consistency with the existing pattern.
99-128: LGTM: Well-implemented input fields for token debugging.The implementation for total and used credits follows the same pattern as other numeric inputs, with proper handling of empty values and conversion to integers.
153-154: LGTM: Added token values to Pro test scenario.The "Test Pro + No Chats" scenario now includes realistic token values (20000 total, 18500 used), providing a good way to test the near-limit state (92.5% usage).
frontend/src/components/CreditUsage.tsx (1)
1-35: Well-implemented token usage visualization component.The component effectively visualizes token usage with:
- Conditional rendering when token data is available
- Proper percentage calculation with min/max constraints
- Color-coded progress bar that changes based on usage thresholds
- Clear labeling and "Resets Monthly" indication
frontend/src/components/ChatBox.tsx (6)
42-46: Good addition of threshold constants for different plan types.Extracting these magic numbers into named constants improves code readability and maintainability.
48-48: LGTM: Appropriate use of constants based on plan type.This logic correctly applies different thresholds depending on whether the user is on a starter or pro plan.
50-52: Good implementation of conditional warning logic.This prevents showing both warning and limit messages simultaneously for starter users who exceed the limit.
110-114: LGTM: Clear threshold implementation for token limit.The condition correctly shows the limit message only when the threshold is exceeded.
314-316: LGTM: Properly implemented submission restriction for starter users.The logic correctly prevents submission when a starter user exceeds their token limit.
330-333: LGTM: Appropriate placeholder text for token limit.Good user experience enhancement - showing a helpful message that explains why input is disabled and offering an upgrade path.
|
let's good. Tested with Free, Starter, and Team users. Free still works as before. |
Summary by CodeRabbit
New Features
Enhancements