Merge/main and peanut wallet #592
Conversation
…nto fix/container-breaking-for-link-input-view
…github.com/kushagrasarathe/peanut-ui into fix/container-breaking-for-link-input-view
…utTest chore: added tests for react components
[TASK-7545] fix(footer): make docs external link
This reverts commit ddbc320.
[TASK-7525] fix(kyc): update bridge customer id on link creation
[TASK-7550] fix(kyc): store kyc status in db
[TASK-6773] fix: hide points estimation on consumer pages
chore: refactored banner. Failed at admin panel implementation
Prod Release
[TASK-7762] fix: fee calculation after promo code is applied
…or-link-input-view Fix container breaking for link input view
feat: Add support for whitelisted parent frame origins - Cashout
…to peanut-wallet
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Warning Rate limit exceeded@kushagrasarathe has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 12 minutes and 46 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
WalkthroughThis pull request introduces a comprehensive set of changes across multiple components and configurations in a React-based web application. The modifications primarily focus on enhancing user experience, improving wallet connection mechanisms, adding promotional code functionality, and refining error handling. Key areas of change include updating dependencies, modifying authentication flows, introducing new banner and promo code components, and adjusting routing and maintenance configurations. Changes
Sequence DiagramsequenceDiagram
participant User
participant App
participant WalletProvider
participant AuthContext
participant APIService
User->>App: Initiates Action
App->>WalletProvider: Connect Wallet (useAppKit)
WalletProvider-->>App: Wallet Connected
App->>AuthContext: Fetch/Update User
AuthContext->>APIService: Request User Data
APIService-->>AuthContext: Return User Details
AuthContext-->>App: Update User State
App->>User: Display Relevant UI
Possibly related PRs
Poem
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: 4
🧹 Nitpick comments (39)
src/components/Global/Footer/index.tsx (1)
30-30: Consider addingrel="noopener noreferrer"for external links
When opening external links in a new tab, it is generally best practice to addrel="noopener noreferrer"to enhance security and prevent potential window access from the new page.<Link key={link.name} href={link.url} target={link.url.startsWith('http') ? '_blank' : undefined} + rel={link.url.startsWith('http') ? 'noopener noreferrer' : undefined} className="font-semibold uppercase transition-colors last:mr-0 hover:text-violet-3 dark:text-white dark:hover:text-purple-1 md:mr-4" > {link.name} </Link>src/config/routesUnderMaintenance.ts (2)
1-3: Consider expanding the interface for future flexibility.
You might want to add fields likemaintenanceMessageorendTimein theMaintenanceConfiginterface to handle more detailed maintenance scenarios (like an estimated timeframe or custom messages).
12-17: Preemptively handle multiple maintenance routes.
Storing routes in an array is a good approach. However, you might consider referencingMAINTAINABLE_ROUTES.CASHOUTor others by default in the array for demonstration, so that contributors easily see how to add a route.src/components/Global/Banner/MaintenanceBanner.tsx (1)
8-16: Leverage stronger type checks for route matching.
Currently, thepathname.startsWith(route)check is sufficient. For more complex route structures, consider using a router-based method (like Next.js route matching) or a refined string comparison to avoid partial overlaps (e.g.,/send-moneymight match/send).src/components/Global/Banner/GenericBanner.tsx (1)
9-17: Good usage of default props and a marquee effect.
One minor note: marquee-style effects can be less accessible. Consider providing a user option to pause the scrolling.src/components/Global/Banner/index.tsx (1)
10-12: Maintain clarity in the variable name.
maintenanceBanneris a JSX element ornull. You might rename it to something likemaintenanceBannerElementto clarify it’s a rendered component rather than a boolean.src/config/wagmi.config.tsx (4)
13-13: Document environment variable usage.
The comment explaining theNEXT_PUBLIC_WC_PROJECT_IDis helpful. Consider referencing it in documentation or a.env.examplefile for better onboarding.
24-26: Consider fallback handling for chain transport creation.
You are creating HTTP transports from chain RPC URLs. If a chain lacks a default HTTP or is unavailable, you may want to add safety checks or retries to avoid run-time errors.
27-43: Robust connector configuration.
The array-based connectors enable flexibility. However, consider graceful error handling when none of the connectors is valid or available (e.g., user environment constraints).
54-65: createAppKit usage with analytics and onramp.
Enabling analytics and onramp features can have privacy or compliance implications. Ensure that consent and data capture align with your privacy policies.src/components/Request/Pay/Views/Initial.view.tsx (2)
Line range hint
88-88: Initialization of errorState.
Centralizing error handling through a singleerrorStateis good. In future expansions, consider using a reusable error management hook for more complex flows.
Line range hint
452-475: TODO for points estimation.
There is a large commented-out block referencing points calculation. If this is a planned feature, consider tracking it via a dedicated JIRA/Trello ticket for better visibility rather than inline TODO.src/components/Global/LinkAccountComponent/index.tsx (1)
454-454: Conditional display of address fields.
The{needsAddressInput && ...}approach is concise. Keep an eye on possible edge cases for partial KYC states (e.g., in-review or pending).src/components/Claim/Link/Initial.view.tsx (2)
16-39: Consolidated bridging constants & utility usage.
Pulling inestimatePoints,areEvmAddressesEqual, and bridging token name helpers is coherent. Keep watchful for potential naming collisions with local variables.
545-575: Large commented block with duplicated logic.
Seems like a partial duplication of network fee lines or points estimation. If reactivating, consider extracting into a shared component or utility for DRY compliance.jest.setup.ts (1)
3-7: Use ES module imports for clarity (optional).Requiring
utiland assigningTextEncoder/TextDecoderglobally is fine for your Jest environment setup. However, if your build chain supports ES modules in test files, consider using:-import '@testing-library/jest-dom' -const { TextEncoder, TextDecoder } = require('util') +import '@testing-library/jest-dom' +import { TextEncoder, TextDecoder } from 'util'This can improve consistency if the rest of your code is using ESM imports.
src/app/api/bridge/user/new/get-status/route.ts (1)
12-21: Refactor to minimize header duplication.
When constructinggetUserFromCookieRequest, you mergerequestheaders with a newcookieheader. For clarity, consider extracting this logic into a small helper function or constant.src/components/Offramp/Offramp.consts.ts (2)
64-65: Add Documentation for New Promo Code Props
The newly introducedappliedPromoCodeandonPromoCodeAppliedprops help manage promotional codes effectively. Consider adding a short JSDoc/comment on their intended usage and constraints, to streamline future maintenance and clarify their roles.
83-121: Externalize Hardcoded Promo Codes
WhileVALID_PROMO_CODESis a convenient array of constants, consider externalizing these codes into a configuration file or remote source (e.g., environment variable, CMS, or server endpoint) so that they can be updated without necessitating a new build. This approach also keeps the code lightweight and flexible.src/components/Offramp/PromoCodeChecker.tsx (1)
49-56: Remove Redundant Block Statement
This standalone block serves no functional purpose and can safely be removed for cleaner code.} else { - { setPromoCheckerState((prev) => ({ ...prev, error: 'Invalid promo code', isApplied: false, })) onPromoCodeApplied(null) - } }🧰 Tools
🪛 Biome (1.9.4)
[error] 49-56: This block statement doesn't serve any purpose and can be safely removed.
Standalone block statements without any block-level declarations are redundant in JavaScript and can be removed to simplify the code.
Safe fix: Remove redundant block.(lint/complexity/noUselessLoneBlockStatements)
src/components/Global/GeneralRecipientInput/__tests__/GeneralRecipientInput.test.tsx (1)
102-123: Case sensitivity checks on IBAN validation.
Ensuring IBAN inputs are normalized before validation is best practice. You already do this viasanitizeBankAccount(). This is good.src/components/Refund/index.tsx (1)
8-10: Use ofuseWalletanduseAppKitside by side.
You might consider centralizing wallet logic in a single hook for clarity. This simplifies maintenance and makes the flow easier to track.src/components/Global/Header/index.tsx (3)
2-2: Chakra UI imports
The changes are minor but watch for consistent styling usage for a uniform look with your local component library.
7-10: Swapping touseAppKit
This unifies modal control with the rest of your wallet logic. If you plan to removeuseWalleteventually, ensure all references are updated consistently.
290-290: Potential accessibility improvement
Providing a descriptive aria-label or role on the connect button can improve screen-reader support.src/components/Claim/Link/Onchain/Confirm.view.tsx (2)
211-220: Static $0.00 fees
If you foresee future changes in sponsor coverage, consider extracting this into a config or dynamic value for easy updates.
Line range hint
221-239: Commented-out points estimation
If you plan on reintroducing them, add unit tests or mock server responses to confirm correctness when the data layer is reinstated.src/components/Create/Link/Confirm.view.tsx (3)
2-8: Consolidate newly added imports if they are related.
These newly introduced imports are all UI components from internal libraries (0_BruddleandGlobal). Consider logically grouping them to maintain clarity, and remove any unused imports if not required.
15-19: Ensure consistent error handling throughout.
TheErrorHandlerutility is imported here. Double-check that calls toErrorHandlercover all potential error states, including unexpected response shapes.
Line range hint
327-346: Decide whether to remove or restore commented-out code.
This entire block is commented out. If it’s no longer relevant for awarding points, consider removing it for code cleanliness, or annotate it with a clear TODO if it needs to be reintroduced.src/components/Global/TokenSelector/TokenSelector.tsx (2)
3-5: Organize or prune newly added imports.
Imports forpeanutTokenDetails,supportedPeanutChains, andIToken/IUserBalancelook consistent. Confirm that all are necessary and used—removing unused imports helps keep the codebase tidy.
19-20: Ensure type definitions are consistently applied.
The added definitions inTokenSelector.constsand these updated imports should align across the codebase for a consistent interface.src/components/Create/Link/Input.view.tsx (2)
9-10: Streamline the UI imports.
BothButtonandToastcome from@/components/0_Bruddle; ensuring they are consistently imported can improve clarity, especially if you have multiple UI libraries in the future.
80-84: Handle potential errors when connecting the wallet.
ThehandleConnectWalletfunction callsopen()directly. Consider wrapping this in a try/catch or including a callback for failed connections to provide the user with an error message or retry mechanism.src/components/Global/KYCComponent/index.tsx (1)
100-100: Avoid repeated calls for user link data.
Each time you callutils.getUserLinks, you subsequently callupdateBridgeCustomerData. Consider caching or consolidating these calls to optimize performance and reduce repetitive fetches.Also applies to: 133-133, 188-188
src/components/Cashout/Components/Initial.view.tsx (1)
81-81: Rename variable to avoid confusion
The variableweb3modalOpenis somewhat misleading since it's mapped fromuseAppKit. Consider renaming it to something likeopenAppKitModalto reflect the new library.- const { open: web3modalOpen } = useAppKit() + const { open: openAppKitModal } = useAppKit()src/components/Offramp/Confirm.view.tsx (1)
818-865: “You will receive” calculation
Properly waiving the fee ifappliedPromoCodeis used. Otherwise, deduct the fee based on account type. Solid logic.Consider storing the fee in a small function or constant to reduce repetition and keep logic centralized.
src/components/Profile/index.tsx (2)
Line range hint
89-96: Address TODO comment for Sign In implementationThere's a TODO comment indicating that sign-in functionality needs to be implemented. The current implementation returns a disabled button, which might not provide a good user experience.
Would you like me to help implement the sign-in functionality using the existing
handleSiwemethod?
Line range hint
28-85: Consider refactoring authentication flow for maintainabilityThe SIWE implementation is tightly coupled with the current wallet implementation. Given the codebase's transition to
useAppKit, consider:
- Extracting the authentication logic into a custom hook
- Making the wallet integration more abstract to ease future migrations
- Adding error type definitions for better error handling
Here's a suggested approach for extracting the authentication logic:
// hooks/useAuthentication.ts export const useAuthentication = () => { const { address, signMessage } = useAppKit(); // or useWallet based on your migration status const [isLoading, setIsLoading] = useState(false); const [error, setError] = useState<AuthError | null>(null); const authenticate = async () => { // Current handleSiwe logic here }; const logout = async () => { // Current handleLogout logic here }; return { authenticate, logout, isLoading, error }; };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (46)
jest.setup.ts(1 hunks)package.json(6 hunks)src/app/(mobile-ui)/layout.tsx(2 hunks)src/app/api/bridge/user/new/get-status/route.ts(2 hunks)src/app/api/peanut/submit-cashout-link/route.ts(2 hunks)src/app/api/peanut/user/update-user/route.ts(2 hunks)src/components/Cashout/Cashout.consts.ts(3 hunks)src/components/Cashout/Cashout.tsx(2 hunks)src/components/Cashout/Components/Initial.view.tsx(4 hunks)src/components/Claim/Link/FlowManager.tsx(2 hunks)src/components/Claim/Link/Initial.view.tsx(5 hunks)src/components/Claim/Link/Onchain/Confirm.view.tsx(3 hunks)src/components/Claim/Link/Onchain/Success.view.tsx(1 hunks)src/components/Create/Create.tsx(2 hunks)src/components/Create/Link/Confirm.view.tsx(3 hunks)src/components/Create/Link/Input.view.tsx(2 hunks)src/components/Global/AddressInput/index.tsx(1 hunks)src/components/Global/Banner/GenericBanner.tsx(1 hunks)src/components/Global/Banner/MaintenanceBanner.tsx(1 hunks)src/components/Global/Banner/index.tsx(1 hunks)src/components/Global/Footer/consts.ts(1 hunks)src/components/Global/Footer/index.tsx(1 hunks)src/components/Global/GeneralRecipientInput/__tests__/GeneralRecipientInput.test.tsx(1 hunks)src/components/Global/GeneralRecipientInput/index.tsx(2 hunks)src/components/Global/Header/index.tsx(5 hunks)src/components/Global/Icon/index.tsx(2 hunks)src/components/Global/KYCComponent/index.tsx(5 hunks)src/components/Global/LinkAccountComponent/index.tsx(5 hunks)src/components/Global/TokenSelector/TokenSelector.tsx(2 hunks)src/components/Kyc/index.tsx(1 hunks)src/components/LinkAccount/index.tsx(1 hunks)src/components/Offramp/Confirm.view.tsx(7 hunks)src/components/Offramp/Offramp.consts.ts(2 hunks)src/components/Offramp/PromoCodeChecker.tsx(1 hunks)src/components/Offramp/Success.view.tsx(3 hunks)src/components/Profile/Components/SkeletonPage.tsx(1 hunks)src/components/Profile/index.tsx(1 hunks)src/components/Refund/index.tsx(1 hunks)src/components/Request/Pay/Views/Initial.view.tsx(4 hunks)src/components/Request/Pay/Views/Success.view.tsx(1 hunks)src/config/routesUnderMaintenance.ts(1 hunks)src/config/wagmi.config.tsx(1 hunks)src/constants/tooltips.ts(1 hunks)src/context/authContext.tsx(6 hunks)src/utils/cashout.utils.ts(4 hunks)tsconfig.test.json(1 hunks)
✅ Files skipped from review due to trivial changes (4)
- tsconfig.test.json
- src/components/Create/Create.tsx
- src/components/LinkAccount/index.tsx
- src/components/Profile/Components/SkeletonPage.tsx
🧰 Additional context used
📓 Learnings (4)
src/components/Global/TokenSelector/TokenSelector.tsx (1)
Learnt from: jjramirezn
PR: peanutprotocol/peanut-ui#424
File: src/components/Global/TokenSelector/TokenSelector.tsx:197-211
Timestamp: 2024-11-12T09:39:20.720Z
Learning: In `src/components/Global/TokenSelector/TokenSelector.tsx`, when the calculation within functions like `byChainAndText` is not computationally expensive, it's acceptable to avoid using `useCallback` for memoization.
src/components/Request/Pay/Views/Success.view.tsx (1)
Learnt from: jjramirezn
PR: peanutprotocol/peanut-ui#409
File: src/components/Request/Pay/Views/Success.view.tsx:23-23
Timestamp: 2024-11-12T09:39:20.720Z
Learning: In the `SuccessView` component, `transactionHash` remains constant because we are in a success view, so it's unnecessary to include it in the dependency array of `useEffect` hooks.
src/components/Create/Link/Confirm.view.tsx (1)
Learnt from: Hugo0
PR: peanutprotocol/peanut-ui#458
File: src/components/Offramp/Confirm.view.tsx:141-141
Timestamp: 2024-11-12T09:39:20.720Z
Learning: The `handleConfirm` function in `src/components/Create/Link/Confirm.view.tsx` is separate from the one in `src/components/Offramp/Confirm.view.tsx` and does not need to be renamed when refactoring `handleConfirm` in `src/components/Offramp/Confirm.view.tsx`.
src/components/Request/Pay/Views/Initial.view.tsx (3)
Learnt from: jjramirezn
PR: peanutprotocol/peanut-ui#410
File: src/components/Request/Pay/Views/Initial.view.tsx:87-93
Timestamp: 2024-11-12T09:39:20.720Z
Learning: When refactoring to eliminate code duplication, prioritize readability and consider whether the change significantly improves the code. If it doesn't enhance readability or maintainability, it's acceptable to keep the existing code structure.
Learnt from: jjramirezn
PR: peanutprotocol/peanut-ui#422
File: src/components/Request/Pay/Views/Initial.view.tsx:76-78
Timestamp: 2024-11-12T09:39:20.720Z
Learning: In `src/components/Request/Pay/Views/Initial.view.tsx`, both `txFee` and `utils.formatTokenAmount(estimatedGasCost, 3)` return strings, ensuring consistent return types for `calculatedFee`.
Learnt from: jjramirezn
PR: peanutprotocol/peanut-ui#422
File: src/components/Request/Pay/Views/Initial.view.tsx:76-78
Timestamp: 2024-11-12T09:39:20.720Z
Learning: In `src/components/Request/Pay/Views/Initial.view.tsx`, both `txFee` and `utils.formatTokenAmount(...)` return strings, ensuring that `calculatedFee` consistently returns a string without the need for additional type conversion.
🪛 Biome (1.9.4)
src/components/Cashout/Cashout.tsx
[error] 9-9: Unexpected empty object pattern.
(lint/correctness/noEmptyPattern)
package.json
[error] 81-81: The key @testing-library/jest-dom was already declared.
This where a duplicated key was declared again.
If a key is defined multiple times, only the last definition takes effect. Previous definitions are ignored.
(lint/suspicious/noDuplicateObjectKeys)
[error] 84-84: The key @types/jest was already declared.
This where a duplicated key was declared again.
If a key is defined multiple times, only the last definition takes effect. Previous definitions are ignored.
(lint/suspicious/noDuplicateObjectKeys)
src/components/Offramp/PromoCodeChecker.tsx
[error] 49-56: This block statement doesn't serve any purpose and can be safely removed.
Standalone block statements without any block-level declarations are redundant in JavaScript and can be removed to simplify the code.
Safe fix: Remove redundant block.
(lint/complexity/noUselessLoneBlockStatements)
🔇 Additional comments (120)
src/components/Global/Icon/index.tsx (3)
2-2: Great reintroduction of the twMerge import.
This import helps to avoid conflicting Tailwind utility classes in merged className strings. It’s beneficial for cleaner className composition in React components.
204-204: New ticket icon path looks solid.
The path syntax is valid, and adding this new icon in the icons object is consistent with existing patterns in the file.
205-205: chevron-up icon addition is properly defined.
No functional issues appear to be present; the SVG path and the naming align with the rest of the icon set.
src/components/Global/Footer/consts.ts (1)
29-29: Good move to direct users to the external docs site
This update ensures users are navigated directly to the official documentation site.
src/config/routesUnderMaintenance.ts (2)
5-10: Well-defined constant with descriptive keys.
The MAINTAINABLE_ROUTES constant is clear and explicit. This helps avoid typos in routes throughout the code.
19-19: Exporting the config as default is aligned with usage.
This pattern is helpful to keep the config straightforward to import across the codebase.
src/components/Global/Banner/MaintenanceBanner.tsx (1)
4-6: Prop interface is concise and straightforward.
No improvements needed here at the moment.
src/components/Global/Banner/GenericBanner.tsx (1)
3-7: Expand the typed props if needed.
The typed props look good. If this banner is expected to become more complex, consider top-level doc comments or JSDoc for improved clarity.
src/components/Global/Banner/index.tsx (5)
2-3: Properly importing new generic and maintenance banners.
The imports are organized and consistent.
8-8: Ensure pathname is consistently available.
Returning early if pathname is undefined is a good safeguard, especially in new Next.js app router contexts.
15-17: Beta message is direct and user-friendly.
This is a neat approach to quickly flag routes as “beta.” Keep in mind you might eventually switch or remove it when the feature is stable.
19-19: Clean exit strategy.
Returning null when no banner applies is straightforward.
22-23: Exports are consistent with usage in other files.
Explicitly re-exporting GenericBanner and MaintenanceBanner ensures a clear public API.
src/components/Request/Pay/Views/Success.view.tsx (1)
2-2: All import changes look good.
These added imports (Button, Card, Icon, ReferenceAndAttachment, utils, Link, and _consts) are used properly within the component. The naming conventions are clear, and everything appears consistent with the rest of the codebase.
Also applies to: 4-5, 8-8, 10-11, 13-13
src/config/wagmi.config.tsx (5)
4-5: New Wagmi & AppKit imports look good.
These imports establish the foundation for the new Wagmi-based architecture.
7-7: Ensure consistent usage of wagmi exports.
Ensure that CreateConnectorFn, WagmiProvider, http are consistently used and that no legacy imports remain to avoid confusion.
20-20: URL-based metadata usage.
Using process.env.NEXT_PUBLIC_BASE_URL looks fine. Verify that the environment variable is set appropriately in all deployment environments.
45-50: WagmiAdapter initialization.
Explicitly setting ssr: true is fine as long as all server-side usage of the wagmi context is tested. Make sure to handle potential SSR hydration discrepancies.
74-74: WagmiProvider config reference updated.
Replacing the old config reference with wagmiAdapter.wagmiConfig aligns with the new approach. Looks good.
src/context/authContext.tsx (6)
2-9: Reorganized imports with new types and hooks.
The updated import statements for usePWAStatus, GetUserLinksResponse, useAppKit, and useQuery look coherent. No immediate issues detected.
18-18: Interface update for updating bridge customer data.
Renaming updateBridgeCustomerId to updateBridgeCustomerData and using the new GetUserLinksResponse type improves clarity and type safety.
40-40: web3modalOpen usage instead of open?
You've destructured open as web3modalOpen, which is descriptive. Just confirm all references are updated consistently throughout the file.
132-134: Extended logic for bridge customer updates.
Transitioning to GetUserLinksResponse ensures more robust data usage. Confirm that all properties (customer.id, customer.kyc_status) are present to avoid runtime errors.
142-144: Proper JSON fields naming.
Using bridge_customer_id and kycStatus aligns with your server’s expected field names. Make sure the backend remains consistent to avoid silent mismatch.
273-273: Exposing updateBridgeCustomerData in the context value.
This ensures other parts of the application can easily call the new method. Good job on maintaining the updated interface.
src/components/Request/Pay/Views/Initial.view.tsx (3)
1-29: New imports and restructured references.
Imports from @/components/0_Bruddle, toast, context, and appkit consolidate functionality well. Watch for any unused imports if your lint rules require it.
80-80: Using open from useAppKit.
This is consistent with your switch from traditional web3modals. Validate that open is never called on the server side to avoid SSR issues.
Line range hint 132-132: Memo for fee calculation.
Using useMemo for calculatedFee is efficient. Confirm that dependencies like txFee and estimatedGasCost rarely cause stale values, especially with asynchronous updates.
src/components/Global/LinkAccountComponent/index.tsx (3)
88-89: Introducing needsAddressInput.
This state variable clarifies whether address fields should be displayed. Good approach for user flows that depend on KYC status.
111-134: Effect controlling US address requirements.
It’s smart to check user KYC status and existing stored addresses. Validate that accounts is always defined when referencing user.accounts.some(...) to avoid runtime errors.
199-199: Shifting from 'verified' to 'approved' KYC status.
Ensure you’ve updated all references in the codebase for consistent logic. The mismatch between verified vs. approved could lead to accidental gating issues.
src/components/Claim/Link/Initial.view.tsx (3)
3-9: Extended imports with bridging and UI components.
Additional imports for bridging logic, Crisp chat, and token selectors unify the feature set. Looks consistent with your bridging approach.
85-85: Opening wallet from useAppKit.
Again, confirm that this works in all environment contexts (SSR vs. browser).
241-241: Consistent kycStatus check to 'approved'.
Maintain alignment with other references across the codebase. Some other files still use 'verified'; ensure no leftover conditions remain.
src/constants/tooltips.ts (2)
4-4: Good user clarity improvement for US bank account instructions.
Line 4’s update clarifies that only the account number is needed, reducing confusion around routing numbers. This is beneficial for user experience.
12-12: Maintain consistent instruction style across platforms.
Line 12 no longer references the routing number. This aligns with the simplified instructions above, ensuring a consistent message regarding required bank information.
src/components/Global/AddressInput/index.tsx (1)
21-21: Stricter validation might break existing flows.
Switching from isAddress(recipient, { strict: false }) to isAddress(recipient) enhances correctness but may reject previously accepted addresses (e.g., if they contained uppercase letters or partial formats). Verify all usage scenarios and ensure that this stricter approach matches business needs.
src/components/Claim/Link/FlowManager.tsx (2)
22-22: Optional appliedPromoCode parameter introduced.
Extending props with an appliedPromoCode?: string | null field is straightforward. Verify all call sites to ensure they handle undefined or null robustly.
36-37: Ensure consistent usage of appliedPromoCode across the flow.
You're conditionally adding appliedPromoCode to componentProps only for IBAN/US recipients. Confirm that other flows do not rely on this property or inadvertently need it. If needed broader, apply outside the conditional.
src/app/api/peanut/submit-cashout-link/route.ts (2)
17-18: Consider validating these new parameters before usage.
The new promoCode and trackParam fields enhance functionality; however, consider handling edge cases (e.g., empty strings, invalid values) to avoid potential issues downstream.
29-37: Ensure consistency in request body structure.
All necessary fields are now included in the request body. Please confirm that the downstream API (Peanut) supports the new promoCode and trackParam properties.
src/components/Cashout/Cashout.consts.ts (3)
6-6: Import usage looks good.
Importing OfframpType ensures typed control over the offrampType in subsequent components.
23-23: Strongly typed component mapping.
The transition to React.FC<ICashoutScreenProps> enhances type safety and improves maintainability.
68-70: Promo code and offramp enhancements.
The addition of appliedPromoCode, offrampType, and onPromoCodeApplied extends flexibility for promotional flow and user interactions.
src/app/api/bridge/user/new/get-status/route.ts (2)
28-28: Confirm ID check logic.
Switching from user?.id to user?.bridge_customer_id is correct given the new structure. Ensure that all references to user ID remain consistent across the codebase.
61-61: Expanded response object enhances clarity.
Returning both id and kyc_status covers multiple use cases. Ensure front-end consumers of this endpoint handle the new structure properly.
src/app/api/peanut/user/update-user/route.ts (4)
1-1: Organized imports.
The import statements follow a clean structure. No issues found.
9-9: Optional kycStatus field.
Allowing kycStatus to be omitted is beneficial. Ensure the receiving endpoint safely handles undefined or empty values.
16-17: Destructuring is concise.
Capturing the new kycStatus property streamlines the payload construction. No issues regarding correctness.
31-31: Conditional property assignment is correct.
kycStatus is now included in the payload if provided. Confirm that your backend logic properly handles this new field.
src/components/Kyc/index.tsx (1)
2-9: Reorganized Imports Look Good
These import changes centralize dependencies neatly, contributing to cleaner code organization. There are no apparent issues with the updated import sources, and everything seems aligned with the component’s usage.
src/components/Offramp/Offramp.consts.ts (1)
81-81: Consistent Promo Code Field
Including appliedPromoCode in the IOfframpSuccessScreenProps interface maintains consistency throughout the application’s flow for promo code usage. This change aligns well with the newly added confirm-screen property.
src/components/Global/GeneralRecipientInput/index.tsx (2)
66-66: Confirm Comprehensive Address Validation
Using isAddress(trimmedInput) ensures the address is a valid Ethereum address in a case-insensitive manner. If additional chain-specific or custom validations are required (e.g., checksums, prefix checks), ensure they are handled accordingly.
82-82: Trim Wisely for Non-Bank Inputs
Applying .trim() to non-IBAN and non-US inputs removes extraneous whitespace and reduces user error. Verify that no legitimate user input would be lost in this scenario (for example, if certain future input types might preserve spaces).
src/components/Offramp/PromoCodeChecker.tsx (2)
1-48: Promo Code Checker Implementation
Overall, this new component efficiently handles promo code validation and UI updates. Normalizing to uppercase and trimming the input ensures consistent comparisons. The state-driven approach is easy to maintain and integrates well with the existing offramp flow.
57-136: Promotional Section Toggling & State Management
The toggle-based expand/collapse for promo code input, plus reactive updates via useEffect when appliedPromoCode changes, is clear and caters well to user interactions. The user feedback messages for successful or erroneous entry are likewise straightforward and user-friendly.
src/components/Claim/Link/Onchain/Success.view.tsx (2)
78-78: **Improved label clarity **
Changing the label to "Cross-chain Routing via Axelar:" is a clear improvement in descriptive naming. No issues found.
85-85: **Enhanced user-friendly terminology **
Renaming "Destination Chain" to "Destination Address:" is more accurate and helpful to the user. Good change.
src/components/Cashout/Cashout.tsx (3)
13-13: **State for promo code is typed properly **
Defining appliedPromoCode as string | null helps ensure type safety for the promo code feature.
180-181: **Promo code callback integration **
Providing the onPromoCodeApplied prop is an effective way to allow parent components to pass down and manage promo code behavior.
9-9: **Static analysis empty object pattern **
The reported "Unexpected empty object pattern" appears to be a false positive with no actual code snippet requiring a fix.
🧰 Tools
🪛 Biome (1.9.4)
[error] 9-9: Unexpected empty object pattern.
(lint/correctness/noEmptyPattern)
src/app/(mobile-ui)/layout.tsx (1)
109-109: **Transition to useAppKit for wallet workflow **
Using useAppKit() centralizes the wallet connection flow. This change aligns the code with modern best practices for wallet integrations.
src/components/Offramp/Success.view.tsx (5)
20-20: **Introducing appliedPromoCode **
Adding the appliedPromoCode prop to integrate promo code logic into the success flow is a sensible, straightforward enhancement.
36-44: **calculateFee function logic **
This conditional approach for zero-fee with a promo code is clear and concise. The fallback to a fee based on account type is intuitive.
67-75: **Contextual fee explanation **
Displaying fee details via <MoreInfo> effectively communicates the cost breakdown. The waived-fee messaging for promo codes is a nice touch.
81-82: **Section label for clarity **
The "You will receive" section label improves user understanding of net funds received.
89-114: **Fee subtraction logic **
Dynamically subtracting fees based on account type is appropriate, but consider boundary checks. If usdValue is smaller than the fee, the result may be negative.
Would you like to automate verifying any potential negative amounts via a script?
src/components/Global/GeneralRecipientInput/__tests__/GeneralRecipientInput.test.tsx (8)
1-16: Use of explicit mocks and type definitions looks solid.
The test setup and custom TestCase type facilitate maintainability, making it easier to add new scenarios.
18-23: Ensure that freely mocked functions maintain parity with actual implementation.
While resolveFromEnsName and validateBankAccount are mocked, confirm their arguments and return types remain consistent with their real implementations to avoid mismatched usage in tests.
32-35: Mocking viem's isAddress function
This mock logic is straightforward, but watch out for possible changes to the viem package’s API. If isAddress later evolves (e.g., support for newer address types), you may need to adjust the mock accordingly.
40-44: Effectively resetting mocks before each test.
This ensures that each test runs independently without side effects from prior tests.
60-101: Great coverage considering US bank account edge cases.
The test array is comprehensive, covering valid and invalid lengths and spacing.
125-165: ETH address tests are thorough.
Covers prefix checks, length checks, and invalid characters thoroughly.
167-182: ENS resolution mock.
Verifying different input results (e.g. null for not found vs. actual address) is key for robust coverage. Keep it up.
185-219: Comprehensive final verification.
The test systematically checks correctness of all relevant fields in the callback (type, isValid, recipient, errorMessage). This ensures the component logic matches expectations for each scenario.
src/components/Refund/index.tsx (3)
2-2: Confirm if all usage of peanut-sdk is tested in integration tests.
Since peanut is a central dependency for retrieving deposit details and receipts, consider adding integration tests or e2e tests to verify real network usage if feasible.
16-16: Dependency injection via useCreateLink.
This approach keeps the code modular. Good job.
23-23: open from useAppKit.
Confirm that open is actually invoked for the intended modal actions, or else consider removing it if not utilized.
src/components/Global/Header/index.tsx (5)
5-5: Using advanced React hooks
Your code effectively leverages useCallback and useEffect for performance. Keep an eye on potential memory leaks or stale closures.
13-14: Coexistence of useRouter and useAccount
Using them effectively for route transitions and wallet data is fine, just ensure there’s no concurrency or lifecycle conflict.
226-226: walletModal usage
Looks good, but removing signInModal references in useWallet can avoid confusion.
263-263: Button onClick
Ensure walletModal() handles re-entrant calls gracefully. If a user rapidly clicks before it closes, you don’t want multiple modals stacking.
279-280: Swapping from useWallet to useAccount
This is a more direct approach if you only need the address and isConnected boolean.
src/components/Claim/Link/Onchain/Confirm.view.tsx (3)
2-4: Modular imports
Extracting Button, Card, Icon, and MoreInfo from shared components fosters a DRY approach. Good practice.
7-10: Context usage
Using multiple contexts (walletContext, loadingStateContext, etc.) can lead to confusion. Keep documented which context handles which logic.
11-12: Separation of concerns
useClaimLink is a clear boundary for chain claim logic. Good approach to keep the component lean.
src/components/Create/Link/Confirm.view.tsx (2)
11-12: Validate that the contexts are initialized correctly.
Both useWallet and useWalletType provide important wallet data. Confirm that these contexts are set up before this component is rendered to avoid potential null reference errors.
24-24: Confirm usage of _consts.
Ensure that the constants from ../Create.consts are actively used in this file. These constants are valuable for consistent usage throughout the app.
src/components/Global/TokenSelector/TokenSelector.tsx (2)
15-16: Evaluate side effects of switching from useWalletType to useAppKit together.
Both hooks manage wallet connectivity but in different ways. Verify that interactions between them do not introduce race conditions in initialization or data retrieval.
187-187: Verify usage of open from useAppKit.
Confirm that calling open() has no unintended side effects if the user clicks repeatedly or closes the wallet modal.
src/components/Create/Link/Input.view.tsx (2)
5-6: Double-check the new import for useAppKit.
Confirm that the build environment supports @reown/appkit/react and that any peer dependencies are satisfied.
15-24: Check for dead imports.
Many context or utils imports are listed. Ensure these are all necessary—removing unused references will reduce mental overhead and potential confusion.
src/components/Global/KYCComponent/index.tsx (1)
51-51: Validate that updateBridgeCustomerData is working as intended.
Renaming from updateBridgeCustomerId to updateBridgeCustomerData suggests a broader scope for updates. Confirm that the returned promise resolves with expected data and handles errors appropriately.
src/components/Cashout/Components/Initial.view.tsx (4)
3-6: Imports look coherent
These new imports for assets, Button, Card, Toast, and useCreateLink appear consistent with the usage in the component. No immediate issues detected.
11-11: Constant references recognized
Importing MAX_CASHOUT_LIMIT and MIN_CASHOUT_LIMIT from Offramp.consts is consistent with usage patterns for code clarity and modularity.
385-385: Improved error message
The updated string clarifies for US bank accounts to exclude the routing number. This provides better guidance to end-users. No issues detected.
17-21: New utility and library imports
The addition of useAppKit from @reown/appkit/react aligns with the shift away from useWeb3Modal. Ensure calls are updated everywhere to prevent mismatched references.
Use this verification script to locate and replace old useWeb3Modal references:
✅ Verification successful
Migration from useWeb3Modal to useAppKit is consistent across the codebase
The codebase shows a consistent migration pattern where useAppKit from '@reown/appkit/react' has been properly implemented across all relevant components. There are no remaining references to the old useWeb3Modal hook or @web3modal package imports. The new useAppKit hook is being used consistently for wallet connection functionality, with the open method being destructured and used appropriately (sometimes renamed for clarity, e.g., web3modalOpen, walletModal).
Key locations where useAppKit is properly implemented:
- src/components/Cashout/Components/Initial.view.tsx
- src/context/authContext.tsx
- src/app/(mobile-ui)/layout.tsx
- src/components/Global/Header/index.tsx
- Various other components in the Request, Refund, and Claim features
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Searching for useWeb3Modal usage
rg -A 5 $'useWeb3Modal'
Length of output: 22
Script:
#!/bin/bash
# Let's try a more comprehensive search for web3modal references
rg -i "web3modal|useweb3"
Length of output: 601
Script:
#!/bin/bash
# Let's also check for useAppKit usage to understand the migration pattern
rg -i "useappkit"
Length of output: 1615
Script:
#!/bin/bash
# Search for any remaining web3modal package imports
rg -i "@web3modal"
Length of output: 18
src/utils/cashout.utils.ts (4)
8-9: Domain verification constant
ALLOWED_PARENT_DOMAINS broadens frame checks to specific domains. Looks like a straightforward approach to limit embedding.
10-21: Frame allowance logic
isInAllowedFrame() carefully checks ancestorOrigins (modern browsers) and falls back to document.referrer. This is a good layered check, although note that referrer checks can be spoofed or absent in some scenarios.
545-546: Optional promo parameters
Allowing promoCode and trackParam as optional fields extends functionality without disrupting existing calls. Implementation is well-suited for future expansions.
566-567: Added parameters in POST body
Including promoCode and trackParam keys ensures these optional fields propagate to the server. No security flags, but confirm server-side handling for potential injection attacks.
Consider sanitizing input or ensuring server validation to mitigate injection risk.
src/components/Offramp/Confirm.view.tsx (11)
4-4: Import matches usage
Adding useCreateLink from @/components/Create/useCreateLink is consistent with the usage below in handleCashoutConfirm logic.
6-10: Global imports
CrispButton, Icon, GlobalKYCComponent, etc., are introduced. The structure indicates deeper integration with global UI components. This is fine.
12-21: Auth and context imports
Pulling from @/context modules for user data and utility functions is consistent with existing architectural patterns. Good usage.
32-32: Card import
The new import from ../0_Bruddle aligns with the usage of the Card component throughout.
34-34: PromoCodeChecker
Importing PromoCodeChecker directly signals new promotional code handling—ensures synergy with similarly updated modules.
55-56: New props for promo code
appliedPromoCode and onPromoCodeApplied reflect a clear approach to incorporate promotional codes within the Offramp flow.
99-101: Promo code callback
The local handlePromoCodeApplied function passes the code to onPromoCodeApplied. This is straightforward data flow.
730-782: Fee logic
Dynamically adjusting the fee to $0 if appliedPromoCode is present, otherwise using $1 for SEPA or $0.50 for ACH. Implementation is clear and user-friendly.
871-880: Promo code input
<PromoCodeChecker> usage further clarifies the promotional code workflow. Good integration with the newly added callback.
881-906: Proceed button event
Conditionally invoking handleCashoutConfirm or handleSubmitTransfer is suitable for forking logic based on the offramp type.
907-944: Back navigation and error handling
Resetting form state and steps on back click is a good user experience practice. The Crisp support chat scenario for errors is also a nice synergy.
package.json (7)
32-33: New dependencies for appkit
"@reown/appkit": "^1.6.0" and "@reown/appkit-adapter-wagmi": "^1.6.0" reflect your shift to these libraries for wallet connectivity. No obvious conflicts.
39-39: React Query version
Downgrading or pinning to "@tanstack/react-query": "5.8.4" ensures the app remains stable if the latest version has breaking changes.
Check for usage of any features that might only exist in newer versions.
42-42: Pinning @wagmi/core
Pinning "@wagmi/core": "2.14.3" can help avoid unexpected updates. Ensure this version aligns with all needed features.
59-59: Adding pino-pretty
This is useful for structured logs in development. No concerns.
100-100: Retaining @types/web-push
No issues found with @types/web-push. Keep consistent usage.
117-127: Jest transform additions
The transform settings for ts-jest, along with transformIgnorePatterns, address module transformation (wagmi, viem). Good approach for library compatibility.
138-142: Resolutions block
Locking specific versions of @wagmi/core, viem, and wagmi helps maintain consistent behavior across the codebase.
src/components/Profile/index.tsx (1)
3-6: Verify wallet hook consistency across the codebase
While the import organization looks clean, there might be an inconsistency with the broader codebase changes. The component is still using useWallet while other components have moved to useAppKit.
Let's verify the wallet hook usage across the codebase:
Also applies to: 10-12
✅ Verification successful
Both hooks are being used together as intended
Based on the analysis of the codebase, the use of both useWallet and useAppKit hooks is intentional and correct. The useAppKit hook is imported from @reown/appkit/react and is used alongside useWallet in multiple components. They serve different purposes:
useAppKit: Handles web3modal and wallet connection UI/interactionsuseWallet: Manages wallet state and additional wallet-related functionality
Key evidence:
- Both hooks are used together in multiple components (Header, TokenSelector, Initial.view, etc.)
useAppKitis consistently imported from@reown/appkit/react- There's a TODO comment indicating planned integration work between these hooks
- No migration patterns or deprecation notices were found
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for useWallet vs useAppKit usage patterns
echo "Checking wallet hook usage patterns..."
# Check for useWallet usage
echo "Files still using useWallet:"
rg "useWallet" -l
# Check for useAppKit usage
echo "Files using useAppKit:"
rg "useAppKit" -l
# Check for specific wallet-related imports
echo "Checking wallet-related imports in other components:"
rg "import.*from.*['\"]@reown/appkit['\"]" -l
Length of output: 2082
Script:
#!/bin/bash
# Let's check the actual implementation in files using both hooks to understand the pattern
echo "Checking implementation patterns in files using both hooks:"
for file in $(rg "useAppKit" -l | grep -f <(rg "useWallet" -l)); do
echo "=== $file ==="
rg "use(Wallet|AppKit)" "$file" -C 2
done
# Let's also check the walletContext implementation
echo -e "\nChecking walletContext implementation:"
rg "export.*useWallet" "src/context/walletContext" -A 5
# And check the authContext implementation for useAppKit
echo -e "\nChecking authContext implementation:"
rg "export.*useAppKit" "src/context/authContext.tsx" -A 5
Length of output: 1022
Script:
#!/bin/bash
# Let's try a different approach to check the relationship between these hooks
echo "Checking useAppKit implementation and usage:"
rg "useAppKit" -C 5
echo -e "\nChecking if useAppKit is imported from an external package:"
rg "import.*useAppKit.*from" -C 2
echo -e "\nChecking if there are any migration patterns or TODOs:"
rg -i "todo.*wallet|migrate.*wallet" -C 2
Length of output: 22168
| @@ -166,7 +166,7 @@ export const InitialCashoutView = ({ | |||
| recipient: bankAccountNumber, | |||
| password: '', | |||
| }) | |||
| if (user?.user.kycStatus == 'verified') { | |||
| if (user?.user.kycStatus === 'approved') { | |||
There was a problem hiding this comment.
💡 Codebase verification
Inconsistent KYC status values across codebase
The codebase currently has a mix of both 'verified' and 'approved' being used for KYC status checks:
- 4 files using
'verified': Kyc/index.tsx, LinkAccount/index.tsx, ProfileHeader.tsx, and LinkAccountComponent/index.tsx - 5 files using
'approved': IframeWrapper/index.tsx, LinkAccountComponent/index.tsx, KYCComponent/index.tsx, Initial.view.tsx (Claim), and Initial.view.tsx (Cashout)
This inconsistency needs to be addressed. While the change in the reviewed file is correct as it aligns with the newer 'approved' standard, the other instances using 'verified' should be updated to maintain consistency across the codebase.
🔗 Analysis chain
KYC status update
Changing the check from verified to approved helps maintain consistency if the rest of the code now uses 'approved'. Ensure no references to the old 'verified' status remain.
Update required: Multiple instances of 'verified' KYC status found
src/components/Kyc/index.tsx: Uses'verified'for KYC status checksrc/components/LinkAccount/index.tsx: Uses'verified'in conditional checksrc/components/Profile/Components/ProfileHeader.tsx: Uses'verified'forhasKYCedvariablesrc/components/Global/LinkAccountComponent/index.tsx: Uses'verified'in KYC status validation
Let's verify if there are any instances of 'approved' status to understand the current standard:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Searching for old 'verified' references throughout the codebase
rg -A 2 $'kycStatus.*verified'
Length of output: 1191
Script:
#!/bin/bash
# Searching for 'approved' KYC status references
rg -A 2 $'kycStatus.*approved'
Length of output: 2086
| "@testing-library/jest-dom": "^6.6.3", | ||
| "@testing-library/react": "^16.1.0", | ||
| "@testing-library/user-event": "^14.5.2", | ||
| "@types/jest": "^29.5.12", |
There was a problem hiding this comment.
Duplicate dependency declarations
The lines show @testing-library/jest-dom and @types/jest appear more than once. Only the latter occurrence is in effect. To avoid confusion, remove duplicates.
Apply this diff:
"devDependencies": {
- "@testing-library/jest-dom": "^6.6.3",
- "@testing-library/react": "^16.1.0",
- "@testing-library/user-event": "^14.5.2",
- "@types/jest": "^29.5.12",
...
"@testing-library/jest-dom": "^6.4.2",
...
"@types/jest": "^29.5.12",
...
},🧰 Tools
🪛 Biome (1.9.4)
[error] 81-81: The key @testing-library/jest-dom was already declared.
This where a duplicated key was declared again.
If a key is defined multiple times, only the last definition takes effect. Previous definitions are ignored.
(lint/suspicious/noDuplicateObjectKeys)
[error] 84-84: The key @types/jest was already declared.
This where a duplicated key was declared again.
If a key is defined multiple times, only the last definition takes effect. Previous definitions are ignored.
(lint/suspicious/noDuplicateObjectKeys)
| userId: user.user.userId, | ||
| kycStatus: customer.kyc_status, |
There was a problem hiding this comment.
@Hugo0 this file needs review, it had some conflicts, need to double check if all the values are being passed or if something is unnecessary
| <div className="flex w-max flex-row items-center justify-center gap-1"> | ||
| <Icon name={'transfer'} className="h-4 fill-gray-1" /> | ||
| <label className="font-bold">Total</label> | ||
| <div className="relative flex flex-1 items-center justify-end gap-1 text-sm font-normal"> |
There was a problem hiding this comment.
@Hugo0 this whole file too
| @@ -106,6 +108,31 @@ export const GlobaLinkAccountComponent = ({ accountNumber, onCompleted }: IGloba | |||
| } | |||
There was a problem hiding this comment.
@Hugo0 this too
Merged main branch into pranut-wallet
Summary by CodeRabbit
Release Notes
New Features
GenericBannercomponent for displaying messages in a marquee format.MaintenanceBannercomponent to indicate routes under maintenance.OfframpConfirmViewandOfframpSuccessView.PromoCodeCheckercomponent for validating and applying promo codes.TokenSelectorcomponent with new state management and improved UI interactions.Bug Fixes
GeneralRecipientInputcomponent.Improvements
useAppKithook.Chores