Decorate RegenApi to have all queries

[amaury1093]

Before

Right now, to make a query, we need to do the following:

regen-js/packages/api/src/api.spec.ts

Lines 17 to 20 in 6460062

	const impl = new QueryClientImpl(api.connection);
	const res = await impl.AllBalances({
	address: 'regen:1j9h8dpu7ah2hl9rg7ycu0e64kh90rrlpk9kagz', // Amaury's account.
	});

After

Ideally, what we want is:

api.query.cosmos.bank.v1beta1.AllBalances({ address });

I.e. create a .query field on RegenApi, and decorate with all the queries that are found in the proto files.

Proposals

1. we use ts-proto right now as generation tool. Maybe it's worth (and not too hard) to build our own generation tool to output exactly what we want.
2. ts-proto outputs everything in the src/generated folder. Maybe we could use export * from './{file} everywhere, and decorate the query object at runtime:

import * as genProto from './src/generated';

class RegenApi {
  private decorateQuery() {
    this.query = Object.keys(genProto).reduce((acc, namespace) => {
      acc[namespace] = Object.keys(namespace).reduce(...)

      return acc;
    }, {});
  }
}

The challenge here with method 2 is keeping TS types (doable though, but be ready for generics all over the place).

[aaronc]

Proposals

1. we use ts-proto right now as generation tool. Maybe it's worth (and not too hard) to build our own generation tool to output exactly what we want.

👍

Ideally we want separate namespaces (i.e. regen and cosmos) in separate npm packages (doesn't seem possible with ts-proto now). That way people could say publish a widgets library using just the cosmos types that other apps can import.

What else would the custom generation tool do @amaurymartiny ?

[amaury1093]

Ideally we want separate namespaces (i.e. regen and cosmos) in separate npm packages (doesn't seem possible with ts-proto now).

I think it's possible, in #7 I created a @regennetwork/proto-cosmos package with only cosmos (and 3rd party) types. The idea is that we run protoc twice, once in each package.

What else would the custom generation tool do @amaurymartiny ?

I can mainly think of generating convenient interfaces that would improve UX:

1. for queries, something like proposed above: myBalance = await api.query.cosmos.bank.v1beta1.AllBalances({ address }); (client conn, query impl etc are all hidden from users)

2. interop with cosmjs with nice UX

const msg1: Any = api.tx.cosmos.bank.v1beta1.send({...}); // ts-proto normally returns MsgSendResponse, with our fork we can have Any
const msg2: Any = api.tx.regen.data.v1alpha1.signData({...});
// Then plug the Anys into cosmjs

3. multiple messages with TS-typed callbacks

txBuilder.addMsg(api.tx.cosmos.bank.v1beta1.send({...}, (res)=>{
  // callback with `res` is called when we get a TxResponse from the node,
  // and res has correct TS typings
});
txBuilder.addMsg(...); // can create tx with multiple Msgs, each with their own callback

4. Possibly well-typed event listening, but I may need to dig a bit more into that.

[aaronc]

Ideally we want separate namespaces (i.e. regen and cosmos) in separate npm packages (doesn't seem possible with ts-proto now).

I think it's possible, in #7 I created a @regennetwork/proto-cosmos package with only cosmos (and 3rd party) types. The idea is that we run protoc twice, once in each package.

Do the two packages depend on each other correctly then? Or are there duplicated types? Maybe doesn't matter so much if they're just js interfaces...

[frumioj]

Is there a way to have an abbreviated default version of api.query.cosmos.bank.v1beta1.AllBalances({ address }); be regen.AllBalances({ address }); ?