Hi everyone! A quick question on numbering conventions in dApps. What are you all using to represent numbers (currency/ token values) in the thousands (ei. 120,000), millions (ie. 999,000,000) and decimal values longer than 4 digits (ie. .000001) ?
Hi everyone! A quick question on numbering conventions in dApps. What are you all using to represent numbers (currency/ token va
This is actually a really interesting question
I came across this when developing Balance Manager and it’s quite annoying the flexbility with decimal numbers for token balances
the approach we took was to have 3 signficant numbers
If you take a look at this screenshot you will see that for example The Ocean Token has a price of $0.0117
meaning it rounds up to display at least 3 signficant digits
and also the Ethereum balance is rounded as 0.446 ETH
Hey Pedro! Dealing with this now too. The 3 decimals seem to work for most tomens. What about tokens where you usually deal with more decimals to represent value? Up till now we basically showed them in full, if over 3 decimals in overviews.
The tricky word here is “signficant digits”
so it’s not a 3 decimal rule but to always round the amount to display at least 3 signficant digits
0.0000354 would be valid for example
I see, gotcha.
but also would 0.01
Did you encounter weird formatting challenges with potentiall irregular token amount of digits? But I guess that is the best approach.
the maximum amount would be 18 decimals
but I created a cut off value
Im going to share it in a second
eg if you have a list of:
last one would be 19456.35
BigNumber Helper Functions
BigNumber Helper Functions. GitHub Gist: instantly share code, notes, and snippets.
in english the rule would be “display at least 3 significant digits” which is different than “at least 3 decimals”
Significant meaning, start the count after any 0 value decimal.
The only possible downside I could see, is where an user would be trained/used to handle balances in its full amount. More from a recognition point of view. But I guess a tradeoff.
The only possible downside I could see, is where an user would be trained/used to handle balances in its full amount. More from
Do you mean full amount as in no rounding numbers?
just actual full amount so 18 digits
like you see on exchanges printing the full balances in your exchange wallet. Even if that means showing 'dust' in terms of token value.
like you see on exchanges printing the full balances in your exchange wallet. Even if that means showing 'dust' in terms of toke
True, I think this a design decision from the wallet side
Some may show full amounts, some may not or even make it optional
Also better tx fee calculation tools will reduce dust