-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
refactor: replace all bigints to use bn.js library instead #468
Conversation
Total Coverage: 89.82% Coverage Report
|
Total Coverage: 89.81% Coverage Report
|
Total Coverage: 89.81% Coverage Report
|
Total Coverage: 89.81% Coverage Report
|
Total Coverage: 89.81% Coverage Report
|
Total Coverage: 89.84% Coverage Report
|
Total Coverage: 89.84% Coverage Report
|
Total Coverage: 89.84% Coverage Report
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some points;
- I think we should always prioritize type inputs as
BigNumberish
. - We should always return
bn
objects as values - Maybe we should consider export bn as
BigNumber
as is clear and also more familiar to ether users.
const { value } = await contractInstance.functions.echo_u64(INPUT).call(); | ||
expect(value).toBe(INPUT); | ||
expect(value).toBe(toHex(INPUT)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you use toHex
to make this value more comparable than a bn.js
wrapper?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's because both INPUT
and value
are gonna be BN
instances (objects).
The object instances can be different, but same value. To compare the value for testing purpose we convert to Hex first
we can also do value.eq(INPUT)
Total Coverage: 89.86% Coverage Report
|
This PR is looking good, I think we should just hold to release on version 0.15 of the SDK. |
Total Coverage: 89.81% Coverage Report
|
Coverage report
Show new covered files 🐣
Show files with reduced coverage 🔻
Test suite run success486 tests passing in 44 suites. Report generated by 🧪jest coverage report action from 39cf885 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
} | ||
// END ANCHOR: HELPERS | ||
|
||
// ANCHOR: OVERRIDES to accept better inputs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏼
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR introduces a refactor to add
bn.js
and replacebigint
.Main problems of
bigint
:JSON.stringify
, it breaks the codees2020
minimumnumber
bigint
UIntArray
hex strings
Main benefits of using
bn.js
npm:es2020+
projecthex
string. i.e: 0x00022ab23Summary of Code changes:
bn
helpers method as a way to createBN
instanceethers
a lot of times with these):toHex
-> convert to hex string, also allowing padding to match byte syzetoArray
-> convert to Uint8Array, also allowing padding to match byte syzetoNumber
-> convert to number (already validates if number is gonna be too big and lose precision)bn.js
, to accept a wide range of inputs. (calledBNInput
)BigNumberish
as INPUT of contract calls withu64
BN
instance as OUTPUT of contract calls withu64
U64Coder
to encode/decode onlyu64
typeshexZeroPad, zeroPad, uIntPad and other...
and sometimes evenhexlify, arrayify
Closes #280