cli

cli copied to clipboard

Currently, you can only instantiate the client with a wallet object (either keplr or cosmjs)...this makes it harder to use keplr since you need the client to get the info to do a suggestChain....

New version is backwards compatible (i.e. can be instantiated the same way) but you can also instantiate without a wallet (making only the query methods usable) and can attach a wallet (or useKeplr) at a later time.

Client is now also an eventemitter so individual modules can be notified of an instantiated/switched wallet and reinstantiate their txClient with the new wallet.

You can now use it like this:

const client = new Client({ apiURL, rpcURL, prefix});
client.useKeplr(chainInfo);

chainInfo is type Partial<ChainInfo> where ChainInfo is the type of object passed to Keplr's experimentalSuggestChain() method.

useKeplr() tries to obtain all the required ChainInfo information automagically. Those auto-discovered ones can then be overridden by anything passed to the useKeplr() call explicitly.

Visit the preview URL for this PR (updated for commit 6b12521):

https://ignite-go-docs--pr2856-feat-ts-client-impro-868dn0vf.web.app

_{(expires Tue, 11 Oct 2022 11:27:38 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

@clockworkgr can we make ignite client agnostic from wallets?

So instead of a userKeplr func, I would say it should be a plugin that comforts a Signer interface. And we create both cosmjs and keplr plugins inside in ignite client.

But user should be limited and not able to pass multiple wallet plugins, if so, ignite client can throw errors.

What do you think?

@clockworkgr can we make ignite client agnostic from wallets?

So instead of a userKeplr func, I would say it should be a plugin that comforts a Signer interface. And we create both cosmjs and keplr plugins inside in ignite client.

But user should be limited and not able to pass multiple wallet plugins, if so, ignite client can throw errors.

What do you think?

That was my initial plan and it's relatively easy to implement... we just add a public variable to the generic client called signingPlugin of type SigningPluginInterface that has an init() and a signAndBroadcast(msgs,fee,memo) method....Any object conforming to that type can be then added as the signingPlugin. we run init() on registration (so Keplr one for example could do the chain suggestion) and use the client.signingPlugin.signAndBroadcast() method everywhere else with standard msgs/fee/memo payload.

The problem is that this breaks the simple direct txClient usage in each module as those signing calls now depend on something provided by the client which is not available when using them directly...

Thoughts?

Visit the preview URL for this PR (updated for commit c32fe23):

https://ignite-go-docs--pr2856-feat-ts-client-impro-868dn0vf.web.app

_{(expires Fri, 21 Oct 2022 09:06:08 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 6a3f3838d2b9d95930a15fc246edf13896cc1215}