Ensure tableId is valid type at runtime

[joewagner]

Overview

This makes the error message returned from an invalid call to Validator.getTableById() easier to understand.

Details

@dtbuchholz After looking into this I was reminded that the types are being generated from our API spec, so allowing tableId to be number or string or BigNumber was not a good solution. Forcing the type to be string at runtime seems like the best path.
Interesting side note: in the process of setting this up I noticed that if you call
validator.getTableById({chainId: 31337, tableId: 9007199254740993});
the resulting http request is
<api path>/tables/31337/9007199254740992
Specifically anything bigger than Number.MAX_SAFE_INTEGER will potentially result in a request for the wrong table. Not a big deal because there are nowhere near that many tables.

fixes #470

[dtbuchholz]

gotcha. and one day, we'll hit that max!! until then...makes sense.

[dtbuchholz]

@joewagner i do wonder, though, if this will lead to confusion because i'd definitely assume tableId is a number, considering it's a numeric value to the human eye as well as its on-chain representation.

thinking about it again, maybe BigInt and .toString() could be used to ensure spec conformity?

const tokenId = BigInt(Number.MAX_SAFE_INTEGER + 1)
console.log(tokenId.toString());
// 9007199254740993 -> pass this to the API

[joewagner]

@joewagner i do wonder, though, if this will lead to confusion because i'd definitely assume tableId is a number, considering it's a numeric value to the human eye as well as its on-chain representation.

thinking about it again, maybe BigInt and .toString() could be used to ensure spec conformity?

I can definitely understand wanting to allow bigint or number here. The allowed type is defined in the spec https://github.com/tablelandnetwork/docs/blob/main/specs/validator/tableland-openapi-spec.yaml#L182
I can definitely find a way to work around things for typescript folks, but it feels weird to have a type defined in the spec that's different than what the SDK allows. @carsonfarmer do you have any suggestions, or thoughts here?

[awmuncy]

I'd agree; the SDK should take the args in the spec. If someone has a big int, and they see it takes either a string or number, they can toString() it themselves, no?

[joewagner]

I'd agree; the SDK should take the args in the spec. If someone has a big int, and they see it takes either a string or number, they can toString() it themselves, no?

Yeah after thinking this over a bit, we should avoid deviating from the spec whenever possible.
I'll rebase this and point it at staging now so we can get it into next week's ship.

The base branch was changed.