fix: billing page

[MaheshtheDev]

No description provided.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	supermemory-app	99fd62d	Sep 07 2025, 05:14 PM

[MaheshtheDev]

• fix: billing page #416 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add the label Main to this PR to add it to 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.

[claude]

Code Review: Billing Page Fix

✅ Positive Changes

1. Improved Data Management

• Better state management: Replaced individual React Query hooks with a single local state object (billingData) that consolidates all billing-related data
• Cleaner data flow: Using useEffect to derive state from useCustomer hook provides better control over data updates
• Reduced prop drilling: Consolidated billing data into a single state object

2. Enhanced User Experience

• Loading state: Added proper loading indicator when customer data is being fetched
• Better error handling: More robust handling of undefined/null customer data with proper fallbacks
• Consistent state: Single source of truth for billing data reduces potential race conditions

3. Code Structure Improvements

• Removed unused imports: Cleaned up imports by removing fetchConnectionsFeature, fetchMemoriesFeature, fetchSubscriptionStatus, and usePathname
• Simplified hooks: Direct use of useCustomer destructured properties instead of separate query hooks
• Better TypeScript: Explicit typing for billingData state

⚠️ Areas for Improvement

1. Performance Considerations

// Current - runs on every customer/isCustomerLoading change
useEffect(() => {
  if (!isCustomerLoading) {
    // ... state updates
  }
}, [isCustomerLoading, customer])

Recommendation: Consider memoizing the derived values to prevent unnecessary re-computations:

const billingData = useMemo(() => {
  if (isCustomerLoading || !customer) {
    return defaultBillingData;
  }
  // ... compute billing data
}, [isCustomerLoading, customer]);

2. Type Safety Issues

• Line 198: Hardcoded connection limit ({billingData.connectionsUsed} / 10) should use connectionsLimit from state
• Missing null checks: customer?.features?.memories could benefit from more explicit type guards

3. Code Consistency

// Inconsistent - using ?? operator in some places but not others
const memoriesFeature = customer?.features?.memories ?? {
  usage: 0, 
  included_usage: 0,
}
// Then later: memoriesFeature?.usage ?? 0 (redundant after nullish coalescing above)

4. Magic Numbers

• Line 198: Hardcoded 10 for connections limit should be derived from billingData.connectionsLimit
• Consider extracting plan limits to constants

🔒 Security Considerations

• No security issues identified - No sensitive data exposure or XSS vulnerabilities
• Proper use of environment-specific URLs

🧪 Testing Recommendations

• Unit tests needed: Test the useEffect logic with various customer data states
• Integration tests: Test loading states and error scenarios
• Accessibility: Ensure loading states are announced to screen readers

🚀 Suggested Fixes

1. Fix hardcoded connection limit:

<span className="text-sm text-white/90">
  {billingData.connectionsUsed} / {billingData.connectionsLimit}
</span>

2. Add useMemo for performance:

const billingData = useMemo(() => {
  if (isCustomerLoading || !customer) return defaultBillingData;
  
  const memoriesFeature = customer.features?.memories;
  const connectionsFeature = customer.features?.connections;
  
  return {
    isPro: customer.products?.some(product => product.id === "consumer_pro") ?? false,
    memoriesUsed: memoriesFeature?.usage ?? 0,
    memoriesLimit: memoriesFeature?.included_usage ?? 0, 
    connectionsUsed: connectionsFeature?.usage ?? 0,
    connectionsLimit: connectionsFeature?.included_usage ?? 0,
  };
}, [isCustomerLoading, customer]);

📊 Overall Assessment

Score: 8/10 - This is a solid refactoring that improves code organization and user experience. The main issues are minor performance optimizations and a small hardcoded value. The change successfully consolidates the billing data management and provides better loading states.

Recommendation: ✅ Approve with minor fixes - Address the hardcoded connection limit and consider the performance optimization.

[graphite-app]

[graphite-app]

Merge activity

• Sep 7, 4:54 PM UTC: Dhravya added this pull request to the Graphite merge queue.
• Sep 7, 4:56 PM UTC: Merged by the Graphite merge queue.

[claude]

Code Review for PR #416: fix: billing page

Overview

This PR refactors the billing page component to use the useCustomer hook more directly instead of separate query functions. The changes improve data flow and reduce dependencies.

✅ Positive Changes

1. Improved Data Architecture

• Consolidates billing data into a single state object with proper TypeScript typing
• Uses useCustomer hook directly instead of separate query functions, reducing complexity
• Adds proper loading states with isCustomerLoading

2. Better User Experience

• Adds loading spinner while customer data is being fetched
• Maintains consistent loading state handling throughout the component

3. Code Organization

• Removes unused imports
• Consolidates data processing in a single useEffect
• Cleaner separation of concerns

⚠️ Areas for Improvement

1. Performance Considerations

• The useEffect runs on every customer object change, which could cause unnecessary re-renders
• Consider memoizing the customer data processing with useMemo

2. Error Handling

• No error handling for customer data fetching failures
• Consider adding error boundaries or fallback states

3. Hardcoded Values

• Connections limit is hardcoded to 10 (line 198) instead of using connectionsLimit
• Should use: billingData.connectionsUsed / billingData.connectionsLimit

🔧 Specific Issues

Line 198: Replace hardcoded connection limit with dynamic value from billingData.connectionsLimit

🛡️ Security & Best Practices

✅ Security: No security issues identified

• No sensitive data exposure
• Proper authentication checks maintained
• Safe URL handling for billing portal

✅ Code Style: Follows project conventions

• Consistent with existing component patterns
• Proper TypeScript usage

🎯 Recommendation

Approve with minor fixes. The refactoring is solid and improves the codebase. Address the hardcoded connection limit and consider the performance optimizations.

Priority Fixes:

1. Fix hardcoded connection limit (line 198)
2. Add error handling for customer data loading
3. Consider memoizing the billing data calculation