-
Notifications
You must be signed in to change notification settings - Fork 11
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
Add support for WalletConnect v2 #13
Conversation
❌ Deploy Preview for legder-connect-kit failed.
|
89e3d61
to
92527ae
Compare
Hi @nenadV91, I forgot to mention that to test it with Ledger Live you need the new version of the WalletConnect Live App (not released yet). To confirm that v2 works without depending on LL you can scan the QR code (or copy and paste it from the browser console) with a third party mobile wallet that supports v2, like Trust or Zerion. I will make the encoded URI the ledgerlive:// deep link when the Live App is released. Instructions for installing the new Live App are on the Ledger Slack (accessible to Ledger employees only): https://ledger.slack.com/archives/C04JHL7AQBF/p1677492460127719. It might be enough to check that the connection works but it is outdated and has some bugs that have already been fixed. I've been running the latest version directly from the repo. |
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.
Some small stuff, if you want more infos or discuss some of my comments we can do that on a huddle too
declare module '@walletconnect/legacy-provider/dist/umd/index.min.js' { | ||
import WalletConnectProvider from '@walletconnect/legacy-provider/dist/umd/index.min.js'; | ||
export default WalletConnectProvider | ||
}; |
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.
Why do you need this file and types declarations ?
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.
The WalletConnect packages are not browser safe, there is an open issue since 2020 and I've commented on it: WalletConnect/walletconnect-monorepo#341
The solution is to consume the pre bundled package instead of trying to bundle it together with your own lib: WalletConnect/walletconnect-monorepo#341
If importing the @walletconnect/ethereum-provider directly you will have all sorts of problems with nodejs dependencies, even after trying to polyfill them.
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.
Added a comment on the file mentioning this.
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.
Making it a peer dependency instead of bundling it might avoid this altogether.
// placeholder functions until the component is initialized | ||
let setModalUri = (uri: string) => {}; | ||
|
||
// called by the WalletConnect display_uri event handler to set a new URI | ||
export let setWalletConnectUri = (uri: string): void => { | ||
log('setModalUri', uri); | ||
setModalUri(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.
You might want to use a provider instead for managing a shared/global state
useEffect(() => { | ||
previousUriRef.current = 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 think it's better to only update when needed
useEffect(() => { | |
previousUriRef.current = uri; | |
}); | |
useEffect(() => { | |
previousUriRef.current = uri; | |
}, [uri]); |
if (uri !== previousUri && uri !== wcUri) { | ||
setWcUri(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 think we should move this inside the useEffect
packages/connect-kit/src/components/UseLedgerLiveModal/UseLedgerLiveModal.tsx
Outdated
Show resolved
Hide resolved
return new Promise(async (resolve, reject) => { | ||
try { | ||
if (!provider?.session?.connected) { | ||
showExtensionOrLLModal('', reject), | ||
|
||
// connect initializes the session and waits for connection | ||
await provider.connect(); | ||
} else { | ||
log('reusing existing session'); | ||
} | ||
|
||
// call the original provider request | ||
return resolve(await baseRequest({ method, params })); | ||
} catch(err) { | ||
logError('error', err); | ||
return reject(err); | ||
} | ||
}); |
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.
You might want to change the way this Promise is done as it looks like an anti-pattern with the async/await: https://stackoverflow.com/a/43050114
Also this talk (https://www.youtube.com/watch?v=XV-u_Ow47s0) is interesting
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.
Fixed, I've replaced the async/await with .then
I understand the "anti-pattern" issue is due to the risk of not correctly handling the errors when using async within a promise constructor. The whole purpose of patching the provider in this way is to get the "user rejected request" error to the dApp UI when the modal is closed. So in this case reject is being passed as the onClose callback to the modal component and also in the catch block to hadle the error correctly.
Nice talk!
if (method === 'eth_requestAccounts') { | ||
log('calling patched', method, params); | ||
|
||
return new Promise(async (resolve, reject) => { |
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.
Same comment as for WalletConnectEvm
389b08f
to
ccff5af
Compare
2cfabdb
to
a431778
Compare
- add workspaces to root `package.json` so we can test demo app with local loader package without manual linking - moved `checkSupport` parameter types and their management to a `supportOptions` module, added parameters for WalletConnect v2, sets defaults for chain parameters, `getSupportOptions` is called by other modules - renamed `ExtensionUnavailableModal` to `ExtensionInstallModal` - renamed `ConnectWithLedgerLiveModal` to `UseLedgerLiveModal` - renamed the `Ethereum` provider to `ExtensionEvm` since it is used for Polygon and future EVM chains, moved chain compatibility checks there, renamed related constants and types - renamed `Solana` to `ExtensionSolana` since this is through the extension, and we might support Solana through WalletConnect as well in the future - renamed the original `WalletConnect` module to `WalletConnectLegacy` which now imports the dist file from `@walletconnect/legacy-provider`, updated the module declaration in `src/@types/index.d.ts` - created a new `WalletConnectEvm` module for the v2 provider which imports the dist file from `@walletconnect/ethereum-provider` v2, added a new module declaration in `src/@types/index.d.ts` - removed the `TryConnectEthereum` module - when the extension is supported but not installed we now default to the `WalletConnect` provider instead of the extension one, this will make it possible to use WC in that case if the user needs it - the modal module now has a `showExtensionOrLLModal` function with the logic to show the `ExtensionInstallModal` if both the user's platform and the required chains are supported, or the `UseLedgerLiveModal` one - the `eth_requestAccounts` request on both WalletConnect provider modules now call `showExtensionOrLLModal` - `getProvider` now returns the `WalletConnectLegacy` provider if the version parameter is 1 or the `WalletConnectEvm` one otherwise - store result of `checkSupport` in a module variable and make it available through `getSupportResult`, is used by `showExtensionOrLLModal` to decide which modal to show - made some changes to the rollup config to be able to bundle @walletconnect/ethereum-provider v2
Fixes LIVE-7738
- add await to calls to baseRequest inside eth_requestAccounts - remove event handlers before adding again
60ebfac
to
431dfbe
Compare
2595543
to
f57c449
Compare
- update package versions - rename version parameter to walletConnectVersion - update connect-kit-loader's tsconfig outDir
f57c449
to
ee9cbcc
Compare
Changes
package.json
so we can test demo app with local loader package without manual linkingcheckSupport
parameter types and their management to a supportOptions module, added parameters for WalletConnect v2, sets defaults for chain parameters,getSupportOptions
is called by other modulesExtensionUnavailableModal
toExtensionInstallModal
ConnectWithLedgerLiveModal
toUseLedgerLiveModal
Ethereum
provider toExtensionEvm
since it is used for Polygon and future EVM chains, moved chain compatibility checks there, renamed related constants and typesSolana
toExtensionSolana
since this is through the extension, and we might support Solana through WalletConnect as well in the futureWalletConnect
module toWalletConnectLegacy
which now imports the dist file from@walletconnect/legacy-provider
, updated the module declaration insrc/@types/index.d.ts
WalletConnectEvm
module for the v2 provider which imports the dist file from@walletconnect/ethereum-provider
v2, added a new module declaration insrc/@types/index.d.ts
TryConnectEthereum
module - when the extension is supported but not installed we now default to theWalletConnect
provider instead of the extension one, this will make it possible to use WC in that case if the user needs itshowExtensionOrLLModal
function with the logic to show theExtensionInstallModal
if both the user's platform and the required chains are supported, or theUseLedgerLiveModal
oneeth_requestAccounts
request on both WalletConnect provider modules now callshowExtensionOrLLModal
getProvider
now returns theWalletConnectLegacy
provider if the version parameter is 1 or theWalletConnectEvm
one otherwisecheckSupport
in a module variable and make it available throughgetSupportResult
, is used byshowExtensionOrLLModal
to decide which modal to showWC v1 testing information
[WalletConnectLegacy] getWalletConnectLegacyProvider
on the consoleWC v2 testing information
[WalletConnectEvm] getWalletConnectProvider
on the console