Fix web support.

[Neopallium]

The default features of sp-core-hashing was enabling std on sp-std which causes issues with some other Substrate crates (sp-arithmetic).

[cla-bot-2021]

User @Neopallium, please sign the CLA here.

[niklasad1]

Thanks, nice catch

[jsdw]

Thankyou, this looks good to me; if we can remove a feature without breaking anything then it seems like a win!

The default features of sp-core-hashing was enabling std on sp-std which causes issues with some other Substrate crates (sp-arithmetic).

Out of interest, I am curious to know what sort of issue you encountered?

And just to note in case it matters: Substrate crates aren't released automatically at the moment (they were for a while but this is being re-worked), meaning that if you rely on Subxt's substrate crates being compatible with those you're using elsewhere in your project, you'll likely be disappointed due to version mismatches. Often times, I'd suggest just not enabling the "substrate-compat" feature flag at the moment, until we are publishing them again and can maintain some sort of alignment.

[Neopallium]

The default features of sp-core-hashing was enabling std on sp-std which causes issues with some other Substrate crates (sp-arithmetic).

Out of interest, I am curious to know what sort of issue you encountered?

And just to note in case it matters: Substrate crates aren't released automatically at the moment (they were for a while but this is being re-worked), meaning that if you rely on Subxt's substrate crates being compatible with those you're using elsewhere in your project, you'll likely be disappointed due to version mismatches. Often times, I'd suggest just not enabling the "substrate-compat" feature flag at the moment, until we are publishing them again and can maintain some sort of alignment.

I only started using subxt-signer, because of issues using Substrate crates like sp-core on non-runtime wasm (i.e. web wasm target). I am looking to use our Rust polymesh-api in the browser. I created this example egui that compiles to native and a webapp: https://github.com/PolymeshAssociation/polymesh_api_example_gui
Also working on a yew webapp example.

I maintain the Rust polymesh-api project which is like subxt but only supports Polymesh:
https://github.com/PolymeshAssociation/polymesh-api

Because of bad web "no_std" support in a lot of the Substrate crates, I have had to re-impl some basic types:
https://github.com/PolymeshAssociation/polymesh-api/blob/main/crates/polymesh-api-client/src/basic_types.rs
It has mostly been around serde support, a lot of the Substrate crates incorrectly used std feature flag for serde support. It looks like that is improving lately, but I haven't tried updating to the latest Substrate crates.

One big feature of polymesh-api that you might be interested in is how we support Ink! contracts to allow them to make runtime calls with Rust code that is very similar to how an RPC client would submit transactions:
https://github.com/PolymeshAssociation/Polymesh/blob/43f4010033db2b3351abbe9483d8bac2ddd6ab00/contracts/settlements/lib.rs#L110

We used a ChainExtension to support runtime calls and storage reads (polymesh-api hides these details), we didn't use the seal_call_runtime feature of pallet_contracts because it wasn't stabilized at the time and we would have had to modify it anyways (to switch identities and handle call permissions).

[jsdw]

Thanks for the info!

One big feature of polymesh-api that you might be interested in is how we support Ink! contracts to allow them to make runtime calls with Rust code that is very similar to how an RPC client would submit transactions

Interesting! I dug a little and didn't get super far, but would be interested to know more about this, ie do you generate code for contracts or write manual interfaces for key contracts? Layering better support for things like contracts on top of the core subxt crate is something I have in mind to look into more at some point :)

I also wonder whether there were any major issues with using Subxt that led to you creating your own library? It's the sort of thing I'd love to get feedback on!

[Neopallium]

One big feature of polymesh-api that you might be interested in is how we support Ink! contracts to allow them to make runtime calls with Rust code that is very similar to how an RPC client would submit transactions

Interesting! I dug a little and didn't get super far, but would be interested to know more about this, ie do you generate code for contracts or write manual interfaces for key contracts? Layering better support for things like contracts on top of the core subxt crate is something I have in mind to look into more at some point :)

Code is generated (from chain metadata) to support both RPC & Ink! and uses a feature flag ink to switch between code that is just for one. I want to change that later to help with compile times (apply the feature flag to the generator not the generated code).

I will open an issue to explain how it works a provide snips of generated code to help explain.

I also wonder whether there were any major issues with using Subxt that led to you creating your own library? It's the sort of thing I'd love to get feedback on!

I started working on polymesh-api over a year ago and had looked at subxt back then, but it didn't have all the features that I wanted and the api was a little bit verbose.

Another feature that I just recently added is support for decoding block events (as json) all the way back to the genesis block of Polymesh, which was tricky since Polymesh first launched with chain metadata v12 and requires a schema file polymesh_schema.json for the custom chain types.
This example uses that feature:
https://github.com/PolymeshAssociation/polymesh-api/blob/c444e452b0401d40694ba326042f56a5617d642f/crates/polymesh-api-client/examples/dump_blocks.rs#L291