impl NearSchema derive macro

[miraclx]

use near_sdk::NearSchema;

#[derive(NearSchema)]
#[abi(json, borsh)]
struct Value {
    field: InnerValue
}

Effectively translates into

#[derive(schemars::JsonSchema, borsh::BorshSchema)]
struct Value {
    field: InnerValue
}

When compiled targeting WASM, this is a no-op.

[miraclx]

One question though. Do we want to proxy attr macros like #[schemars], #[serde], #[validate] for schemars, and #[borsh_skip] for borsh?

[itegulov]

Hmm, does this mean that all inner values have to implement both JsonSchema and BorshSchema regardless of which one is actually needed? This is one of the things I could not implement when I tried to do this: something like "if there is a derivation for BorshSerialize & BorshDeserialize then derive BorshSchema" (and also analogously for JsonSchema). Do you think this would be impossible to achieve?

[itegulov]

One question though. Do we want to proxy attr macros like #[schemars], #[serde], #[validate] for schemars, and #[borsh_skip] for borsh?

schemars actually respects many serde attributes when deriving a schema, so yeah that would be nice. Same goes for borsh, it checks for borsh_skip when deriving BorshSchema.

[miraclx]

"if there is a derivation for BorshSerialize & BorshDeserialize then derive BorshSchema" (and also analogously for JsonSchema). Do you think this would be impossible to achieve?

using a derive macro, unfortunately yes.

Best we can do is leave BorshSchema out of NearAbi since borsh is already reexported via near_sdk::borsh so devs can manually implement BorshSchema on the types they want.

[itegulov]

Maybe we could derive JsonSchema by default and add something like this for borsh?

#[derive(NearAbi)]
#[abi(borsh)] // makes NearAbi derive `BorshSchema` instead of `JsonSchema`
struct Value {
    field: InnerValue
}

Does not seem like there is a great solution for this either way.

[austinabell]

I agree with Daniyar, both should not be expected. Would require all inner types to have both implemented. Unclear if it would be better to have one derive with attributes or just two different derives. My intuition is that the latter seems more natural, but that is very weakly held.

The issue with your example, Daniyar, is that it limits the ability to derive both types. Yes, a very niche use case, but might be a bit of a footgun

[miraclx]

limits the ability to derive both types

I actually think this might be possible, tested a small example, and it seems to work. Here's the syntax I'm working with:

#[derive(NearAbi)]
#[abi(json, borsh)]
struct Value {
    field: InnerValue
}

And omitting the attribute entirely defaults to JsonSchema.

I'll go ahead to implement this, I'll report here if I hit any blockers.

An alternative to the attribute syntax might be (if you prefer being explicit):

#[derive(NearAbi)]
#[abi(schema = "json")]
#[abi(schema = "borsh")]
struct Value {
    field: InnerValue
}

[miraclx]

Done. So, I went with the first syntax.

#[derive(NearAbi)]
#[abi(json, borsh)]
struct Value {
    field: InnerValue
}

• Defaults to implement JsonSchema when the attribute is missing.
• #[abi(borsh)] implements BorshSchema.
• #[abi(json, borsh)] implements both.

This already proxies schemars, serde attributes on the item. I'll follow this with proxying field and variant attributes as well as a test suite for guaranteeing stability.

In the meantime, let me know what you think.

[itegulov]

Also would be cool to add some use cases of this macro to compilation_tests.

[austinabell]

what does putting this in a mod do?

[miraclx]

NearSchema's expansion effectively adds derives to a clone of the structure.

#[derive(NearSchema)]
struct Value {
    field: InnerValue
}

expands into

struct Value {
    field: InnerValue
}

const _: () = {
    mod __near_abi_private {
        #[derive(schemars::JsonSchema)]
        struct Value {
            field: InnerValue
        }
        
        impl schemars::JsonSchema for super::Value { ... }
        //                            ^^^^^
        // disambiguates the cloned structure from the original one
    }
};

[austinabell]

oh, I see, so you want to avoid the type name being something different from the original for the purposes of schemars, which uses the type name or something?

[miraclx]

Yeah, borsh also uses the type name. Honestly, it's mostly because of Borsh. Depending on the structure, borsh uses the name quite extensively.

[miraclx]

Bump on this. super::* requires the type to exist in a module. And would fail in this case.

mod x {
    fn a() {
        #[derive(NearSchema)]
        pub struct MyType;
    }
}

super::MyType from the injected __near_abi_private module would reference x::MyType, which is nonexistent.

[miraclx]

Resolved to expanding to this instead:

struct Value {
    field: InnerValue
}

const _: () = {
    type Value__NEAR_SCHEMA_PROXY = Value;
    {
        #[derive(schemars::JsonSchema)]
        struct Value {
            field: InnerValue
        }
        
        impl schemars::JsonSchema for Value__NEAR_SCHEMA_PROXY { ... }
    }
};

[austinabell]

can we put this export under unstable as well for now? Doesn't seem clear this will be more intuitive than deriving the traits directly yet and the internal semantics aren't tested yet.