You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 that borsh would rather not depend on serde, so maybe this functionality can be behind an optional feature schema-serde?
As for the BorshSchemaContainer's format, I propose we use untagged Fields and inline all single-fielded Definition variants for the sake of readability while maintaining all other underlying type names (Struct, Tuple etc). Borsh schema for struct Pair(u32, u32) would look like:
@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.
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: