telescope

telescope copied to clipboard

Before Telescope 1.0, the generated messages only contained the object fields that are present in the protobuf message declaration. Now, the meta field typeUrl/$typeUrl is added. This causes issues when using the message in testing frameworks that do equality checks.

I know I somwwhat requested that addition. But seeing the consequences now I think it's not a great way to implement the feature. Ideally we can keep the proto fields and meta fields separate. Maybe it's better to add the type URL on the type instead of the instance. If you have ideas for this, let me know.

In the meantime I'll use this for cosmjs-types:

    prototypes: {
      addTypeUrlToDecoders: false,
      addTypeUrlToObjects: false,
    }

Oh, that makes sense to remove $typeUrl for equality checks.

Just wondering do we have to also remove typeUrl fields inside the objects that do encode and decode?

I think it's still possibly safe to have sth like this:

// addTypeUrlToObjects: true
export const WeightedVoteOption = {
  typeUrl: "/cosmos.gov.v1beta1.WeightedVoteOption",
  encode(message: WeightedVoteOption, writer: BinaryWriter = BinaryWriter.create()): BinaryWriter {
  decode(input: BinaryReader | Uint8Array, length?: number): WeightedVoteOption {

Just curious about that can we still leave addTypeUrlToObjects on.

Thank you very much

Just wondering do we have to also remove typeUrl fields inside the objects that do encode and decode?

I think those are actually fine (addTypeUrlToObjects: true) because they do not affect the data objects but only the types. There the field is good to have.

The real issue seems to be addTypeUrlToDecoders: true which adds the $typeUrl field to the Any instances.

---

Edit: thank you for the quick reponse. I was not aware that the problem really only affects the one case of Any.

And for $typeUrl, it would be very helpful that we have it for identifying proto type of an interface. It's really a bad news that we have to discard it.

But I guess we can generate "is" functions for those interfaces that need identify, like:

function isClientUpdateProposal(
  message: Partial<ClientUpdateProposal>
): message is ClientUpdateProposal {
// identify fields and their types
}

In this way we can tell their types when we need. If we go with this way, I think only those ones with "cosmos_proto.implements_interface" need "is" functions, there're not that many of them.

if you think this's a good idea, I'll work on this soon

Can you show me where/how the field $typeUrl is currently used? Maybe I have better ideas then.

It's used to generate like this, only for those with "cosmos_proto.implements_interface" and when the option interface.enabled is on:

export interface ModuleAccount {
  $typeUrl?: "/cosmos.auth.v1beta1.ModuleAccount";
  baseAccount?: BaseAccount;
  name: string;
  permissions: string[];
}

we use it to identify the polymorphic types in the application layer

e.g. for Osmosis Pools there are tons of Pool types:

https://github.com/cosmology-tech/create-cosmos-app/blob/6f12acbcdfdae0ead3460af2b0ace975c3e21ff2/examples/provide-liquidity/utils/pool.ts#L177

https://github.com/cosmology-tech/create-cosmos-app/blob/6f12acbcdfdae0ead3460af2b0ace975c3e21ff2/examples/swap-tokens/hooks/usePools.ts#L29-L30

cc @webmaster128

I've done recursive object cloning in tests and strip out properties, like $typeUrl. Would that help or are there more than tests that needs this removed?

we do this in ts-codegen, here is an example that would work to get equality checks passing: https://gist.github.com/pyramation/95f7b3d97daaa384030df6224729ca2b