feat: add transactionType key for charge creation #880
Conversation
kushagrasarathe
commented
May 29, 2025
kushagrasarathe
commented
- contributes to TASK-10750
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
## Walkthrough
This set of changes introduces a new transaction type, 'WITHDRAW', across transaction history, payment initiation, and charge creation flows. It updates UI components to improve loading, error, and empty states, and aligns transaction display logic and titles with the new type. Several components and types are extended to support and properly render 'WITHDRAW' transactions. Additionally, wallet connection management and drawer behavior were refined.
## Changes
| File(s) | Change Summary |
|-----------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|
| src/services/services.types.ts | Added `TChargeTransactionType` type and optional `transactionType` to `CreateChargeRequest`. |
| src/hooks/usePaymentInitiator.ts | Allowed `InitiatePaymentPayload` to include `transactionType`; propagated this to charge creation.|
| src/components/Payment/PaymentForm/index.tsx, src/components/Payment/Views/Confirm.payment.view.tsx | Added `transactionType` to payment initiation payloads, set based on flow context. |
| src/app/(mobile-ui)/withdraw/crypto/page.tsx | Added `transactionType: 'WITHDRAW'` to charge creation payload. |
| src/hooks/useTransactionHistory.ts | Added 'WITHDRAW' to `EHistoryEntryType`; updated amount and symbol formatting; integrated new type.|
| src/components/TransactionDetails/transactionTransformer.ts | Mapped 'WITHDRAW' entries to new direction/card type and peer name logic. |
| src/components/TransactionDetails/TransactionAvatarBadge.tsx | Added icon handling for 'withdraw'; commented out color logic for 'add'. |
| src/components/TransactionDetails/TransactionDetailsHeaderCard.tsx | Made title text for 'withdraw' and 'add' conditional on transaction status. |
| src/components/Home/HomeHistory.tsx | Replaced loading, error, and empty states with structured components and skeleton loaders; added `HistorySkeleton` export. |
| src/app/(mobile-ui)/history/page.tsx | Updated error display to use structured `EmptyState` component and heading. |
| src/app/(mobile-ui)/home/page.tsx | Added logic to auto-disconnect external wallet on home page load using wagmi/appkit hooks. |
| src/app/[...recipient]/client.tsx | Refactored effect logic to prevent drawer opening during add money flow. |
| src/components/Payment/Views/Status.payment.view.tsx | Minor string adjustment in title for 'SEND' type. |
| src/components/Setup/Views/InstallPWA.tsx | Added effect to auto-show install modal on supported desktop browsers. |
| src/components/TransactionDetails/TransactionDetailsDrawer.tsx | Modified condition controlling bottom border display on transaction date row. |
| src/utils/sdkErrorHandler.utils.tsx | Added handling for "Insufficient balance" error message. |
## Possibly related PRs
- [peanutprotocol/peanut-ui#863](https://github.com/peanutprotocol/peanut-ui/pull/863): Modifies payment initiation payload by adding `chargeId`; related through payment initiation logic.
- [peanutprotocol/peanut-ui#663](https://github.com/peanutprotocol/peanut-ui/pull/663): Also modifies error and loading UI in the `HistoryPage` component, affecting similar rendering logic.
- [peanutprotocol/peanut-ui#797](https://github.com/peanutprotocol/peanut-ui/pull/797): Refactors data fetching and loading states in the `HistoryPage` component, related to UI but different concerns.
## Suggested reviewers
- Hugo0
- jjramirezn✨ Finishing Touches
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. 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/app/(mobile-ui)/home/page.tsx (1)
19-19: Auto-disconnect behavior implemented correctly.The wallet connection management logic is properly implemented. The useEffect correctly disconnects external wallets when the home page loads, and the dependencies are appropriate.
Consider documenting the business rationale for this auto-disconnect behavior - it might not be immediately obvious to future developers why external wallets are automatically disconnected on the home page.
Also applies to: 24-24, 34-35, 69-74
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
src/app/(mobile-ui)/history/page.tsx(2 hunks)src/app/(mobile-ui)/home/page.tsx(3 hunks)src/app/(mobile-ui)/withdraw/crypto/page.tsx(1 hunks)src/app/[...recipient]/client.tsx(1 hunks)src/components/Home/HomeHistory.tsx(3 hunks)src/components/Payment/PaymentForm/index.tsx(3 hunks)src/components/Payment/Views/Confirm.payment.view.tsx(1 hunks)src/components/TransactionDetails/TransactionAvatarBadge.tsx(2 hunks)src/components/TransactionDetails/TransactionDetailsHeaderCard.tsx(1 hunks)src/components/TransactionDetails/transactionTransformer.ts(1 hunks)src/hooks/usePaymentInitiator.ts(3 hunks)src/hooks/useTransactionHistory.ts(4 hunks)src/services/services.types.ts(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (4)
src/app/(mobile-ui)/history/page.tsx (1)
src/components/Global/EmptyStates/EmptyState.tsx (1)
EmptyState(13-28)
src/hooks/usePaymentInitiator.ts (1)
src/services/services.types.ts (1)
TChargeTransactionType(101-101)
src/hooks/useTransactionHistory.ts (2)
src/constants/general.consts.ts (1)
BASE_URL(43-43)src/utils/general.utils.ts (1)
formatAmount(300-340)
src/components/Payment/PaymentForm/index.tsx (1)
src/hooks/usePaymentInitiator.ts (1)
InitiatePaymentPayload(36-51)
🔇 Additional comments (26)
src/services/services.types.ts (2)
101-101: LGTM! Well-defined transaction type enum.The
TChargeTransactionTypeunion type clearly defines the four transaction types and follows TypeScript best practices for string literal unions.
111-111: Good addition of optional transaction type property.Adding the
transactionTypeas an optional property maintains backward compatibility while enabling enhanced transaction classification.src/components/Payment/Views/Confirm.payment.view.tsx (1)
156-156: Correct conditional logic for transaction type.The transaction type is appropriately set based on the payment flow - 'DEPOSIT' for add money flows and 'REQUEST' for standard payment requests.
src/app/(mobile-ui)/withdraw/crypto/page.tsx (1)
127-127: Correctly identifies withdrawal transactions.Setting
transactionType: 'WITHDRAW'appropriately classifies this charge creation as a withdrawal operation, aligning with the new transaction type system.src/components/TransactionDetails/TransactionAvatarBadge.tsx (1)
50-53: Good implementation of withdraw transaction type.The withdraw case correctly uses the 'wallet-outline' icon and clears initials, following the established pattern for other transaction types.
src/app/(mobile-ui)/history/page.tsx (2)
4-4: LGTM: Import addition aligns with UI consistency improvements.The EmptyState component import supports the enhanced error display structure.
69-75: Excellent UI consistency improvement!The structured error display using EmptyState component provides better visual hierarchy and user experience compared to the previous simple centered text. This aligns well with the similar improvements mentioned in the AI summary for
HomeHistory.tsx.src/components/TransactionDetails/TransactionDetailsHeaderCard.tsx (2)
70-70: Good consistency improvement for withdraw transaction titles.Making the title conditional on transaction status improves accuracy - using past tense "Withdrew" for completed transactions and present continuous "Withdrawing" for pending ones aligns with the existing pattern used for other transaction directions.
73-73: Good consistency improvement for add transaction titles.The conditional title logic matches the pattern established for other transaction types and improves user understanding by using appropriate tense based on transaction status.
src/hooks/usePaymentInitiator.ts (3)
24-24: Good import addition for transaction type support.The TChargeTransactionType import enables explicit transaction categorization throughout the payment flow.
50-50: Well-designed interface extension.Adding the optional
transactionTypeproperty maintains backward compatibility while enabling explicit transaction categorization. This aligns with the broader PR objective of adding transaction type tracking.
526-526: Proper propagation of transaction type to charge creation.The transactionType is correctly passed through to the charge creation payload, enabling end-to-end transaction type tracking from initiation to backend processing.
src/app/[...recipient]/client.tsx (1)
300-310: Good refactoring that improves control flow clarity.The simplified conditional logic is more readable and the separation of concerns is cleaner:
- The compound condition on line 300 combines the previously nested checks
- The transaction details drawer opening is now properly conditional on flow type (lines 307-309)
This prevents unwanted drawer behavior during add money flows while maintaining correct state transitions.
src/components/TransactionDetails/transactionTransformer.ts (1)
148-153: LGTM! Well-structured addition of WITHDRAW transaction type handling.The new WITHDRAW case follows the established patterns in the codebase and properly sets the transaction properties. The fallback to 'External Account' is appropriate for withdraw transactions and distinguishes them from cashout operations which use 'Bank Account'.
src/hooks/useTransactionHistory.ts (4)
18-18: WITHDRAW transaction type added correctly.The new
WITHDRAWenum value is properly integrated into theEHistoryEntryTypeenum and follows the existing naming convention.
1-3: Import refactoring improves consistency.The updated imports remove unused dependencies (
PEANUT_WALLET_TOKEN_DECIMALS,formatUnits) and add theformatAmountutility, which aligns with the standardized amount formatting throughout the file.
161-162: Standardized amount handling across all transaction types.The refactoring to use
entry.amount.toString()consistently across all transaction types (SEND_LINK, REQUEST, DIRECT_SEND, DEPOSIT, WITHDRAW) improves maintainability and reduces complexity. The new WITHDRAW case follows the established pattern correctly.Also applies to: 167-167, 170-172, 173-176, 177-180, 182-186
196-196: Enhanced amount formatting with formatAmount utility.The use of
formatAmountutility for usdAmount formatting is consistent with the broader refactoring and leverages the helper function fromsrc/utils/general.utils.tswhich handles edge cases like small numbers and decimal precision properly.src/components/Payment/PaymentForm/index.tsx (2)
27-27: Good addition of explicit type import.Adding the
InitiatePaymentPayloadtype import improves type safety and makes the code more maintainable.
370-370: Proper typing and transactionType logic implementation.The explicit typing of the payload as
InitiatePaymentPayloadis excellent for type safety. The conditional logic fortransactionTypecorrectly maps different flow types:
- 'DEPOSIT' for add money flows
- 'DIRECT_SEND' for direct payments
- 'REQUEST' for payment requests (default)
This aligns well with the interface definition in
src/hooks/usePaymentInitiator.tsand ensures consistent transaction categorization.Also applies to: 379-379
src/components/Home/HomeHistory.tsx (6)
13-14: LGTM! Import additions support the UI improvements.The new imports for
Card,CardPosition,getCardPosition, andEmptyStatecomponents are appropriate for the enhanced loading and empty state implementations.
69-79: Excellent skeleton loading implementation!The replacement of a simple loading spinner with skeleton cards provides much better UX by showing the expected layout structure. The use of
Array.from({ length: 5 })andgetCardPositionfor consistent styling is well-implemented.
85-91: Good standardization with EmptyState component.The error state now uses a consistent
EmptyStatecomponent with appropriate icon and messaging, which improves UI consistency across the application. The error logging with Sentry is also properly maintained.
96-103: Consistent empty state implementation.The empty state follows the same pattern as the error state, using the
EmptyStatecomponent with appropriate messaging and icon. This provides a cohesive user experience.
108-108: Reasonable padding adjustment.The reduction from
pb-28topb-4when logged in appears more appropriate and likely prevents excessive bottom spacing that could push content unnecessarily far from the bottom of the viewport.
182-192: Well-implemented skeleton component.The
HistorySkeletoncomponent effectively mimics the structure of actual transaction cards with:
- Proper use of
CardPositionfor consistent styling- Animated pulse effects using
animate-pulse- Appropriate dimensions and spacing that match the actual content layout
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/components/Setup/Views/InstallPWA.tsx (1)
120-128: Consider the UX implications of auto-showing modals.The implementation is technically sound with proper cleanup and dependency management. However, automatically showing modals without user interaction can be intrusive and may violate accessibility guidelines, particularly for users with screen readers or those who prefer to control when UI elements appear.
Given that this is specifically for desktop users in a PWA installation flow (showing mobile-first messaging), the behavior might be acceptable, but consider:
- Adding a user preference to disable auto-show behavior
- Ensuring the modal is properly announced to screen readers
- Providing clear escape mechanisms (ESC key support)
Consider adding an escape key handler and ensuring proper ARIA attributes:
useEffect(() => { // show modal by default on desktop if (deviceType === 'desktop' && !isUnsupportedBrowser) { const timer = setTimeout(() => { setShowModal(true) }, 500) return () => clearTimeout(timer) } }, [deviceType, isUnsupportedBrowser]) + + // Handle escape key to close modal + useEffect(() => { + const handleEscape = (event: KeyboardEvent) => { + if (event.key === 'Escape' && showModal) { + setShowModal(false) + } + } + document.addEventListener('keydown', handleEscape) + return () => document.removeEventListener('keydown', handleEscape) + }, [showModal])
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
src/components/Setup/Views/InstallPWA.tsx(1 hunks)src/components/TransactionDetails/TransactionDetailsDrawer.tsx(1 hunks)src/components/TransactionDetails/TransactionDetailsHeaderCard.tsx(3 hunks)src/components/TransactionDetails/transactionTransformer.ts(3 hunks)src/utils/sdkErrorHandler.utils.tsx(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/components/TransactionDetails/TransactionDetailsHeaderCard.tsx
- src/components/TransactionDetails/transactionTransformer.ts
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Deploy-Preview
🔇 Additional comments (2)
src/utils/sdkErrorHandler.utils.tsx (1)
110-111: LGTM! The error handling addition follows established patterns.The new condition appropriately handles "Insufficient balance" errors with a clear, user-friendly message. The placement in the else-if chain is logical, and it follows the same string-matching pattern used throughout the function.
Note that this complements the existing 'insufficient funds' check on line 48, which suggests these handle different error sources - this is likely intentional and beneficial for comprehensive error coverage.
src/components/TransactionDetails/TransactionDetailsDrawer.tsx (1)
147-148:❓ Verification inconclusive
Verify the UI impact of changing from sourceView to status condition.
The logic change from
transaction.sourceView === 'status'totransaction.status === 'pending'makes sense from a UI perspective - controlling border visibility based on actual transaction state rather than view context. However, this functional change could affect existing UI behavior.Please verify that this change doesn't introduce visual inconsistencies by running the following script to check how these conditions are used across the codebase:
🏁 Script executed:
#!/bin/bash # Description: Check usage patterns of sourceView and status conditions in transaction components # Expected: Find other similar patterns to ensure consistency # Search for sourceView === 'status' usage patterns echo "=== Searching for sourceView === 'status' patterns ===" rg -A 3 -B 3 "sourceView.*===.*['\"]status['\"]" # Search for status === 'pending' patterns in UI components echo "=== Searching for status === 'pending' patterns in components ===" rg -A 3 -B 3 "status.*===.*['\"]pending['\"]" --type tsx --type ts # Search for hideBottomBorder usage to understand the pattern echo "=== Searching for hideBottomBorder usage patterns ===" rg -A 5 -B 2 "hideBottomBorder"Length of output: 13401
#!/bin/bash # Extract context around the Date PaymentInfoRow in TransactionDetailsDrawer echo "=== Date row context ===" rg -C12 "label={transaction.status === 'cancelled' ? 'Created' : 'Date'}" src/components/TransactionDetails/TransactionDetailsDrawer.tsx echo "" # Extract context around the Network fee PaymentInfoRow using sourceView echo "=== Network fee row context ===" rg -C5 "transaction.networkFeeDetails && transaction.sourceView" src/components/TransactionDetails/TransactionDetailsDrawer.tsx
Verify border visibility for Date and Network fee rows
Please confirm that the updated
hideBottomBorderlogic produces the intended UI in all contexts:
- The Date row now hides its bottom border whenever
transaction.status === 'pending'(regardless ofnetworkFeeDetailsorsourceView).- The Network fee row is still gated by
transaction.sourceView === 'status'and always hides its border when shown.- In views where
sourceView !== 'status'butstatus === 'pending', the Date row will render without a border and no Network fee row appears—verify this matches design expectations.- Manually inspect the drawer in both “status” and other views for a pending transaction to ensure borders appear (or are hidden) correctly.
