Unable to see methods

[Tarnadas]

Hey,

I tried out Raen, but it seems like I'm unable to see methods. It seems like it's not working at all.
Deployed contract:
https://raen.dev/admin/#/dex-test.shrm.testnet
I tried out both your frontend and also nearblocks.io, which supports displaying contract methods, but no luck either.

Here is the contract file:
https://drive.proton.me/urls/9N1K8RN0Q0#3KigN0oIWnAF

Let me know, if you need any more information.

[willemneal]

Hmm strange. I'll take a look at your Wasm,but the source would be the most helpful.

[willemneal]

Can you also share the files in your target/wit folder?

[Tarnadas]

orderly_dex.zip
Unfortunately they seem to look empty.
I can not yet share the source, but I really want this to be open sourced. It's the upcoming on-chain orderbook DEX from Orderly Network. I'll ask again regarding open sourcing.

One idea that might cause the issue, but haven't tested it:
My contract is in an extra lib folder. In its Cargo.toml I only enabled rlib crate type like this:

[lib]
crate-type = ["rlib"]

My actual contract has this lib as dependency:

[package]
name = "orderly-dex"
...

[lib]
crate-type = ["cdylib"]

[dependencies]
orderly-dex-lib = { path = "../contract-lib" }

and has cdylib enabled for wasm compilation. I do this to reduce code size from the wasm file, since enabling rlib makes the file quite a lot larger.

[willemneal]

Ah I see! I need to update the readme and documentation, but currently you need to add the following to the Cargo.toml any dependency that your contract uses that exposes an external interface, e.g ../contract-lib/Cargo.toml:

[package.metadata.witgen]
export = true

[Tarnadas]

Thx this works! However I have another unrelated problem I assume:

Building orderly-dex
You probably need to add a `witgen` macro to the missing type

Add 'witgen' as a dependency to add to type definition. e.g.

   1 use witgen::witgen;
   2
   3 /// Type exposed by contract API
   4 #[witgen]
   5 struct Foo {}
   6
Failed to build package: orderly-dex
Error: Failed to build package: orderly-dex

Caused by:
    expected ',', found '>'
         --> index.ts:24:79
          |
       24 | register-account: function(account-id: option<account-id>) -> expected<tuple<>>
          | 

I've been trying to fix this by slamming the #[witgen] proc macro on many things, but I think my crate structure doesn't allow it.

My contract struct is on dex.rs:

#[near_bindgen]
#[derive(BorshDeserialize, BorshSerialize, PanicOnDefault)]
#[witgen]
pub struct OrderlyDex {
    // ...
}

but I also have several other files with impls for that contract, that I added as modules.

I've been trying to track this down by installing cargo-witgen and running cargo witgen generate manually until I have no more errors. I came across this error message:

❯ cargo witgen generate
Error: no type named `u128`
     --> index.wit:34:16
      |
   34 |   limit-price: u128,
      |                ^---

Where u128 is the json_types::U128 from near_sdk. I'm not sure how to fix this. What I tried was this:

#[witgen]
use near_sdk::json_types::U128;

but then I get an error:

❯ cargo witgen generate
thread 'main' panicked at 'not yet implemented: Can only have top level path, e.g. cannot do `use other_crate::module::...`', /home/marior/.cargo/registry/src/github.com-1ecc6299db9ec823/witgen_macro_helper-0.15.0/src/generator.rs:237:13

[willemneal]

What is the rust of the return type of this:

register-account: function(account-id: option<account-id>) -> expected<tuple<>>

Raen didn't update to use the newest dependency logic for the sdk types. Instead it still drops in the needed sdk types. And as witgen says it currently doesn't support decorating imports, this is why I used the Cargo.toml trick. This dependency logic currently lives in raen should be in witgen (I'm working on upgrading it to the newest wit).

[Tarnadas]

it looks like this:

#[near_bindgen]
#[witgen]
impl OrderlyDex {
    #[payable]
    #[handle_result]
    #[witgen]
    pub fn register_account(&mut self, account_id: Option<AccountId>) -> Result<()> {
        // ...
    }

It seems to interfere with the #[handle_result] macro from near_sdk.

[Tarnadas]

forgot something. This is my Result type:

pub type Result<T> = std::result::Result<T, error::ContractError>;

#[derive(BorshSerialize, Debug, Error, FunctionError)]
pub enum ContractError {
    // ...
}

[willemneal]

Hmm yeah currently wit supports result types, however, the issue here is that witgen can't resolve your type. E.g. Result<()> --> type Result = ... And thus wit is mad about there not being a second argument to expected. I know it's not as pretty but you could try adding #[witgen] to ContractError and then for the function signature use:

use error::ContractError;

Result<(), ContractError>  // Note currently you can only use the last part of a path

If this does work let me know, I'd be interested to know what the final json schema looks like. I've wanted to improve it's enum support, but I think it shouldn't matter as much since it's not an input.

Also you should only add #[witgen] to the types that are part of the external interface. For example here: https://github.com/raendev/raen/blob/main/examples/rust-status-message-advanced/src/lib.rs

witgen is generated statically, that is it imports the whole crate as a syn::file and parses it. This makes it very fast, but means that it can't take advantage of the macro system. I have plans to integrate it with Rust Analyzer so that it can also have type resolution.

Currently there is a special case for near_bindgen when parsing and it generates the wit based on this. However, the witgen is nothing more than a tag for which elements witgen should consider. Once the resolution is added it will know the API and thus which types need to be generated and #[witgen] would go away all together!

[Tarnadas]

Ok so I made it work. Here are the steps to make it work:

• remove custom Result and use std Result instead
• add #[witgen] on every function input and output type

I had a couple more problems:

I had a naming conflict in the resulting index.ts file, because I had a function limit_order but I also had a struct LimitOrder. The function has been renamed to the same TypeScript name. I worked around this by renaming limit_order to create_limit_order.

The witgen compiler didn't seem to notice changes. If I compiled it once and it failed and then fixed that error, it displayed the same error again. I worked around this by running rm -rf target/wit before invoking raen.

The #[handle_result] from near_sdk is actually just syntactic sugar. It results in wrong type generation. I don't return results at all! It panics instead. I can work around this by not using #[handle_result], though I have not yet implemented this.

Here's the target/wit output:
orderly_dex.zip
and link to RAEN admin:
https://raen.dev/admin/#/near/dev-1675922461155-44407165648495

Also one question:
what is the easiest way to integrate this with near-api-js for view methods and wallet selector for change methods?

[willemneal]

Glad it's working! One note in case you missed it: you can add documentation to your functions and types and they'll show up on the admin panel!

Unfortunately we had support for generating JS/TS class, but removed it as it meant a dependency on the sdk and we were more focused on getting the admin panel working. The ts types are generated but each function arg is a type. So I think it would involve a little be of manual effort to add the types, but the sdk already supports creating a class given the function names.

You can also an old version of witme to generate the TS. See tenk for an example of this: https://github.com/TENK-DAO/tenk/blob/main/package.json#L49

Eventually we hope to generate the TS again, but we need to update to the newest version of WIT.

Also the #[handle_result] macro is new to me, but my guess is that it transforms to a panic that passes the error as a string.

[Tarnadas]

Exactly, #[handle_result] will desugar to a panic. I just like to write my code by return Result types. I actually initiated the debate here which resulted in that proc macro.

Will also add some doc comments soon :D

For now the json schema should be good enough. We'll maybe check later into automating this further for the TypeScript types, but I think I will use the latest version from witme. Thx for the info!