Best way to represent u64 and u128 types in JS-SDK?

[ailisp]

Currently they are all represent as bigint in JS SDK. In Rust SDK, it's more precise:

pub type BlockHeight = u64;
pub type Balance = u128;

However, it is useful to know their maximum to avoid overflow. Basic ways can be just document the fact, or a simple alias:

type u64 = bigint
type u128 = bigint
type BlockHeight = u64
type Balance = u128

A more type safe way can be using techique like this: https://github.com/skayo/TypedNumbers/blob/main/src/index.ts, but it's quite unpopular.

I wonder which is the best, JS/TS idiomatic way to do this.

[ailisp]

cc @volovyks @austinabell

[volovyks]

For the record, I suggested not to use the library and avoid u types, since they are not native to JS/TS and developers can be unfamiliar with the concept. @MaximusHaximus , what is your opinion on this?

@ailisp

type u128 = bigint
type Balance = u128

This approach can be a good compromise.

BTW, what type of error do user gets when they exids the limit?
Can we throw an error early?

[austinabell]

I would disagree that naming a bigint u128 solves that problem. Seems like it would be misleading to developers to think that the number will be constrained to that range

[ailisp]

@volovyks for Uint128, smart contract panicked, expect Uint128:

              "ExecutionError": "Smart contract panicked: Expect Uint128 for amount\n    at promise_batch_action_transfer (native)\n    at promiseBatchActionTransfer (build/promise_batch_api.js:450)\n    at test_transfer_overflow (build/promise_batch_api.js)\n"

The error is raise in our c code, when try to convert an overflowed bigint to u128/u64:

  if (quickjs_to_u128(ctx, argv[3], amount_ptr) != 0) {
    return JS_ThrowTypeError(ctx, "Expect Uint128 for amount");
  }

We also have similar check for uint64, but I test it doesn't trigger:

  if (JS_ToUint64Ext(ctx, &gas, argv[4]) < 0) {
    return JS_ThrowTypeError(ctx, "Expect Uint64 for gas");
  }

The triggered error is:

"ActionError": {
          "index": 0,
          "kind": {
            "FunctionCallError": {
              "ExecutionError": "Integer overflow."
            }
          }

I debugged on it, it's a bug/feature in our quickjs fork, original quickjs use mod 2**64, our fork is let it overflow and let wasm runtime reject it. I'll fix it there