-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
serde derivations for BorshSchemaContainer
#98
Comments
@itegulov Do I understand it correctly that NEAR ABI does not need Borsh Schema anymore and we can close this issue? I feel Borsh Schema does not really work well, and we should potentially redesign it. |
@frol nope, it does. I mean Borsh Schema is the only format we have that can represent borsh-serializable types. To be fair, Borsh is used much more rarely in contracts' public API from my experience, so I don't know how big of a deal the redesign would be from users' perspective. |
what is status for this? |
It would be nice to be able to (de)serialize
BorshSchemaContainer
into something human-readable. For some context, we must somehow represent a contract's borsh-serializable types in the ABI schema file. Since this file is in JSON format, we have to serialize borsh schema as JSON, which is doable in a janky way using serde's remote derivation (see near/near-sdk-rs#872). Ideally, this logic should live in this repo, but I also recognize thatborsh
would rather not depend onserde
, so maybe this functionality can be behind an optional featureschema-serde
?As for the
BorshSchemaContainer
's format, I propose we use untaggedFields
and inline all single-fieldedDefinition
variants for the sake of readability while maintaining all other underlying type names (Struct
,Tuple
etc). Borsh schema forstruct Pair(u32, u32)
would look like:See near/near-sdk-rs@979b839 for more examples.
CC @austinabell
The text was updated successfully, but these errors were encountered: