fix(request): show some request info on already paid view#412
Conversation
📝 WalkthroughWalkthroughThe pull request introduces changes to two components within the payment request functionality. In Changes
Possibly related PRs
Suggested labels
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 (
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (5)
src/components/Request/Pay/Views/GeneralViews/AlreadyPaid.view.tsx (1)
Line range hint
1-47: Overall assessment: Changes improve component robustness and alter user flowThe modifications in this file successfully address the PR objectives by:
- Enhancing the display of token information with improved fallback logic.
- Changing the user flow from sending to requesting payments.
These changes appear to be intentional and well-implemented. However, due to the significant shift in user experience, it's crucial to ensure that this aligns with the broader UX strategy of the application.
Consider documenting this change in user flow in your application's UX documentation or user stories to maintain clarity on the intended user journey.
src/components/Request/Pay/Pay.tsx (4)
Line range hint
65-67: Consider improving error handlingThe current error handling only logs to the console. For a better user experience, consider updating the component state to reflect the error and display an appropriate message to the user.
Here's a suggestion for improved error handling:
catch (error) { console.error('Failed to fetch request link details:', error) setLinkState('ERROR') // Optionally, set an error message state to display to the user // setErrorMessage('Failed to fetch request link details. Please try again.') }Don't forget to add an error view in the component's return statement:
{linkState === 'ERROR' && <generalViews.ErrorView errorMessage={errorMessage} />}
Line range hint
24-31: Consider simplifying state managementThe component manages multiple states which could potentially be simplified. Consider creating a custom hook to manage the request link state and related operations. This would improve the readability and maintainability of the component.
Here's a basic example of how you could start refactoring this:
// useRequestLink.ts export const useRequestLink = () => { const [linkState, setLinkState] = useState<_consts.IRequestLinkState>('LOADING') const [requestLinkData, setRequestLinkData] = useState<_consts.IRequestLinkData | undefined>(undefined) // ... other states const checkRequestLink = async (pageUrl: string) => { // ... existing logic } return { linkState, requestLinkData, // ... other states and functions checkRequestLink, } } // In your component const { linkState, requestLinkData, checkRequestLink } = useRequestLink()Also applies to: 149-163
Line range hint
65-69: Replace hardcoded API keyThe API key is currently hardcoded as 'YOUR_API_KEY'. This is not a secure practice and should be replaced with an environment variable.
Replace the hardcoded API key with an environment variable:
const requestLinkDetails: any = await peanut.getRequestLinkDetails({ link: pageUrl, APIKey: process.env.NEXT_PUBLIC_PEANUT_API_KEY, apiUrl: '/api/proxy/get', })Make sure to add the API key to your environment variables and update your deployment process accordingly.
Line range hint
149-155: Add dependencies to useEffectThe useEffect hook doesn't have any dependencies, which might lead to unnecessary re-renders or missed updates. Consider adding the necessary dependencies.
Update the useEffect hook with the appropriate dependencies:
useEffect(() => { const pageUrl = typeof window !== 'undefined' ? window.location.href : '' if (pageUrl) { checkRequestLink(pageUrl) } }, [checkRequestLink]) // Add checkRequestLink as a dependency // You might need to wrap checkRequestLink with useCallback to prevent unnecessary re-renders const checkRequestLink = useCallback(async (pageUrl: string) => { // ... existing logic }, []) // Add any dependencies of checkRequestLink here
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- src/components/Request/Pay/Pay.tsx (1 hunks)
- src/components/Request/Pay/Views/GeneralViews/AlreadyPaid.view.tsx (2 hunks)
🔇 Additional comments (2)
src/components/Request/Pay/Views/GeneralViews/AlreadyPaid.view.tsx (1)
20-20: LGTM: Improved fallback for token symbol displayThe addition of
requestLinkData?.tokenAddressas a final fallback option enhances the robustness of the component. This change ensures that some information about the token is always displayed, even if the symbol is not available, which aligns well with the PR objective of showing more request info on the already paid view.src/components/Request/Pay/Pay.tsx (1)
70-72: Approved: Correct fix for the order of operations issueThis change addresses the PR objective by setting
requestLinkDataimmediately after fetching the request link details. This ensures that the correct data is available when checking the payment status and rendering the "Already Paid" view.The modification improves the component's behavior without introducing any new variables or altering the existing logic. It's a simple and effective solution to the described issue.
We were moving the state before setting the link data, this commit sets the link data before moving the state in case of an already paid link.
Summary by CodeRabbit
New Features
Bug Fixes