Skip to content
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

Convert primitives to object-with-baseclass #158

Closed
jacogr opened this issue Jun 30, 2018 · 3 comments
Closed

Convert primitives to object-with-baseclass #158

jacogr opened this issue Jun 30, 2018 · 3 comments

Comments

@jacogr
Copy link
Member

jacogr commented Jun 30, 2018

This one is a bit involved, so it probably makes sense starting with 1, seeing how it goes (implementing across the tree, i.e. here, api & apps) and then taking it further.

Basically, atm any value actually refers to the base type. For this example, let's take BlockNumber. In effect, it is type BlockNumber = BN, the idea is -

// probably may not be needed to pass generic, probably just Uint8Array (sliceables)
interface ParamEncoder <S> {
  encode (): S;
  toJSON (): any;
}

interface ParamDecoder <C, O> {
  decode (input: S): C;
  fromJSON (input: any): C;
}

interface BaseParam <T> { // or BasePrimitive, or BaseType, or...
  value: T;
}

class BlockNumber implements ParamEncoder<Uint8Array>, BaseParam<BN> {
  value: BN;

  encode (): Uint8Array {
    // ... convert to sliceable
  }

  toJSON (): any {
    // yes, we have utils for this, just a sample
    return '0x' + this.value.toString(16);
  }

  static decode (input: Uint8Array): BlockNumber {
    return new BlockNumber(...);
  } 

  static fromJSON (input: any): BlockNumber {
    return new BlockNumber(...);
  }
}  

The benefits we get -

  1. consistent interface for all values
  2. encoding/decoding is not done in different places across the codebase
  3. instead of import encoder from '@polkadot/primitives/bn/encoder'; enoder(bn) we just do bn.encode()

BlockNumber here is actually an interesting one -

  1. It may encode differently depending on chain (sizes, Nonce & Balance are currently good examples of this)
  2. It shares the same type with others, only differring in length, i.e. Balance & Nonce are also with the same logic.
  3. With the above in mind, it probably makes a bit more sense doing Nonce or Balance first (the latter has further-reaching UI impacts, so Nonce conevrs all the bases, but has a lesser footprint)
@jacogr jacogr added this to To Do in @polkadot{.js} via automation Jun 30, 2018
@jacogr
Copy link
Member Author

jacogr commented Jul 13, 2018

This is a bit of a monster, even just to get started. So PR #172 started, need to decide -

  1. How to pass through the encoding size (could be 32 or 64 here, depending on chain/impl)
  2. How to handle storage with that (not an issue here, but will be AccountId where the accounts are enumerated)

So... structure is there about more-or-less at this point what is expected, but need to make sure we don't paint ourselves into a corner.

@jacogr
Copy link
Member Author

jacogr commented Oct 24, 2018

Closing done in API polkadot-js/api#161

@jacogr jacogr closed this as completed Oct 24, 2018
@polkadot{.js} automation moved this from To Do to Done Oct 24, 2018
@polkadot-js-bot
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.

@polkadot-js polkadot-js locked as resolved and limited conversation to collaborators Jun 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
Development

No branches or pull requests

2 participants