fix: remaining ux issues #401
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
📝 Walkthrough📝 Walkthrough## Walkthrough
The changes in this pull request involve modifications across several components. In the `KYCComponent`, the logic for determining the `initialStep` prop has been updated to check for the user's email. The `Profile` component has undergone changes in state management, rendering logic, and import statements, enhancing user navigation and interaction. The `CreateRequestLink` component now utilizes `useRouter` to redirect users to the home page when at the first step. The `InitialView` component has refactored how token logos are handled, improving code readability while maintaining existing functionalities. Additionally, the `TokenSelector` component has been updated to include a new prop for connection requirements.
## Changes
| File | Change Summary |
|-------------------------------------------|----------------------------------------------------------------------------------------------------|
| src/components/Kyc/index.tsx | Updated `initialStep` logic to check if `user?.user?.email` is defined instead of just `user`. |
| src/components/Profile/index.tsx | Removed unused imports, added `Link` for KYC navigation, enhanced state management, and improved error handling in `handleSiwe`. |
| src/components/Request/Create/Create.tsx | Added `useRouter` import and modified `handleOnPrev` to redirect to home page when at the first step. |
| src/components/Request/Pay/Views/Initial.view.tsx | Refactored token logo handling by introducing `chainDetails` constant and updating rendering logic to use `tokenRequestedLogoURI`. Maintained existing functionalities for transaction fees and wallet connection. |
| src/components/Global/TokenSelector/TokenSelector.consts.ts | Added optional property `shouldBeConnected` to `TokenSelectorProps` interface. |
| src/components/Global/TokenSelector/TokenSelector.tsx | Integrated `shouldBeConnected` prop to manage fallback display logic based on connection status. |
## Possibly related PRs
- **#376**: The changes in `TokenSelector.tsx` regarding state management for token and chain placeholders may relate to the `KYCComponent` since both components deal with user-related data and interactions.
- **#395**: The updates in `TokenSelector.tsx` to improve token selection logic could be relevant as they may affect how user data is handled in conjunction with the `KYCComponent`.
- **#396**: The addition of the "cashout" link in the `Header` component could be related to the `KYCComponent` as both may involve user verification processes.
- **#399**: The refactor of the navbar components, including the addition of the cashout feature, may connect with the `KYCComponent` as both are part of the user interface that interacts with user data and actions.
## Suggested reviewers
- Hugo0📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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
🧹 Outside diff range and nitpick comments (1)
src/components/Request/Pay/Views/Initial.view.tsx (1)
249-249: Consistent use of new token logo URIThe use of
tokenRequestedLogoURIin theimgtag is consistent with the new approach introduced earlier. This change simplifies the code and improves maintainability.Consider adding an
altattribute with a more descriptive text for better accessibility. For example:-<img src={tokenRequestedLogoURI} className="absolute left-0 top-0 h-6 w-6" alt="logo" /> +<img src={tokenRequestedLogoURI} className="absolute left-0 top-0 h-6 w-6" alt={`${requestLinkData.tokenSymbol} logo`} />
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- src/components/Request/Pay/Views/Initial.view.tsx (2 hunks)
🔇 Additional comments (2)
src/components/Request/Pay/Views/Initial.view.tsx (2)
197-202: Improved token logo handling logicThe introduction of
chainDetailsand the new approach to derivetokenRequestedLogoURIis a good improvement. It centralizes the logic for obtaining the token logo URI, making the code more maintainable and easier to understand. The use of optional chaining (?.) is a good practice to prevent potential runtime errors.
Line range hint
1-368: Summary of changesThe modifications in this file focus on improving the handling of token logos. The introduction of
chainDetailsand the new approach to derivetokenRequestedLogoURIcentralizes the logic and makes the code more maintainable. These changes are well-implemented and do not alter the overall functionality of theInitialViewcomponent.The refactoring enhances code readability and reduces the likelihood of errors when working with token logos. It's a good example of incremental improvement in code quality.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
src/components/Request/Create/Create.tsx (1)
34-36: Consider user expectations with this navigation changeThe modification to redirect users to the home page when they're at the first step and attempt to go back is a good improvement in terms of navigation. It provides a clear exit point from the create flow.
However, this change might be unexpected for users who are accustomed to the previous behavior. Consider the following suggestions:
- Add a confirmation dialog before redirecting to ensure users don't lose any entered data accidentally.
- Update any relevant documentation or user guides to reflect this new behavior.
- Consider adding a visual indicator (like a "home" or "exit" icon) on the first step to make this functionality more discoverable.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- src/components/Request/Create/Create.tsx (2 hunks)
🔇 Additional comments (2)
src/components/Request/Create/Create.tsx (2)
7-7: LGTM: Correct import for useRouterThe import statement for
useRouterfromnext/navigationis correctly added and placed appropriately with other imports.
10-10: LGTM: Proper initialization of useRouterThe
routervariable is correctly initialized using theuseRouterhook at the top level of the functional component.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (5)
src/components/Profile/index.tsx (5)
Line range hint
2-22: LGTM: Import statements updated appropriatelyThe changes to the import statements reflect the modifications made in the component. The addition of
Linkfrom 'next/link' and the removal of unused imports improve the code's cleanliness.Consider reviewing the entire import list to ensure all imported items are still in use and remove any that are no longer needed.
Line range hint
39-40: Improved state management and error handlingThe addition of the
modalTypestate and the enhancements to thehandleSiwefunction improve the component's functionality and user experience. The error handling inhandleSiweis particularly beneficial.Consider using a more specific error message in the
catchblock ofhandleSiwe. Instead of a generic message, you could provide more context based on the type of error encountered.Also applies to: 79-124
398-406: Enhanced KYC badge with improved interactivityThe modifications to the KYC badge improve its functionality and user experience. The addition of the
select-noneclass, theLinkcomponent for non-verified users, and the hover effect are all positive changes.Consider adding an
aria-labelto the Link component for better accessibility. For example:- <Link className="px-2 py-1" href={'/kyc'}> + <Link className="px-2 py-1" href={'/kyc'} aria-label="Complete KYC verification">
Line range hint
224-270: Improved data fetching and state management in useEffect hooksThe refinements to the useEffect hooks enhance the component's efficiency in managing state updates and data fetching. The new hook for fetching link details for visible data is particularly beneficial for performance.
Consider implementing a debounce mechanism for the
_fetchLinkDetailsAsyncfunction call in the last useEffect hook. This could prevent unnecessary API calls if the user quickly changes pages or tabs. Here's an example of how you might implement this:import { debounce } from 'lodash'; // ... (inside the component) const debouncedFetchLinkDetails = useCallback( debounce((visibleData) => { _fetchLinkDetailsAsync(visibleData); }, 300), [] ); useEffect(() => { const visibleData = dashboardData .slice((currentPage - 1) * itemsPerPage, currentPage * itemsPerPage) .filter((item) => item.status === undefined); if (selectedTab === 'history' && visibleData.length > 0) { debouncedFetchLinkDetails(visibleData); } }, [currentPage, selectedTab]);This change would help to reduce the number of API calls made when the user is quickly navigating through the data.
Line range hint
1-624: Overall improvements to component functionality and user experienceThe changes made to the Profile component enhance its functionality and user experience while maintaining its core structure. The refinements in state management, data fetching, and UI elements contribute to a more robust and user-friendly component.
To further improve the code organization and maintainability, consider breaking down this large component into smaller, more focused sub-components. For example, you could create separate components for:
- UserInfo (containing the profile picture, username, and KYC badge)
- UserStats (containing the points, invites, etc.)
- TabContent (managing the different tab contents)
This would make the main Profile component more manageable and easier to maintain in the long run.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (8)
src/components/Kyc/index.tsx (1)
Line range hint
1-85: Consider improving error handling and prop usageWhile the overall structure of the component is good, there are a few areas that could be improved:
Error handling: The component doesn't handle the case where
userexists butuser.useris undefined. This could lead to potential errors.Prop usage: The
setOfframpFormandonCompletedprops ofGlobalKYCComponentare set to empty functions. This might indicate missing functionality.To improve error handling, consider adding a check for
user.user:{!user || (user && !user.user) ? ( // Render loading or error state ) : user.user.kycStatus === 'verified' ? ( // Render verified user UI ) : ( // Render GlobalKYCComponent )}
- For the
GlobalKYCComponentprops, implement proper handlers or remove them if they're not needed:<GlobalKYCComponent initialStep={Number(Boolean(user?.user?.email))} offrampForm={{ email: user?.user?.email ?? '', name: user?.user?.full_name ?? '', password: '', recipient: '', }} setOfframpForm={(form) => { // Implement form update logic console.log('Form updated:', form); }} onCompleted={() => { // Implement completion logic console.log('KYC process completed'); }} />These changes will make the component more robust and ensure that all props are being used effectively.
src/components/Profile/index.tsx (7)
Line range hint
2-22: LGTM! Consider cleaning up unused imports.The changes to the import statements look good. The addition of
Linkfrom 'next/link' suggests improved navigation, which aligns with the UX improvements mentioned in the PR title.Consider removing any other unused imports to keep the codebase clean. You can use tools like ESLint with the
no-unused-varsrule to automatically detect and remove unused imports.
Line range hint
39-45: LGTM! Consider adding comments for new state variables.The addition of the
modalTypestate variable and the modification of the error state structure are good improvements. These changes likely contribute to better UX by providing more specific modal functionality and detailed error handling.Consider adding a brief comment explaining the purpose and possible values of the
modalTypestate variable. This will help other developers understand its usage quickly.
Line range hint
93-126: LGTM! Consider using consistent error handling.The improvements to the
handleSiwefunction are excellent. The added error handling and state updates for loading and error messages will significantly improve the user experience during the authentication process.For consistency, consider using the
setErrorStatefunction to update the error state in the catch block, similar to how it's used elsewhere in the component. This would make the error handling pattern more uniform throughout the component.
Line range hint
207-307: LGTM! Consider memoizing complex calculations.The refinements to the useEffect hooks are excellent improvements. They enhance the component's reactivity to user interactions and state changes, particularly with the addition of pagination handling. These changes will significantly improve the user experience when dealing with large datasets.
Consider memoizing complex calculations or derived state using
useMemooruseCallbackhooks. For example, the calculations in the useEffect hook that sets the table data based on the selected tab could benefit from memoization, potentially improving performance for large datasets.Example:
const memoizedTableData = useMemo(() => { // Your table data calculation logic here }, [selectedTab, dashboardData, contactsData, accountsData]); useEffect(() => { setTableData(memoizedTableData); }, [memoizedTableData]);
393-409: LGTM! Consider adding aria labels for accessibility.The modifications to the KYC badge rendering logic are excellent. The conditional rendering and the use of the
Linkcomponent for non-verified users greatly improve the user experience by providing clear visual feedback and easy access to the KYC process.To enhance accessibility, consider adding aria labels to the KYC badge. This will help users with screen readers understand the purpose of the badge and the link.
Example:
<div className={`kyc-badge select-none ${/* ... */}`} aria-label={user?.user?.kycStatus === 'verified' ? 'KYC Verified' : 'KYC Not Verified'} > {user?.user?.kycStatus === 'verified' ? ( 'KYC' ) : ( <Link className="px-2 py-1" href={'/kyc'} aria-label="Complete KYC process"> NO KYC </Link> )} </div>
Line range hint
509-589: LGTM! Consider adding loading state for referral data.The updates to the modal content for 'Boost' and 'Invites' types are excellent improvements. The detailed information display for referrals enhances the user experience by providing clear and structured data.
Consider adding a loading state for the referral data in the 'Invites' modal. This would improve the user experience in cases where the data might take a moment to load, especially for users with many referrals.
Example:
{modalType === 'Invites' ? ( <div className="flex w-full flex-col items-center justify-center gap-2 text-h7"> {isLoadingReferrals ? ( <Loading /> // Your loading component ) : user?.referredUsers > 0 ? ( // Your existing referral data display logic ) : ( <p>No referrals yet.</p> )} </div> ) : ''}
Line range hint
1-593: LGTM! Consider updating component documentation.Overall, the changes made to the Profile component are excellent improvements that align well with the PR objective of fixing remaining UX issues. The modifications enhance user interaction, improve error handling, and provide more detailed information to the user.
Consider updating or adding JSDoc comments for the Profile component to reflect the new features and behaviors. This will help maintain clear documentation as the component evolves.
Example:
/** * Profile Component * * Displays user profile information, including: * - Basic user details * - KYC status * - Points and referral information * - Transaction history * - Contacts * - Linked accounts * * @component * @example * return ( * <Profile /> * ) */ export const Profile = () => { // ... component logic }
nezz0746
force-pushed
the
fix/remaining-ux-issues
branch
from
163eb01
to
a200746
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (8)
src/components/Global/TokenSelector/TokenSelector.consts.ts (1)
9-9: Approved, but additional context and documentation needed.The addition of the
shouldBeConnectedproperty to theTokenSelectorPropsinterface is a good improvement that could enhance the component's flexibility. However, to ensure proper usage and maintainability, please consider the following:
- Add a brief comment explaining the purpose and expected behavior when this property is set to
trueorfalse.- Update any relevant documentation for the TokenSelector component to include information about this new property.
- If this change is part of a larger feature implementation, consider mentioning it in the PR description for better context.
src/components/Global/TokenAmountInput/index.tsx (2)
56-56: Approved: Added text centering to inputGood improvement to the user experience by center-aligning the text in the input field. This change is consistent with the PR's goal of fixing UX issues.
For consistency, consider moving the
text-centerclass to the beginning of the className string, grouping it with other layout-related classes:- className={`h-12 w-[4ch] max-w-80 bg-transparent text-center text-h1 outline-none transition-colors placeholder:text-h1 focus:border-purple-1 dark:border-white dark:bg-n-1 dark:text-white dark:placeholder:text-white/75 dark:focus:border-purple-1`} + className={`text-center h-12 w-[4ch] max-w-80 bg-transparent text-h1 outline-none transition-colors placeholder:text-h1 focus:border-purple-1 dark:border-white dark:bg-n-1 dark:text-white dark:placeholder:text-white/75 dark:focus:border-purple-1`}
Line range hint
1-101: Suggestions for overall component improvementsWhile the component functions well, here are some suggestions to enhance its maintainability and performance:
- Consider memoizing the
onChangefunction usinguseCallbackto prevent unnecessary re-renders.- The
parentWidthcalculation in theuseMemohook might cause layout thrashing. Consider using auseLayoutEffectfor this calculation instead.- The
utils.estimateStableCoin(1)call on line 37 seems to be unused. If it's not needed, consider removing it.- The ternary operator for the
inputType(line 18) could be simplified to a boolean expression.Here are the suggested changes:
- Memoize the
onChangefunction:const onChange = useCallback((tokenvalue: string) => { setTokenValue(tokenvalue) }, [setTokenValue])
- Use
useLayoutEffectforparentWidth:const [parentWidth, setParentWidth] = useState('auto') useLayoutEffect(() => { if (inputRef.current && inputRef.current.parentElement) { setParentWidth(`${inputRef.current.parentElement.offsetWidth}px`) } }, [])
Remove the unused
utils.estimateStableCoin(1)call.Simplify the
inputTypecalculation:const inputType = useMemo(() => window.innerWidth < 640 ? 'text' : 'number', [])These changes will help improve the component's performance and readability.
src/components/Request/Create/Views/Initial.view.tsx (1)
Line range hint
1-180: Overall: Consistent simplification of payment request flow.The changes in this file consistently remove wallet connection requirements and simplify the user flow for creating payment requests. This aligns with the PR objective of fixing remaining UX issues. The modifications include:
- Removal of wallet-related imports and logic.
- Simplification of the
handleOnNextfunction call.- Adjustment of the
TokenSelectorcomponent to not require wallet connection.- Streamlining of the "Confirm" button's onClick handler.
These changes should improve the user experience by allowing users to proceed further in the payment request creation process without needing to connect their wallet upfront. However, it's crucial to ensure that this simplification doesn't introduce issues in later stages of the process where wallet connection might be necessary.
Consider documenting this architectural change in the project's documentation or README, explaining the new flow for creating payment requests and any implications it might have for other parts of the application.
src/components/Global/Header/index.tsx (1)
Line range hint
1-314: Consider refactoring styles for improved maintainabilityWhile not directly related to the current changes, I noticed a mix of inline styles and className usage throughout the component. For future improvements, consider:
- Consistently using className for styling to improve maintainability.
- Refactoring the ToolsDropdown component to use more className-based styles instead of inline styles.
- Utilizing a CSS-in-JS solution or CSS modules for better style encapsulation and management.
These changes could enhance the overall maintainability and consistency of the codebase.
src/components/Global/TokenSelector/TokenSelector.tsx (3)
21-21: LGTM! Consider updating TokenSelectorProps type definition.The addition of the
shouldBeConnectedprop with a default value oftrueis a good improvement, allowing for more flexible usage of the component while maintaining backward compatibility.Don't forget to update the
TokenSelectorPropstype definition in the_constsfile to include this new prop.
25-29: LGTM! Consider clarifying the comment.The initialization of
showFallbackbased on!shouldBeConnectedaligns well with the component's intended behavior. The added comment provides good context.Consider updating the comment to explicitly mention the
shouldBeConnectedprop:/** * If shouldBeConnected is true and the user is not connected, we show a fallback screen to search for tokens directly, * instead of showing the balances. */
163-165: LGTM! Consider minor refactoring for improved readability.The updated condition for rendering the fallback message correctly incorporates the
shouldBeConnectedprop, ensuring the message is only shown when connection is required and the user is not connected.Consider extracting the condition into a descriptive variable for improved readability:
const shouldShowConnectPrompt = !isConnected && shouldBeConnected; {shouldShowConnectPrompt ? ( // ... existing fallback message JSX ) : !showFallback ? ( // ... existing content ) : ( // ... existing fallback content )}This refactoring would make the condition more self-explanatory and easier to maintain.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (9)
- src/components/Global/Header/index.tsx (2 hunks)
- src/components/Global/TokenAmountInput/index.tsx (2 hunks)
- src/components/Global/TokenSelector/TokenSelector.consts.ts (1 hunks)
- src/components/Global/TokenSelector/TokenSelector.tsx (2 hunks)
- src/components/Kyc/index.tsx (1 hunks)
- src/components/Profile/index.tsx (3 hunks)
- src/components/Request/Create/Create.tsx (2 hunks)
- src/components/Request/Create/Views/Initial.view.tsx (3 hunks)
- src/components/Request/Pay/Views/Initial.view.tsx (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- src/components/Kyc/index.tsx
- src/components/Request/Create/Create.tsx
- src/components/Request/Pay/Views/Initial.view.tsx
🔇 Additional comments (9)
src/components/Global/TokenAmountInput/index.tsx (1)
46-46: Approved: Removed unnecessary trailing spaceGood cleanup. Removing the trailing space in the className string improves code cleanliness without affecting functionality.
src/components/Request/Create/Views/Initial.view.tsx (3)
4-4: LGTM: Import changes align with component simplification.The removal of wallet-related imports and the addition of
useContextalign with the shift away from wallet connection management within this component. This change simplifies the component and suggests a move towards more centralized state management.
129-129: LGTM: TokenSelector alignment with new flow.The addition of
shouldBeConnected={false}to theTokenSelectorcomponent is consistent with the removal of wallet connection requirements. This ensures that users can select tokens without needing to connect their wallet first.
158-158: LGTM: Simplified confirmation process.The direct call to
handleOnNext()in the "Confirm" button's onClick handler is consistent with the removal of wallet connection logic. This simplifies the confirmation process by removing the intermediate wallet connection step.To ensure this change doesn't introduce any issues, let's verify the implementation of
handleOnNext:#!/bin/bash # Description: Check the implementation of handleOnNext function # Test: Search for the handleOnNext function definition ast-grep --lang typescript --pattern $'const handleOnNext = async () => { $$$ }'src/components/Global/Header/index.tsx (2)
265-268: LGTM: Improved text handling in MenuLinksThe addition of the
text-nowrapclass to the Text component prevents text wrapping, which enhances the button's appearance. This change aligns well with the PR's objective of addressing UX issues.
Line range hint
285-291: LGTM: Consistent text handling in SocialLinksThe addition of the
text-nowrapclass to the button in SocialLinks is consistent with the earlier change in MenuLinks. This improves overall UI consistency and prevents unwanted text wrapping, addressing potential UX issues.src/components/Global/TokenSelector/TokenSelector.tsx (3)
37-37: LGTM! Unused variable removed.Good cleanup. Removing the unused
environmentInfovariable from the destructuring ofuseWalletTypehook improves code cleanliness without affecting functionality.
158-158: LGTM! Improved conditional rendering of the previous button.The updated logic for the
showPrevprop ensures that the previous button is only displayed when it's relevant (i.e., when connection is required and the fallback screen is shown). This change aligns well with the component's intended behavior.
Line range hint
1-363: Overall, good improvements to the TokenSelector component.The changes consistently implement the new
shouldBeConnectedprop, improving the flexibility of the component while maintaining backward compatibility. The fallback screen logic and connection requirements are now more adaptable to different use cases. Good job on cleaning up unused variables and improving the overall code quality.
| @@ -131,11 +123,10 @@ export const InitialView = ({ | |||
| }} | |||
| tokenValue={_tokenValue} | |||
| onSubmit={() => { | |||
| if (!isConnected) handleConnectWallet() | |||
| else handleOnNext() | |||
| handleOnNext() | |||
There was a problem hiding this comment.
💡 Codebase verification
Potential Wallet Connection Dependencies Found: Review Required
Wallet connection logic remains in the following files:
src/components/Request/Create/Create.tsxsrc/components/Request/Pay/Views/Initial.view.tsxsrc/components/Create/Link/Input.view.tsxsrc/components/Create/Link/Success.view.tsxsrc/components/Create/Link/Initial.view.tsxsrc/components/Create/Link/Confirm.view.tsxsrc/components/Create/useCreateLink.tsx
The removal of handleConnectWallet in Initial.view.tsx may affect functionalities that rely on wallet connections. Please verify that downstream processes still operate correctly without the wallet connection check.
🔗 Analysis chain
LGTM: Simplified user flow, but verify downstream impacts.
The direct call to handleOnNext() without wallet connection checks simplifies the user flow, aligning with the removal of wallet connection logic. This change allows users to proceed without being connected to a wallet.
However, let's verify that this change doesn't introduce issues later in the process where a wallet connection might be required. Run the following script to check for any wallet connection requirements in the subsequent steps:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for wallet connection requirements in the payment request flow
# Test: Search for wallet connection logic in related components
rg --type typescript -g '**/{Create,Pay}/**/*.tsx' 'useAccount|useWeb3Modal|connect.*wallet'
Length of output: 177
Script:
#!/bin/bash
# Description: Re-run the wallet connection logic search with corrected rg command
# Test: Search for wallet connection logic in related components
rg --type typescript -g '**/{Create,Pay}/**/*.tsx' 'useAccount|useWeb3Modal|connect.*wallet'
Length of output: 129
Script:
#!/bin/bash
# Description: Search for wallet connection logic in Create and Pay components using corrected rg command
# Test: Search for wallet connection logic in related components
rg -g '**/{Create,Pay}/**/*.tsx' 'useAccount|useWeb3Modal|connect.*wallet'
Length of output: 1781
There was a problem hiding this comment.
I don't think removing the connect prompts on the request page should break anything since it's isolated @Hugo0 🤔
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
| @@ -131,11 +123,10 @@ export const InitialView = ({ | |||
| }} | |||
| tokenValue={_tokenValue} | |||
| onSubmit={() => { | |||
| if (!isConnected) handleConnectWallet() | |||
| else handleOnNext() | |||
| handleOnNext() | |||
Summary by CodeRabbit
Summary by CodeRabbit