synthetix-mintr
synthetix-mintr copied to clipboard
Synthetixio
Avoid big/small numbers being displayed in SCI format
@bachstatter It's JS not liking very big/small numbers. Solution would be to keep the original BigNumber value sent by the smart contract and create a "readable" value using the max decimals JS can handle.
Then when validating the transaction, if the input value === readable balance we process the transaction with the BigNumber value directly.
We don't want to use the rounded readable value directly as it would leave some dust in the wallet.
I think I've implemented this somewhere, in burn, mint or send.
@bachstatter that's just an idea I got but feel free to try something else if you think it might be better!
Is the big number sent back from the smart contract in a string format?
We could use a package to help with this sorta stuff: https://www.npmjs.com/package/bignumber.js
As discussed in person the other day, we know this library, but always managed to use ethers.js or custom made helpers.
@justinjmoses it would be nice to have your opinion on that.
I'm definitely not against it but we would probably end up refactoring a lot of code.
ethers should have support for it - we just need to not make it a JS Number but rather a string - so using ethers.utils.formatEther() on the BN returned from the contract. Unless I'm missing something?
@bachstatter let's try that?
Right now we're using export const bigNumberFormatter = value => Number(snxJSConnector.utils.formatEther(value));
Maybe let's create another function which doesn't convert to number and try in one screen for now (like Trade).
If I click Max on the trade screen I get this value:
const value = 1.50812902664e-7
If I try to give that to
snxJSConnector.utils.formatEther(value)
It throws this error:
underflow (operation="setValue", fault="underflow", value=1.50812902664e-7, outputValue=1, version=4.0.27)
Hmm. I think I'm just gonna assign myself to do this one. It's not trivial and some of the logic needs to be updated everywhere in the dApp.