Fix invoice status logic and refactor billing components #8175
Conversation
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
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. WalkthroughRefactors BillingHistory by extracting getStatusBadge and isInvoicePayable helpers, replacing inline logic. Updates payment-option rendering to use isInvoicePayable. Adjusts past-due comparison to use invoice.due_date directly against Date.now(), implying unit change. Removes the previous inline getStatusBadge and defines helpers at module scope. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor User
participant UI as BillingHistory
participant H1 as getStatusBadge
participant H2 as isInvoicePayable
User->>UI: View invoices
UI->>H1: getStatusBadge(invoice.status)
H1-->>UI: React node (badge)
UI->>H2: isInvoicePayable(invoice)
alt Invoice payable (open/uncollectible)
UI-->>User: Render crypto/card payment options
else Not payable
UI-->>User: Hide payment options
end
Note over UI,H2: Past-due check compares invoice.due_date directly to Date.now()
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests
Comment |
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
jnsdls
force-pushed
the
Fix_invoice_status_logic_and_refactor_billing_components
branch
from
7210b29 to
41bac4a
Compare
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
...oard/src/app/(app)/team/[team_slug]/(team)/~/billing/invoices/components/billing-history.tsx
Outdated
Show resolved
Hide resolved
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8175 +/- ##
=======================================
Coverage 56.29% 56.29%
=======================================
Files 906 906
Lines 59209 59209
Branches 4182 4182
=======================================
Hits 33330 33330
Misses 25774 25774
Partials 105 105
🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
apps/dashboard/src/app/(app)/team/[team_slug]/(team)/~/billing/invoices/components/billing-history.tsx(2 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{ts,tsx}: Write idiomatic TypeScript with explicit function declarations and return types
Limit each file to one stateless, single-responsibility function for clarity
Re-use shared types from@/typesor localtypes.tsbarrels
Prefer type aliases over interface except for nominal shapes
Avoidanyandunknownunless unavoidable; narrow generics when possible
Choose composition over inheritance; leverage utility types (Partial,Pick, etc.)
Comment only ambiguous logic; avoid restating TypeScript in prose
**/*.{ts,tsx}: Use explicit function declarations and explicit return types in TypeScript
Limit each file to one stateless, single‑responsibility function
Re‑use shared types from@/typeswhere applicable
Prefertypealiases overinterfaceexcept for nominal shapes
Avoidanyandunknownunless unavoidable; narrow generics when possible
Prefer composition over inheritance; use utility types (Partial, Pick, etc.)
Lazy‑import optional features and avoid top‑level side‑effects to reduce bundle size
Files:
apps/dashboard/src/app/(app)/team/[team_slug]/(team)/~/billing/invoices/components/billing-history.tsx
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Load heavy dependencies inside async paths to keep initial bundle lean (lazy loading)
Files:
apps/dashboard/src/app/(app)/team/[team_slug]/(team)/~/billing/invoices/components/billing-history.tsx
apps/{dashboard,playground-web}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
apps/{dashboard,playground-web}/**/*.{ts,tsx}: Import UI primitives from@/components/ui/*(Button, Input, Select, Tabs, Card, Sidebar, Badge, Separator) in dashboard and playground apps
UseNavLinkfor internal navigation with automatic active states in dashboard and playground apps
Use Tailwind CSS only – no inline styles or CSS modules
Usecn()from@/lib/utilsfor conditional class logic
Use design system tokens (e.g.,bg-card,border-border,text-muted-foreground)
Server Components (Node edge): Start files withimport "server-only";
Client Components (browser): Begin files with'use client';
Always callgetAuthToken()to retrieve JWT from cookies on server side
UseAuthorization: Bearerheader – never embed tokens in URLs
Return typed results (e.g.,Project[],User[]) – avoidany
Wrap client-side data fetching calls in React Query (@tanstack/react-query)
Use descriptive, stablequeryKeysfor React Query cache hits
ConfigurestaleTime/cacheTimein React Query based on freshness (default ≥ 60s)
Keep tokens secret via internal API routes or server actions
Never importposthog-jsin server components
Files:
apps/dashboard/src/app/(app)/team/[team_slug]/(team)/~/billing/invoices/components/billing-history.tsx
apps/{dashboard,playground}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
apps/{dashboard,playground}/**/*.{ts,tsx}: Import UI primitives from@/components/ui/_(e.g., Button, Input, Tabs, Card)
UseNavLinkfor internal navigation to get active state handling
Use Tailwind CSS for styling; no inline styles
Merge class names withcn()from@/lib/utilsfor conditional classes
Stick to design tokens (e.g., bg-card, border-border, text-muted-foreground)
Server Components must start withimport "server-only"; usenext/headers, server‑only env, heavy data fetching, andredirect()where appropriate
Client Components must start with'use client'; handle interactivity with hooks and browser APIs
Server-side data fetching: callgetAuthToken()from cookies, sendAuthorization: Bearer <token>header, and return typed results (avoidany)
Client-side data fetching: wrap calls in React Query with descriptive, stablequeryKeysand set sensiblestaleTime/cacheTime(≥ 60s default); keep tokens secret via internal routes or server actions
Do not importposthog-jsin server components (client-side only)
Files:
apps/dashboard/src/app/(app)/team/[team_slug]/(team)/~/billing/invoices/components/billing-history.tsx
apps/{dashboard,playground}/**/*.tsx
📄 CodeRabbit inference engine (AGENTS.md)
Expose a
classNameprop on the root element of every component
Files:
apps/dashboard/src/app/(app)/team/[team_slug]/(team)/~/billing/invoices/components/billing-history.tsx
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Size
- GitHub Check: Analyze (javascript)
🔇 Additional comments (2)
apps/dashboard/src/app/(app)/team/[team_slug]/(team)/~/billing/invoices/components/billing-history.tsx (2)
49-51: LGTM!The helper function correctly identifies payable invoices by including both "open" and "uncollectible" statuses, which aligns with the business logic.
133-133: LGTM! Improved payment logic consistency.The refactored payment button visibility now correctly includes both "open" and "uncollectible" invoices, which aligns with the intended business logic as mentioned in the PR objectives.
...oard/src/app/(app)/team/[team_slug]/(team)/~/billing/invoices/components/billing-history.tsx
Outdated
Show resolved
Hide resolved
...oard/src/app/(app)/team/[team_slug]/(team)/~/billing/invoices/components/billing-history.tsx
Outdated
Show resolved
Hide resolved
jnsdls
force-pushed
the
Fix_invoice_status_logic_and_refactor_billing_components
branch
from
41bac4a to
93a0a03
Compare
jnsdls
force-pushed
the
Fix_invoice_status_logic_and_refactor_billing_components
branch
from
93a0a03 to
c6cb579
Compare
jnsdls
force-pushed
the
Fix_invoice_status_logic_and_refactor_billing_components
branch
from
c6cb579 to
7a2dd35
Compare
size-limit report 📦
|
jnsdls
deleted the
Fix_invoice_status_logic_and_refactor_billing_components
branch
TL;DR
Fixed invoice status logic and refactored invoice-related functions for better code organization.
What changed?
getStatusBadgeandisInvoicePayablefunctions from the component to the module levelisInvoicePayablefunction instead of checking only for "open" statusHow to test?
Why make this change?
The previous implementation had a logic error in the "Past Due" badge condition, showing the wrong status for invoices. Additionally, refactoring the functions improves code organization and makes the invoice payment logic more consistent by using a dedicated function to determine if an invoice is payable.
PR-Codex overview
This PR refactors the
getStatusBadgefunction in thebilling-history.tsxfile and introduces a new functionisInvoicePayable. These changes improve the handling of invoice statuses and their display in the billing history component.Detailed summary
getStatusBadgefunction to a standalone function.isInvoicePayableto check if an invoice can be paid.Summary by CodeRabbit
New Features
Bug Fixes
Refactor