Eng_wasm crate documentation?

Developer Help
1

Hi. I was wondering why the eng_wasm, eng_wasm_derive, etc crates are not documented, for example on crates.io? Can documentation for these crates be expected soon?

I have appreciated your tutorials and guides, but there is no replacing documentation at the crate level.

For example, when there is a wildcard use statement like use eng_wasm::*; and then there are references to mysterious types like H160 without documentation it is hard to know what is going on, how to manage type conversions, etc.

Looking forward to this crate documentation! Thx.

3 Likes
2

Hi Brendan
H160 and others are documented at Supported Types, describing the secret contract types and their mapping to solidity.

Will follow up on crate docs.

2 Likes
3

Thanks, @taariq . Those docs are a helpful start.

While we are waiting for more complete crate docs, one thing I am not sure how to handle are Results with Engima secret contracts.

I would like to follow a good Result and Error pattern, but I am getting a compiler error:

the trait "eng_wasm::eng_pwasm_abi::eth::AbiType" is not implemented for "core::result::Result<(), TGError>"

Can you provide a description of proper error handling and return values in secret contracts? I could not find anything in the docs or this forum about that. Thx.

2 Likes
4

@taariq Let me know if you can provide guidance on Result and Error guestions I described above.
In addition, I would like information on how to convert the Supported Types you mentioned to and from byte arrays and Strings. Then I would be able to interoperate with them seamlessly. Thanks!

1 Like
5

Here’s a great example of decoding the decrypted output

Will revert on error handling, don’t want to shoot from the hip.

2 Likes
6

Thanks, @taariq. That is also helpful. But I am not yet working the results of secret contract results in javascript, I am still writing my secret contract in Rust! :wink: To give you a sense of the questions I keep coming across that prompted my request for crate documentation, consider:

  • Do read_state! and write_state! take a string or byte array something else as its key?
  • If I want to make a compound key for read_state!, how do I use a H160 in a format! command to prepare the compound key? What type conversions are provided by the crate and how do I do this?
  • How should I store something like an IPFS hash? Should it be using one of the provided types, or just a string?
  • Can I store anything using write_state! for which I implement Serde::Serialize? Or are there other special limitations and traits that must be implemented?

These are the kinds of things I need to know and reading the source is not an efficient way to determine them, because for example, H160 might derive from another undocumented type for which it is unclear what methods are available, etc.

So if you have answers to any of these questions, that is great! If not, then I hope this explains what crate documentation is so needed. I appreciate it.

4 Likes
7

With you now Brendan, figured you’re testing as you’re coding and while I referenced the JS code, there’s similar conversion happening in the secret contract to return that “lottery info”, it handles the U256 lottery number as a string key and also converts the output.

Meanwhile hang tight for more about crate docs and secret state/storage.

3 Likes
8

Hey @bmiller59 just confirming that we agree internally on your recommendation for improved (or at least, existing) crate docs, and will be working towards getting this done.

4 Likes
9

@ainsley Thanks for the update! Looking forward to those docs when ready. I think it’s an important component that will allow more people to write sophisticated secret contracts independently, complementing the existing tutorials.

4 Likes