@blocklet/payment-react 1.20.5 → 1.20.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (55) hide show
  1. package/.aigne/doc-smith/config.yaml +2 -2
  2. package/.aigne/doc-smith/upload-cache.yaml +381 -0
  3. package/docs/components-business-auto-topup.md +128 -179
  4. package/docs/components-business-overdue-invoice-payment.md +108 -143
  5. package/docs/components-business-resume-subscription.md +117 -104
  6. package/docs/components-business.md +12 -36
  7. package/docs/components-checkout-checkout-donate.md +209 -149
  8. package/docs/components-checkout-checkout-form.md +115 -136
  9. package/docs/components-checkout-checkout-table.md +92 -172
  10. package/docs/components-checkout.md +43 -109
  11. package/docs/components-history-credit-grants-list.md +45 -70
  12. package/docs/components-history-credit-transactions-list.md +57 -67
  13. package/docs/components-history-invoice-list.md +58 -52
  14. package/docs/components-history-payment-list.md +19 -40
  15. package/docs/components-history.md +42 -67
  16. package/docs/components-ui-form-elements-address-form.md +37 -65
  17. package/docs/components-ui-form-elements-country-select.md +80 -59
  18. package/docs/components-ui-form-elements-currency-selector.md +57 -73
  19. package/docs/components-ui-form-elements-phone-input.md +90 -112
  20. package/docs/components-ui-form-elements.md +46 -80
  21. package/docs/components-ui-payment-summary.md +71 -119
  22. package/docs/components-ui-pricing-table.md +117 -204
  23. package/docs/components-ui.md +59 -32
  24. package/docs/components.md +89 -62
  25. package/docs/getting-started.md +36 -63
  26. package/docs/guides-theming.md +122 -84
  27. package/docs/guides-utilities.md +107 -145
  28. package/docs/guides.md +7 -84
  29. package/docs/hooks-use-mobile.md +50 -36
  30. package/docs/hooks-use-subscription.md +72 -89
  31. package/docs/hooks.md +12 -82
  32. package/docs/overview.md +45 -52
  33. package/docs/providers-donate-provider.md +73 -95
  34. package/docs/providers-payment-provider.md +115 -169
  35. package/docs/providers.md +27 -86
  36. package/es/locales/en.js +7 -0
  37. package/es/locales/zh.js +8 -1
  38. package/es/payment/index.js +3 -0
  39. package/es/payment/progress-item.d.ts +12 -0
  40. package/es/payment/progress-item.js +78 -0
  41. package/es/payment/success.d.ts +4 -1
  42. package/es/payment/success.js +55 -3
  43. package/lib/locales/en.js +7 -0
  44. package/lib/locales/zh.js +8 -1
  45. package/lib/payment/index.js +3 -0
  46. package/lib/payment/progress-item.d.ts +12 -0
  47. package/lib/payment/progress-item.js +107 -0
  48. package/lib/payment/success.d.ts +4 -1
  49. package/lib/payment/success.js +59 -3
  50. package/package.json +3 -3
  51. package/src/locales/en.tsx +7 -0
  52. package/src/locales/zh.tsx +8 -1
  53. package/src/payment/index.tsx +6 -0
  54. package/src/payment/progress-item.tsx +107 -0
  55. package/src/payment/success.tsx +88 -3
@@ -1,104 +1,110 @@
1
1
  # CustomerInvoiceList
2
2
 
3
- The `CustomerInvoiceList` component renders a history of invoices for a specific customer or subscription. It supports two display formats: a compact list grouped by date (`list`) and a detailed, paginated table (`table`). The component can also display a 'Pay' button for open invoices, initiating the payment flow when clicked.
4
-
5
- To function correctly, especially for payment actions and real-time updates, this component must be wrapped within a `PaymentProvider`. For details on setting up the provider and the `useSessionContext` hook, please refer to the [PaymentProvider documentation](./providers-payment-provider.md).
3
+ The `CustomerInvoiceList` component is designed to render a customer's invoice history. It fetches and displays invoice data from the payment service, offering two distinct layouts: a simple, date-grouped list with infinite scroll, and a detailed, paginated table. This component must be used within a `PaymentProvider` to function correctly.
6
4
 
7
5
  ## Props
8
6
 
9
7
  | Prop | Type | Description | Default |
10
8
  | --- | --- | --- | --- |
11
9
  | `customer_id` | `string` | The ID of the customer whose invoices are to be displayed. | `''` |
12
- | `subscription_id` | `string` | The ID of the subscription for which to display invoices. | `''` |
13
- | `currency_id` | `string` | Filters invoices by a specific currency ID. | `''` |
10
+ | `subscription_id` | `string` | Filter invoices by a specific subscription ID. | `''` |
11
+ | `currency_id` | `string` | Filter invoices by a specific currency ID. | `''` |
14
12
  | `include_staking` | `boolean` | If `true`, includes staking-related invoices in the list. | `false` |
15
- | `include_return_staking` | `boolean` | If `true`, includes invoices for returned stakes. | `false` |
16
- | `include_recovered_from` | `boolean` | If `true`, includes invoices that were recovered from bad debt. | `false` |
17
- | `status` | `string` | A comma-separated string of invoice statuses to display (e.g., 'open,paid,uncollectible,void'). | `'open,paid,uncollectible'` |
18
- | `pageSize` | `number` | The number of invoices to display per page. | `10` |
19
- | `target` | `string` | The target attribute for invoice links (e.g., `_self`, `_blank`). | `'_self'` |
20
- | `action` | `string` | If set (e.g., to `'pay'`), a 'Pay' button is rendered for open or uncollectible invoices, triggering the payment flow on click. | `''` |
21
- | `type` | `'list'` \| `'table'` | Determines the rendering mode. `'list'` groups invoices by date, while `'table'` shows a detailed data grid. | `'list'` |
22
- | `onTableDataChange` | `(newData, oldData) => void` | A callback function that fires when the invoice data is loaded or refreshed. | `() => {}` |
23
- | `relatedSubscription` | `boolean` | When `type` is `'table'`, setting this to `true` adds a column showing the subscription related to each invoice. | `false` |
24
-
25
- ## Usage Scenarios
13
+ | `include_return_staking` | `boolean` | If `true`, includes return staking invoices. | `false` |
14
+ | `include_recovered_from` | `boolean` | If `true`, includes invoices that were recovered from a previous balance. | `false` |
15
+ | `status` | `string` | A comma-separated string of invoice statuses to display (e.g., `'open,paid,uncollectible'`). | `'open,paid,uncollectible'` |
16
+ | `pageSize` | `number` | The number of invoices to fetch per page. | `10` |
17
+ | `target` | `string` | The target attribute for invoice links (e.g., `'_self'`, `'_blank'`). | `'_self'` |
18
+ | `action` | `string` | Defines a call-to-action for certain invoices. Set to `'pay'` to show a pay button for open invoices. | `''` |
19
+ | `type` | `'list' \| 'table'` | The display mode for the invoice list. | `'list'` |
20
+ | `onTableDataChange` | `Function` | A callback function that is triggered when the invoice data changes. | `() => {}` |
21
+ | `relatedSubscription` | `boolean` | In `table` mode, if `true`, shows a column with a link to the related subscription. | `false` |
26
22
 
27
- ### Basic Invoice History
23
+ ## Basic Usage (List View)
28
24
 
29
- To display a simple list of invoices for a particular subscription, set the `subscription_id` and use the default `type='list'`. This mode is ideal for a quick overview of past transactions.
25
+ The default view (`type="list"`) renders a simple list of invoices, grouped by date, with an infinite scroll mechanism to load more items.
30
26
 
31
- ```tsx
27
+ ```tsx CustomerInvoiceListPage.tsx icon=logos:react
32
28
  import { PaymentProvider, CustomerInvoiceList } from '@blocklet/payment-react';
33
- import { useSessionContext } from '../hooks/session'; // Your local session context hook
34
29
 
35
- function InvoiceHistoryPage({ subscriptionId }) {
36
- const { session, connectApi } = useSessionContext();
30
+ function InvoiceHistoryPage() {
31
+ // Assuming customerId is available, e.g., from session or props
32
+ const customerId = 'cus_xxxxxxxxxxxxxx';
37
33
 
38
34
  return (
39
- <PaymentProvider session={session} connect={connectApi}>
40
- <h2>Invoice History</h2>
41
- <CustomerInvoiceList
42
- subscription_id={subscriptionId}
43
- status="paid,void"
44
- />
35
+ <PaymentProvider>
36
+ <CustomerInvoiceList customer_id={customerId} />
45
37
  </PaymentProvider>
46
38
  );
47
39
  }
48
40
  ```
49
41
 
50
- ### Detailed Invoice Table
42
+ ## Table View
51
43
 
52
- For a more detailed view, use `type='table'`. This mode provides pagination and multiple columns of data, making it suitable for dashboards or customer management pages. You can also add the `relatedSubscription` column for customers with multiple subscriptions.
44
+ For a more detailed and structured presentation, you can set `type="table"`. This mode displays invoices in a paginated table with sortable columns.
53
45
 
54
- ```tsx
46
+ ```tsx CustomerInvoiceTablePage.tsx icon=logos:react
55
47
  import { PaymentProvider, CustomerInvoiceList } from '@blocklet/payment-react';
56
- import { useSessionContext } from '../hooks/session'; // Your local session context hook
57
48
 
58
- function CustomerDashboard({ customerId }) {
59
- const { session, connectApi } = useSessionContext();
49
+ function InvoiceHistoryTable() {
50
+ const customerId = 'cus_xxxxxxxxxxxxxx';
60
51
 
61
52
  return (
62
- <PaymentProvider session={session} connect={connectApi}>
63
- <h3>All Invoices</h3>
53
+ <PaymentProvider>
64
54
  <CustomerInvoiceList
65
55
  customer_id={customerId}
66
56
  type="table"
67
- pageSize={20}
68
- include_staking={true}
69
- relatedSubscription={true}
70
- status="open,paid,uncollectible,void"
57
+ relatedSubscription={true} // Show a column for the related subscription
58
+ pageSize={5}
71
59
  />
72
60
  </PaymentProvider>
73
61
  );
74
62
  }
75
63
  ```
76
64
 
77
- ### Invoices with Payment Action
65
+ In this example, the `relatedSubscription` prop is enabled to add a column that links directly to the subscription associated with each invoice, which is useful for subscription-based services.
78
66
 
79
- By setting the `action` prop, you can enable a 'Pay' button for any invoices that are `open` or `uncollectible`. Clicking this button will open the payment modal provided by `PaymentProvider` to complete the transaction.
67
+ ## Filtering Invoices
80
68
 
81
- ```tsx
69
+ You can use various props to filter the invoices displayed. For example, to show only paid invoices related to staking:
70
+
71
+ ```tsx FilteredInvoiceListPage.tsx icon=logos:react
82
72
  import { PaymentProvider, CustomerInvoiceList } from '@blocklet/payment-react';
83
- import { useSessionContext } from '../hooks/session'; // Your local session context hook
84
73
 
85
- function PayInvoices({ customerId }) {
86
- const { session, connectApi } = useSessionContext();
74
+ function FilteredInvoiceList() {
75
+ const customerId = 'cus_xxxxxxxxxxxxxx';
87
76
 
88
77
  return (
89
- <PaymentProvider session={session} connect={connectApi}>
90
- <h3>Outstanding Invoices</h3>
78
+ <PaymentProvider>
91
79
  <CustomerInvoiceList
92
80
  customer_id={customerId}
93
- status="open,uncollectible"
94
- action="pay" // This enables the "Pay" button
95
81
  type="table"
82
+ status="paid" // Only show paid invoices
83
+ include_staking={true} // Also include staking transactions
96
84
  />
97
85
  </PaymentProvider>
98
86
  );
99
87
  }
100
88
  ```
101
89
 
102
- ### Real-time Updates
90
+ ## Enabling Payments for Open Invoices
91
+
92
+ By setting the `action` prop to `'pay'`, you can add a "Pay" button to any invoices with `open` or `uncollectible` status. Clicking this button will initiate the payment flow using the `connect` instance from `PaymentProvider`.
93
+
94
+ ```tsx PayableInvoiceListPage.tsx icon=logos:react
95
+ import { PaymentProvider, CustomerInvoiceList } from '@blocklet/payment-react';
96
+
97
+ function PayableInvoiceList() {
98
+ const customerId = 'cus_xxxxxxxxxxxxxx';
103
99
 
104
- The component automatically subscribes to the `invoice.paid` WebSocket event. When a customer successfully pays an invoice, the list will refresh in real-time to reflect the new `paid` status without requiring a page reload. This ensures that the invoice data is always up-to-date.
100
+ return (
101
+ <PaymentProvider>
102
+ <CustomerInvoiceList
103
+ customer_id={customerId}
104
+ status="open,uncollectible" // Show only invoices that need payment
105
+ action="pay" // Add a "Pay" button
106
+ />
107
+ </PaymentProvider>
108
+ );
109
+ }
110
+ ```
@@ -1,65 +1,44 @@
1
1
  # CustomerPaymentList
2
2
 
3
- The `CustomerPaymentList` component renders a detailed history of a customer's payments. It is designed for efficiency, featuring infinite scrolling to handle large numbers of transactions without compromising performance. Payments are automatically grouped by date for easy navigation and review.
3
+ The `CustomerPaymentList` component renders a detailed history of a customer's payments. It automatically handles fetching, pagination via infinite scroll, and grouping of payments by date, providing a clear and organized view of a user's transaction history.
4
+
5
+ This component is ideal for user dashboards or account pages where customers need to review their past transactions.
4
6
 
5
7
  ## Props
6
8
 
7
- | Prop | Type | Description | Required |
9
+ | Prop | Type | Required | Description |
8
10
  |---|---|---|---|
9
- | `customer_id` | `string` | The ID of the customer whose payment history should be displayed. | Yes |
11
+ | `customer_id` | `string` | Yes | The unique identifier for the customer (e.g., the user's DID) whose payment history you want to display. |
10
12
 
11
13
  ## Usage Example
12
14
 
13
- To use the `CustomerPaymentList`, you must provide a `customer_id`. The component handles all the logic for fetching, paginating, and displaying the payment data. It must be wrapped within a `PaymentProvider` to function correctly.
15
+ To use the `CustomerPaymentList`, you must wrap it in a `PaymentProvider` and provide the required `customer_id`.
14
16
 
15
- ```tsx
17
+ ```tsx Customer Payment History icon=logos:react
16
18
  import { PaymentProvider, CustomerPaymentList } from '@blocklet/payment-react';
17
- import { useSessionContext } from '../hooks/session'; // This is your app's custom session hook
18
- import { Box, Typography } from '@mui/material';
19
+ import { useSessionContext } from './hooks/useSessionContext'; // Adjust path to your session context hook
19
20
 
20
- function CustomerProfilePage() {
21
- // Get session and connectApi from your application's session context.
21
+ export default function CustomerDashboard() {
22
22
  const { session, connectApi } = useSessionContext();
23
23
 
24
- // The customer ID would typically be the DID of the logged-in user.
25
- const customerDid = session?.user?.did;
26
-
27
- if (!session || !customerDid) {
28
- return <Typography>Please log in to view payment history.</Typography>;
24
+ // Ensure the user is logged in to get their DID
25
+ if (!session?.user?.did) {
26
+ return <div>Please log in to view your payment history.</div>;
29
27
  }
30
28
 
31
29
  return (
32
30
  <PaymentProvider session={session} connect={connectApi}>
33
- <Box sx={{ p: 3 }}>
34
- <Typography variant="h5" gutterBottom>
35
- Payment History
36
- </Typography>
37
- <CustomerPaymentList customer_id={customerDid} />
38
- </Box>
31
+ <h2>My Payment History</h2>
32
+ <CustomerPaymentList customer_id={session.user.did} />
39
33
  </PaymentProvider>
40
34
  );
41
35
  }
42
-
43
- export default CustomerProfilePage;
44
36
  ```
45
37
 
46
- In the example above, `useSessionContext` is a custom hook responsible for providing your application's session state. For detailed instructions on how to set up the `PaymentProvider` and create a session context, please refer to our guide on the [PaymentProvider](./providers-payment-provider.md).
47
-
48
38
  ## Features
49
39
 
50
- - **Automatic Pagination**: The component automatically fetches and renders payments in pages. A "Load More" button appears when more transactions are available, allowing users to load history on demand.
51
-
52
- - **Date-Based Grouping**: To improve readability, all payments are grouped under the date they were created, making it easy to find transactions from a specific day.
53
-
54
- - **Detailed Payment Information**: Each row in the list provides key details about the transaction:
55
- - **Date & Time**: The exact creation time of the payment.
56
- - **Amount**: The total amount received, formatted with the correct currency symbol.
57
- - **Status**: The current status of the payment (e.g., `succeeded`, `processing`) shown with a colored indicator using the `Status` component.
58
- - **Description**: The description associated with the payment intent.
59
- - **Transaction Link**: A direct link to the relevant blockchain explorer for on-chain transactions, if applicable.
60
-
61
- - **Loading and Empty States**: A loading indicator is displayed while the initial payment data is being fetched. If the customer has no payment history, a clear message is shown instead of an empty list.
62
-
63
- ## Related Components
64
-
65
- For displaying a customer's invoice history, which is often related to their payment history, see the [`CustomerInvoiceList`](./components-history-invoice-list.md) component.
40
+ - **Automatic Data Fetching**: The component fetches payment intents from the API endpoint `/api/payment-intents`.
41
+ - **Infinite Scroll**: It automatically loads more payments as the user requests them, ensuring efficient data handling for long payment histories.
42
+ - **Date Grouping**: Payments are visually grouped by date, making the list easy to scan.
43
+ - **Detailed Information**: For each payment, it displays the creation time, amount, status, description, and a link to the blockchain transaction if available.
44
+ - **Loading and Empty States**: It includes a loading indicator during data fetching and displays a user-friendly message if the customer has no payment history.
@@ -1,92 +1,67 @@
1
1
  # History Components
2
2
 
3
- The History Components are a suite of tools designed to give customers a clear and detailed view of their financial interactions. They are essential for building transparent and user-friendly account management sections, such as a customer portal or a billing history page. These components fetch and display data related to invoices, payments, and credit balances, providing a complete historical record.
3
+ The `@blocklet/payment-react` library provides a suite of history components designed to give your users a clear and detailed view of their past activities. These components are essential for building customer portals, account dashboards, and administrative interfaces where users need to track their billing, payments, and credit usage.
4
4
 
5
- ```d2
6
- direction: down
7
-
8
- "Customer Portal" -> "Billing Section"
9
-
10
- "Billing Section": {
11
- "Invoices": "CustomerInvoiceList"
12
- "Payments": "CustomerPaymentList"
13
- "Credits": {
14
- "Grants": "CreditGrantsList"
15
- "Usage": "CreditTransactionsList"
16
- }
17
- }
18
- ```
19
-
20
- This section provides an overview of the components available for displaying historical data. Each component is designed to be easily integrated into your application to provide a specific piece of a customer's history.
5
+ These components fetch and display data directly from the payment service, offering a seamless way to present historical information without needing to build complex data-fetching and rendering logic from scratch.
21
6
 
22
7
  <x-cards data-columns="2">
23
- <x-card data-title="CustomerInvoiceList" data-icon="lucide:receipt" data-href="/components/history/invoice-list">
24
- Renders a list of a customer's invoices, including key details like the amount, status, date, and a link to view the full invoice. It supports both a simple list view and a more detailed table view.
8
+ <x-card data-title="CustomerInvoiceList" data-icon="lucide:receipt-text" data-href="/components/history/invoice-list">
9
+ Render a list or table of a customer's invoices, including details on status, amount, and creation date.
25
10
  </x-card>
26
11
  <x-card data-title="CustomerPaymentList" data-icon="lucide:credit-card" data-href="/components/history/payment-list">
27
- Use this component to display a complete history of payments made by a customer. It lists each payment with its amount, status, date, and a link to the corresponding transaction on the blockchain, if applicable.
12
+ Display a customer's complete payment history, including transaction details, payment method, and status.
28
13
  </x-card>
29
- <x-card data-title="CreditGrantsList" data-icon="lucide:gift" data-href="/components/history/credit-grants-list">
30
- The `CreditGrantsList` component shows all credit grants a customer has received. It details the status, remaining balance, and validity period of each grant, which is useful for managing promotional credits or prepaid balances.
14
+ <x-card data-title="CreditGrantsList" data-icon="lucide:award" data-href="/components/history/credit-grants-list">
15
+ Show a list of all credit grants for a customer, detailing the status, remaining amount, and effective dates.
31
16
  </x-card>
32
- <x-card data-title="CreditTransactionsList" data-icon="lucide:list-ordered" data-href="/components/history/credit-transactions-list">
33
- To provide a granular view of how credits are used, the `CreditTransactionsList` component logs every transaction that affects a customer's credit balance. This includes credit deductions for service usage and any adjustments.
17
+ <x-card data-title="CreditTransactionsList" data-icon="lucide:history" data-href="/components/history/credit-transactions-list">
18
+ List all individual credit transactions, providing a detailed log of credit usage and adjustments over time.
34
19
  </x-card>
35
20
  </x-cards>
36
21
 
37
- ### Example: Building a Billing Page
22
+ ## Common Use Case
38
23
 
39
- You can easily combine these components using a tabbed interface to create a complete billing history section for your users. Most history components rely on `PaymentProvider` to access the DID Connect instance for actions like paying an invoice.
24
+ A typical use case is to create a "Billing History" section in a user's account page. You can use a tabbed interface to switch between different history views, such as Invoices, Payments, and Credits.
40
25
 
41
- The following example shows how to set up a complete billing page. It assumes you have a local `session.js` or `session.ts` file that exports `useSessionContext` for your DID Connect integration. For more details on setting up the provider, see the [PaymentProvider documentation](./providers-payment-provider.md).
26
+ Below is a conceptual example of how you might structure such a page.
42
27
 
43
- ```jsx
28
+ ```jsx MyBillingPage.tsx icon=lucide:user
44
29
  import React from 'react';
45
- import { Tabs, Tab, Box, Typography } from '@mui/material';
46
- import { PaymentProvider } from '@blocklet/payment-react/lib/contexts/payment';
47
- import { useSessionContext } from '../contexts/session'; // Your local session context
48
-
49
- import CustomerInvoiceList from '@blocklet/payment-react/lib/history/invoice/list';
50
- import CustomerPaymentList from '@blocklet/payment-react/lib/history/payment/list';
51
- import CreditGrantsList from '@blocklet/payment-react/lib/history/credit/grants-list';
52
- import CreditTransactionsList from '@blocklet/payment-react/lib/history/credit/transactions-list';
53
-
54
- function BillingHistoryPage() {
55
- const { session, connect } = useSessionContext();
56
- const [tab, setTab] = React.useState(0);
57
-
58
- const handleChange = (event, newValue) => {
59
- setTab(newValue);
60
- };
30
+ import { CustomerInvoiceList, CustomerPaymentList } from '@blocklet/payment-react';
61
31
 
62
- // The customerId is the user's DID from the session.
63
- const customerId = session.user?.did;
32
+ // Assume you have the customer's ID from your session or context
33
+ const customerId = 'cus_xxxxxxxxxxxxxx';
64
34
 
65
- if (!session.ready || !customerId) {
66
- return <Typography>Please log in to view your billing history.</Typography>;
67
- }
35
+ export default function MyBillingPage() {
36
+ // In a real application, you would use state to manage the active tab
37
+ const [activeTab, setActiveTab] = React.useState('invoices');
68
38
 
69
39
  return (
70
- <PaymentProvider connect={connect}>
71
- <Box sx={{ width: '100%' }}>
72
- <Tabs value={tab} onChange={handleChange} aria-label="billing history tabs">
73
- <Tab label="Invoices" />
74
- <Tab label="Payments" />
75
- <Tab label="Credit Grants" />
76
- <Tab label="Credit Usage" />
77
- </Tabs>
78
- <Box sx={{ p: 3 }}>
79
- {tab === 0 && <CustomerInvoiceList customer_id={customerId} type="table" />}
80
- {tab === 1 && <CustomerPaymentList customer_id={customerId} />}
81
- {tab === 2 && <CreditGrantsList customer_id={customerId} />}
82
- {tab === 3 && <CreditTransactionsList customer_id={customerId} />}
83
- </Box>
84
- </Box>
85
- </PaymentProvider>
40
+ <div>
41
+ <h1>Billing History</h1>
42
+ <nav>
43
+ <button onClick={() => setActiveTab('invoices')}>Invoices</button>
44
+ <button onClick={() => setActiveTab('payments')}>Payments</button>
45
+ </nav>
46
+
47
+ <div style={{ marginTop: '20px' }}>
48
+ {activeTab === 'invoices' && (
49
+ <CustomerInvoiceList
50
+ customer_id={customerId}
51
+ type="table"
52
+ />
53
+ )}
54
+ {activeTab === 'payments' && (
55
+ <CustomerPaymentList
56
+ customer_id={customerId}
57
+ />
58
+ )}
59
+ </div>
60
+ </div>
86
61
  );
87
62
  }
88
63
  ```
89
64
 
90
- By using these components, you can build a comprehensive and professional billing history section. This not only improves user experience but also reduces support inquiries by providing customers with self-service access to their data.
65
+ This example demonstrates how you can easily embed the history components to provide comprehensive, self-service billing information to your users. Each component handles its own data fetching, pagination, and display logic.
91
66
 
92
- After implementing history views, you may want to explore advanced topics like customization and theming. Continue to the next section to learn more in our [Guides](./guides.md).
67
+ Explore the detailed documentation for each component to understand its specific props and customization options.
@@ -1,66 +1,56 @@
1
1
  # AddressForm
2
2
 
3
- The `AddressForm` component provides a pre-built UI for collecting billing address details. It includes fields for address line 1, city, state, postal code, and country, with built-in validation that adapts based on the selected country.
3
+ The `AddressForm` component provides a pre-built UI for collecting billing address information. It integrates seamlessly with `react-hook-form` and includes built-in, country-specific validation for fields like postal codes.
4
4
 
5
- This component is designed to work seamlessly within the context of `react-hook-form`.
5
+ This component is designed to be flexible, supporting both full address collection and a simplified version for Stripe postal code verification.
6
6
 
7
7
  ## Props
8
8
 
9
- | Prop | Type | Description | Required |
10
- | --- | --- | --- | :---: |
11
- | `mode` | `string` | Determines the form's behavior. Set to `'required'` to display the full address form. | Yes |
12
- | `stripe` | `boolean` | If `true` and `mode` is not `'required'`, it displays a simplified form with only postal code and country. | Yes |
13
- | `sx` | `SxProps` | Custom MUI styles to be applied to the root `Stack` component. | No |
14
- | `fieldValidation` | `Record<string, any>` | An object for providing custom validation rules, such as regex patterns, for specific fields. | No |
15
- | `errorPosition` | `'right'` \| `'bottom'` | Specifies the position of validation error messages relative to the input fields. Defaults to `'right'`. | No |
9
+ | Prop | Type | Description | Default |
10
+ | ----------------- | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
11
+ | `mode` | `string` | Determines the fields to display. Set to `'required'` to show the complete address form (line 1, city, state, postal code, country). | `undefined` |
12
+ | `stripe` | `boolean` | If `true`, displays a simplified form with only the postal code and country, typically used for card validation with Stripe. | `false` |
13
+ | `sx` | `SxProps` | MUI's `sx` prop for custom styling of the root `Stack` component. | `{}` |
14
+ | `fieldValidation` | `Record<string, any>` | An object for providing custom validation rules, such as regex patterns, for specific fields. See the validation section for details. | `{}` |
15
+ | `errorPosition` | `'right'` \| `'bottom'` | Specifies where to display validation error messages relative to the input field. | `'right'` |
16
16
 
17
- ## Integration with React Hook Form
17
+ ## Usage
18
18
 
19
- `AddressForm` uses `useFormContext` and therefore must be a descendant of a `FormProvider` component from `react-hook-form`. In a typical application, a higher-level component like `CheckoutForm` would wrap your feature and provide this context automatically.
19
+ `AddressForm` must be used within a `FormProvider` from `react-hook-form` because it relies on its context to register fields and manage state.
20
20
 
21
- Note: The following examples assume you have set up `PaymentProvider` and a local `useSessionContext` hook as described in the [PaymentProvider documentation](./providers-payment-provider.md).
21
+ ### Standard Billing Address
22
22
 
23
- ## Usage Scenarios
23
+ To collect a full billing address, set the `mode` prop to `'required'`. This will render all standard address fields, each with a 'required' validation rule.
24
24
 
25
- ### Complete Address Form
26
-
27
- To collect a full billing address, set the `mode` prop to `'required'`. This will render all address fields as mandatory.
28
-
29
- ```jsx
25
+ ```tsx AddressForm with Full Address icon=material-symbols:location-on-outline
30
26
  import { FormProvider, useForm } from 'react-hook-form';
31
- import { AddressForm } from '@blocklet/payment-react';
32
27
  import { Button, Stack } from '@mui/material';
33
- import { useSessionContext } from '../hooks/session'; // Adjust path to your session hook
34
-
35
- export default function FullAddressFormExample() {
36
- // Standard context setup. Not used in this specific form but required for consistency.
37
- const { session, connectApi } = useSessionContext();
28
+ import AddressForm from './AddressForm'; // Adjust the import path
38
29
 
30
+ export default function FullAddressExample() {
39
31
  const methods = useForm({
40
- mode: 'onTouched',
41
32
  defaultValues: {
42
33
  billing_address: {
43
34
  line1: '',
44
35
  city: '',
45
36
  state: '',
46
37
  postal_code: '',
47
- country: 'US',
38
+ country: 'US', // Default country
48
39
  },
49
40
  },
50
41
  });
51
42
 
52
43
  const onSubmit = (data) => {
53
- alert('Form Submitted! Check console for data.');
54
- console.log('Billing Address:', data.billing_address);
44
+ console.log('Form data:', data);
55
45
  };
56
46
 
57
47
  return (
58
48
  <FormProvider {...methods}>
59
49
  <form onSubmit={methods.handleSubmit(onSubmit)}>
60
50
  <Stack spacing={2}>
61
- <AddressForm mode="required" stripe={false} errorPosition="bottom" />
51
+ <AddressForm mode="required" />
62
52
  <Button type="submit" variant="contained">
63
- Submit Address
53
+ Submit
64
54
  </Button>
65
55
  </Stack>
66
56
  </form>
@@ -69,40 +59,36 @@ export default function FullAddressFormExample() {
69
59
  }
70
60
  ```
71
61
 
72
- ### Simplified Stripe Form
62
+ This setup renders input fields for the address line, city, state, and postal code. The country is selected via the integrated [CountrySelect](./components-ui-form-elements-country-select.md) component.
63
+
64
+ ### Stripe Postal Code Verification
73
65
 
74
- In some payment flows, particularly with Stripe, only the postal code and country might be required for verification. To render this simplified version, ensure `mode` is not `'required'` and set the `stripe` prop to `true`.
66
+ When using payment methods like Stripe, you often only need the postal code and country for card verification. Set the `stripe` prop to `true` to render a simplified form containing only these two fields.
75
67
 
76
- ```jsx
68
+ ```tsx AddressForm for Stripe icon=logos:stripe
77
69
  import { FormProvider, useForm } from 'react-hook-form';
78
- import { AddressForm } from '@blocklet/payment-react';
79
70
  import { Button, Stack } from '@mui/material';
80
- import { useSessionContext } from '../hooks/session'; // Adjust path to your session hook
81
-
82
- export default function StripeAddressFormExample() {
83
- // Standard context setup. Not used in this specific form but required for consistency.
84
- const { session, connectApi } = useSessionContext();
71
+ import AddressForm from './AddressForm'; // Adjust the import path
85
72
 
73
+ export default function StripeAddressExample() {
86
74
  const methods = useForm({
87
- mode: 'onTouched',
88
75
  defaultValues: {
89
76
  billing_address: {
90
77
  postal_code: '',
91
- country: 'US',
78
+ country: 'US', // Default country
92
79
  },
93
80
  },
94
81
  });
95
82
 
96
83
  const onSubmit = (data) => {
97
- alert('Form Submitted! Check console for data.');
98
- console.log('Billing Info:', data.billing_address);
84
+ console.log('Form data:', data);
99
85
  };
100
86
 
101
87
  return (
102
88
  <FormProvider {...methods}>
103
89
  <form onSubmit={methods.handleSubmit(onSubmit)}>
104
90
  <Stack spacing={2}>
105
- <AddressForm mode="optional" stripe={true} errorPosition="bottom" />
91
+ <AddressForm stripe={true} />
106
92
  <Button type="submit" variant="contained">
107
93
  Submit
108
94
  </Button>
@@ -115,36 +101,22 @@ export default function StripeAddressFormExample() {
115
101
 
116
102
  ## Validation
117
103
 
118
- `AddressForm` handles validation for required fields automatically. It also includes special validation logic for postal codes.
104
+ The component includes automatic validation for required fields. The most notable feature is the dynamic postal code validation, which adjusts its rules based on the selected country.
119
105
 
120
- ### Postal Code Validation
106
+ - **Required Fields**: All visible fields are automatically marked as required.
107
+ - **Postal Code**: The validation logic uses the `validator/lib/isPostalCode` library. It checks the postal code format against the selected country's standard format (e.g., 5 digits for the US, alphanumeric for Canada). If a country's format is not explicitly supported, a general validation is applied.
108
+ - **Custom Validation**: You can pass additional validation rules via the `fieldValidation` prop. For example, to enforce a specific pattern on the `state` field:
121
109
 
122
- The postal code field is dynamically validated based on the selected country. The component uses the `validator.js` library to check if the postal code format is valid for a list of supported countries. For countries not on the supported list, a generic validation is applied.
123
-
124
- ### Custom Validation
125
-
126
- You can extend the default validation by passing a `fieldValidation` object. This allows you to specify custom regex patterns and error messages for any address field.
127
-
128
- For example, to add a pattern validation for the state field to accept only two-letter abbreviations:
129
-
130
- ```jsx
110
+ ```tsx
131
111
  const customValidation = {
132
112
  'billing_address.state': {
133
113
  pattern: '^[A-Z]{2}$',
134
114
  pattern_message: {
135
- en: 'State must be a 2-letter abbreviation.',
136
- // Add other locales as needed
115
+ en: 'State must be a 2-letter code.',
137
116
  },
138
117
  },
139
118
  };
140
119
 
141
- <AddressForm
142
- mode="required"
143
- stripe={false}
144
- fieldValidation={customValidation}
145
- />
120
+ <AddressForm mode="required" fieldValidation={customValidation} />;
146
121
  ```
147
122
 
148
- ## Related Components
149
-
150
- - **[CountrySelect](./components-ui-form-elements-country-select.md)**: The `AddressForm` uses this component internally to provide a searchable, user-friendly country dropdown with flags.