Feat deser class by schema collection userfriendlyapi

[fospring]

Pre-flight checklist

• I have read the Contributing Guidelines on pull requests.
• Commit messages follow the conventional commits spec
• If this is a code change: I have written unit tests.
• If this is a new API or substantial change: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.

Motivation

add suguar to decode class, create more friendly API, resolve comment of: #370 (comment)

Test Plan

Related issues/PRs

[ailisp]

And this messages: "array"?

[fospring]

we can remove it since no reconstruct is needed. I will update it

[fospring]

removed

[ailisp]

Nice this case still works. I think this is worth mention as an example in readme, as one case in:

export class StatusDeserializeClass {
  static schema = {

[ailisp]

Looks great! I have a few minor concerns on the documentation above, other than that this api is quite easy to use and well implemented!

[gagdiez]

fixed the documentation on the doc

[gagdiez]

@fospring @ailisp I think it would be much clearer if we follow this idea: https://github.com/nameskyteam/borsher

Basically, it would look like this:

import {Schema} from 'near-sdk-js'

class Car {
  schema = { brand: Schema.string, velocity: Schema.number }
}

class Contract {
  schema = {
    field1: Schema.string,
    field2: Schema.HashMap(Schema.string, Schema.number),
    field3: Schema.Array(Schema.bigInt),
    field4: Schema.Class(Car)
    field5: Schema.Option(number)
  }
}

This has several advantages:

• The Schema object makes the schema error-proof.
• All fields are always well defined, making it easy to (de)serialize them
• It can be used across JSON and Borsh serialization.

We could even just grab the https://github.com/nameskyteam/borsher and import it directly into here.

[fospring]

@fospring @ailisp I think it would be much clearer if we follow this idea: https://github.com/nameskyteam/borsher

Basically, it would look like this:

import {Schema} from 'near-sdk-js'

class Car {
  schema = { brand: Schema.string, velocity: Schema.number }
}

class Contract {
  schema = {
    field1: Schema.string,
    field2: Schema.HashMap(Schema.string, Schema.number),
    field3: Schema.Array(Schema.bigInt),
    field4: Schema.Class(Car)
    field5: Schema.Option(number)
  }
}

This has several advantages:

• The Schema object makes the schema error-proof.
• All fields are always well defined, making it easy to (de)serialize them
• It can be used across JSON and Borsh serialization.

We could even just grab the https://github.com/nameskyteam/borsher and import it directly into here.

great suggestion! I will update it

[ailisp]

@gagdiez great suggestion! If it's adding a lot work, let's keep the behavior for:

• collections, maybe look like: Schema.Class(LookupMap, <schema of the value>)
• for primitive types like field1: Schema.string, it can be omitted from schema

[fospring]

@gagdiez great suggestion! If it's adding a lot work, let's keep the behavior for:

• collections, maybe look like: Schema.Class(LookupMap, <schema of the value>)
• for primitive types like field1: Schema.string, it can be omitted from schema

It looks a little difficult, I will try to resolve it in a new MR

[gagdiez]

@fospring sounds good to me, ping me and I'll see to help as well

[fospring]

@fospring sounds good to me, ping me and I'll see to help as well

Great!