[TASK-9261] fix: use username when available in requests #711
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThis pull request introduces changes to how recipient information is handled and displayed in payment-related components. In the PaymentForm component, a new constant using the Changes
Sequence Diagram(s)sequenceDiagram
participant PF as PaymentForm Component
participant RD as RequestDetails
participant PAF as Printable Address Function
PF->>RD: Retrieve recipientAccount details
alt AccountType is PEANUT_WALLET
RD-->>PF: Return user.username
else Other Account Type
PF->>PAF: Format recipient address
PAF-->>PF: Return formatted address
end
PF->>UI: Conditionally render payment details (if not Peanut Wallet)
sequenceDiagram
participant IV as InitialView Component
participant Auth as useAuth Hook
participant RL as Request Link Logic
IV->>Auth: Retrieve authenticated user details
alt Wallet is Peanut Wallet
Auth-->>IV: Provide username data
IV->>RL: Use user.username for link generation
else
IV->>RL: Use recipientAddress from requestLinkDetails
end
Poem
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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 (
|
![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)
src/components/Request/Create/Views/Initial.view.tsx (1)
24-24: Clarify the purpose of the renamed propThe prop
onPrevhas been renamed to_onPrevwith an underscore prefix, suggesting it's not being used. Consider removing the prop if it's truly unused, or add a comment explaining why it's kept but not used.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/components/Payment/PaymentForm/index.tsx(3 hunks)src/components/Request/Create/Views/Initial.view.tsx(3 hunks)src/services/services.types.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
src/components/Request/Create/Views/Initial.view.tsx (1)
Learnt from: jjramirezn
PR: peanutprotocol/peanut-ui#551
File: src/components/Request/Create/Views/Initial.view.tsx:151-156
Timestamp: 2024-12-02T17:19:18.532Z
Learning: In the `InitialView` component at `src/components/Request/Create/Views/Initial.view.tsx`, when setting the default chain and token in the `useEffect` triggered by `isPeanutWallet`, it's acceptable to omit the setters from the dependency array and not include additional error handling for invalid defaults.
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Deploy-Preview
🔇 Additional comments (4)
src/services/services.types.ts (1)
40-47: New property fits well with existing patternsThe addition of the
recipientAccountproperty to theTRequestResponseinterface follows existing patterns in the codebase (e.g., similar structures inRequestLinkandPaymentinterfaces). This ensures consistency while providing more detailed information about the recipient's account.src/components/Payment/PaymentForm/index.tsx (2)
191-197: Add optional chaining to avoid potential runtime errorsThe
useMemohook is a good approach for computing the recipient label, but the access torecipientAccount.user.usernamein line 193 could cause runtime errors if any part of the path is undefined.- return requestDetails!.recipientAccount.user.username + return requestDetails?.recipientAccount?.user?.username || "Unknown User"Even though the condition above checks
requestDetails?.recipientAccount?.type, it's safer to use optional chaining within the return statement too, with a fallback value in case the path is undefined.
271-271: Add optional chaining for safer property accessThe conditional check is missing optional chaining for
recipientAccount, which could cause runtime errors ifrequestDetailsexists butrecipientAccountis undefined.- {requestDetails?.recipientAccount.type !== AccountType.PEANUT_WALLET && renderRequestedPaymentDetails()} + {requestDetails?.recipientAccount?.type !== AccountType.PEANUT_WALLET && renderRequestedPaymentDetails()}src/components/Request/Create/Views/Initial.view.tsx (1)
134-134: Add null check for safer user accessThe direct access to
user!.user.usernamewith a non-null assertion operator could cause runtime errors ifuseris null. Even though this is within anisPeanutWalletcheck, it's safer to handle potential null cases.- let link = `${process.env.NEXT_PUBLIC_BASE_URL}/${isPeanutWallet ? user!.user.username : requestLinkDetails.recipientAddress}/` + let link = `${process.env.NEXT_PUBLIC_BASE_URL}/${isPeanutWallet && user?.user?.username ? user.user.username : requestLinkDetails.recipientAddress}/`This ensures the username is only used when both
isPeanutWalletis true anduser(with its properties) is defined.
also fixes TASK-9259
Summary by CodeRabbit