[v0.50.0] Allow visiting extrinsic fields in subxt_historic

[jsdw]

There are two main ways to decode some data that exist in Rust-land right now:

1. via traits like scale_decode::DecodeAsType and scale_decode::DecodeAsFields
2. viascale_decode::visitor::decode_with_visitor(..) and scale_decode::visitor::Visitor.

The first is the "higher level" approach, where in most APIs you simple give some type you want the bytes to be decoded into and get back that type if decoding works.

The second is "lower level" and is what the first is built upon. This isn't typically exposed, but in some cases can be very useful. One such case is addressing things like https://github.com/paritytech/polkadot-rest-api/pull/36#discussion_r2538499050, where we want to know the names of types for instance.

This PR adds a visit method to extrinsic fields in subxt_historic which allows them to be visitored with said Visitor type, and adds a usage of this in the extrinsics example so that you can see roughly how it's used.

This is somewhat of a workaround to the fact that we have to handle two different type ID / type resolver types in this version of subxt_historic. In future versions, either:

1. the visit() method will be much simpler to implement internally, or
2. it will not exist, but you'll be able to easily fetch everything you need to call scale_decode::visitor::decode_with_visitor(..) yourself anyway, which is all that is done in the visit method anyway.
3. for cases where you just want type information and not to actually decode the type, you'll just be able to fetc hthe u32 type ID, and look up the type in the scale_info::PortableRegistry to find the information you need, without any visitor related stuff.

See examples/extrinsics.rs for an example of what we can do with a visitor.

Note: I also updated the subxt codegen CLI command to accept legacy metadatas; this is helpful to test what sort of types are generated (aside from possibly being useful in the future)

\cc @TarikGul

[jsdw]

I updated the codegen to work with historic metadatas so that it's possible to see what sorts of types we get back for things in actual generated code.

[jsdw]

Just a couple of tweaks to support the CLI command update; not really relevant for the historic example!

[TarikGul]

@jsdw This is a huge win, thank you. So from what I understand this adds the visit() method from scale_decode onto the extrinsic fields.

So I think for us it would look something like:

  fn convert_extrinsic_fields_to_ss58(
      extrinsic: &Extrinsic,
      ss58_prefix: u16
  ) -> serde_json::Value {
      let mut converted_args = Map::new();

      for field in extrinsic.call().fields().iter() {
          let type_name = field
              .visit(GetTypeName::new())
              .ok()
              .flatten();

          let value = field.decode_as::<scale_value::Value>()?;

          let converted_value = if type_name == Some("AccountId32") {
              convert_account_id_to_ss58(&value, ss58_prefix)
          } else {
              // Recursively handle nested types (Is this correct?)
              convert_bytes_to_hex(value, ss58_prefix, Some(type_name))
          };

          converted_args.insert(field.name().to_string(), converted_value);
      }

      Value::Object(converted_args)
  }

[TarikGul]

@jsdw Do you know if it will be possible for us to extend this to events as well?

[TarikGul]

At first I was confused by this by I guess the idea is u32 is a Copy, and LookupName requires the clone()?

[jsdw]

Exactly! LookupName tries to avoid allocating in "normal" cases but alas requires cloning still since it can't guarantee to avoid them.

[TarikGul]

Super solid! 🚀

[jsdw]

I've added a visit method onto storage values, too, which I hope will be what you need w.r.t events :) The only thing it's not on now is storage keys, which I can also add it to if need be so just lemme know!