Support `wallet_watchAsset` in react-celo (Valora request)

[arthurgousset]

Context

• Discord conversation

@jeanregisser on Discord:

With react-celo, what’s the best way to call a custom json-rpc method implemented by the connected client? Let’s say Valora wants to implement wallet_watchAsset (https://eips.ethereum.org/EIPS/eip-747), is everything in place in react-celo to make that call work over WCv2? Can we call send or sendAsync on the provider and it will work? WCv1 had sendCustomRequest (https://docs.walletconnect.com/1.0/quick-start/dapps/client#send-custom-request). It looks like with WCv2 sign client we need to update the namespace (client.update(...) and then we should be able to call client.request(...), https://docs.walletconnect.com/2.0/specs/clients/sign/client-api) But likely this has to be done by accessing the WCv2 client instead of indirectly via the provider.

@dckesler on Discord:

I see two options

1. Change @celo/wallet-walletconnect to make the WalletConnect Client available to consumers as it's currently a private field on the WalletConnectWallet class. Assuming the @walletconnect/sign-client is the same thing as the client api you linked then it would be a fairly simple change to this class https://github.com/celo-org/react-celo/blob/master/packages/walletconnect/src/wc-wallet.ts#L58.
2. Using rainbow-kit you can get access to the WalletConnect Client object but it's not very easy or typed very well. It is, however, possible to get it after a bit of digging.

@silasbw on Discord:

One small (maybe obvious) thing that might be helpful is to wrap the object exposed so it's EIP-1193 compliant (which is what MetaMask injects). There's a raft of google-able examples on how to use 1193 providers, and I think it would likely cut down on inbound confusion from builders if the provider we're talking about exposing here matched the examples (i.e., was compliant with 1193).

[dckesler]

There are quite a few wallet RPC methods that we should consider supporting alongside this. For now this has been deprioritized while we figure out the future of react-celo.

[arthurgousset]

Closing this issue because we are not planning to do further react-celo feature work.