-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wallet configuration information #97
Conversation
Signed-off-by: Ihor Zinchenko <[email protected]>
Signed-off-by: Ihor Zinchenko <[email protected]>
Thank you @zanctor for your contribution. I find the support for this scenario interesting, I believe it would be helpful to include information on how to manage the next requests after pairing. The wallet owner should manage this redirection to pop and remove the created tab. Anyway, in my opinion, auto-closing tabs immediately after opening is not an elegant approach. I have attached a video showing the results: Please let us know if you have a better experience in any way. |
return; | ||
} | ||
|
||
const wcUri = uri.searchParams.get("uri"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand, there should also be managed a request that is not for pairing but the next requests like wc?requestId=xxx
With auto-closing approach user will see the page for a fraction of a second and that's exactly what's happening with deeplinks on mobile. But for DApps when they don't need to add anything for new wallets support and just using WC logic that's already integrated is beneficial. Next requests from DApps will be transferred through WC transport in the existing session. So no need to do anything else. This part is only needed for pairing (in a way like deeplinks do). |
Absolutely no, the deepLink on mobile is natively contemplated and you don't see any rare behaviour when opening. I agree that is better to use WC capabilities but I think this won't fulfil the necessities of all dApps. My suggestion is to keep both possibilities, open the wallet through WC logic or the suggested approach in Feat/extension popup (#82) improved by eip-6963 |
Please take a look at the comment in #PR-82 regarding this particular goal |
hey @zanctor just checking in on this PR. Should we revisit this? I know we've had some updates since this PR was added. Thanks! |
closing this for inactivity. Please feel free to re-open if this should be reviewed again |
Description:
This PR adds information on configuring a wallet application properly to use the WalletConnect pairing modal.
The suggested approach should help solve the communication problem (#82) between a dApp and an extension wallet using standard WalletConnect capabilities.
Checklist