Wallet configuration information

[zanctor]

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

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[franfernandez20]

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:
https://github.com/hashgraph/hedera-wallet-connect/assets/23079185/c7227ba5-33f2-4f15-9147-60014ba856ce

Please let us know if you have a better experience in any way.

[franfernandez20]

I understand, there should also be managed a request that is not for pairing but the next requests like wc?requestId=xxx

[Volind]

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: https://github.com/hashgraph/hedera-wallet-connect/assets/23079185/c7227ba5-33f2-4f15-9147-60014ba856ce

Please let us know if you have a better experience in any way.

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).

[franfernandez20]

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: https://github.com/hashgraph/hedera-wallet-connect/assets/23079185/c7227ba5-33f2-4f15-9147-60014ba856ce
Please let us know if you have a better experience in any way.

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

[franfernandez20]

Please take a look at the comment in #PR-82 regarding this particular goal

[tmctl]

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!