-
Notifications
You must be signed in to change notification settings - Fork 212
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
Voting: use BN.js everywhere #1113
Conversation
Co-authored-by: Pierre Bertet <[email protected]>
* Payroll: Fix accrued salary calculation * Payroll: Improve casting when calculating last payroll date
* Copy improvements * More specific copy * Reverting controversial change
* Change confusing token manager copy
* voting: fetch active account votes in script * Move connectedAccount out of the store and cache * Add comment about using strings over symbols * Move functions to helpers * Update comments Co-Authored-By: 2color <[email protected]> * Add newline
Improve the filters layout: - Move TransfersFilters to its own component. - Make the layout work at all sizes. - Update the download button so it looks like the other icon buttons. - Update some labels: - “Date range” => “Period” - “Transfer type” => “Type” (since it is already below the “Transfers” title). - Select the last 90 days (rolling) by default.
* Voting: fix bug with votes not loading initially * Add comment
Fixes aragon/client#734. With aragon/aragon.js#277 we now get the actual errors back from the RPC when a call goes wrong (e.g. naive `token.symbol()` on DAI) and we need to handle these explicitly. This PR converts a lot of the token fallback-related bits into simpler Promise-based code and adds explicit handlers for their error cases.
- Add a new TokenAmount class. - Add a new Percentage class. - Add bnPercentageToNumber(). - Add formatBnPercentage(). - Format amounts / percentages from the TokenAmount / Percentage classes. - Convert the calculations to BN.js. - Remove `numData` from the vote data structure. - Use formatTokenAmount().
9a6d907
to
7c2fdc1
Compare
I added some changes to remove the Changes:
|
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.
Very very minor nitpicks! This is looking awesome!
@@ -1,17 +1,16 @@ | |||
import React from 'react' | |||
import styled from 'styled-components' | |||
import { GU, textStyle, useTheme } from '@aragon/ui' | |||
import { GU, textStyle, formatTokenAmount, useTheme } from '@aragon/ui' |
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.
We can move this behind textStyle so it's alphabetized
🙏
@@ -1,5 +1,6 @@ | |||
import BN from 'bn.js' | |||
import { hasLoadedVoteSettings } from './vote-settings' | |||
import { Percentage, TokenAmount } from './math-utils' |
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.
Hmm, we don't have to do it now, but I think we could use our newly released TokenAmount lib!
import { formatTokenAmount } from '@aragon/ui' | ||
import { useAragonApi } from '@aragon/api-react' |
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.
Now that I'm seeing the order, shouldn't we move @aragon/ui
below @aragon/api-react
?
apps/voting/app/src/vote-utils.js
Outdated
|
||
const totalVotes = yea.add(nay) | ||
const totalVotes = yea.value().add(nay.value()) |
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.
Just realized this probably could equal -2
if both yea
and nay
get passed in as -1
, but, AFAIK, this can't really happen as they're not being set at -1
at any moment.
apps/voting/app/src/token-utils.js
Outdated
) { | ||
if (!tokenContract || !connectedAccount) { | ||
return -1 | ||
export async function getUserBalanceAt(account, snapshotBlock, tokenContract) { |
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.
I wonder if we should also make these return BN objects (or null), so all the number-related APIs use BN.js?
apps/voting/app/src/math-utils.js
Outdated
} | ||
|
||
// Converts a percentage expressed as a value + base into a number between 0 and 1. | ||
export function bnPercentageToNumber(value, base, precision = 10 ** 9) { |
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.
Just a bit worried with the precision being too big—wonder if we should use something like maxDecimalPrecision
instead (just the number of decimals)?
@@ -16,6 +17,7 @@ function appStateReducer(state) { | |||
connectedAccountVotes, | |||
} = state | |||
|
|||
const pctBaseBn = new BN(pctBase) | |||
const pctBaseNum = parseInt(pctBase, 10) |
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.
We can probably remove this now?
supportRequired: new Percentage(data.supportRequired, pctBaseBn), | ||
votingPower: new TokenAmount(data.votingPower, tokenDecimals), | ||
yea: new TokenAmount(data.yea, tokenDecimals), | ||
nay: new TokenAmount(data.nay, tokenDecimals), |
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.
What do you think about also including the token symbol in the TokenAmount
?
import You from './You' | ||
import { formatNumber } from '../math-utils' | ||
import { VOTE_NAY, VOTE_YEA } from '../vote-types' | ||
|
||
function SummaryRows({ yea, nay, symbol, connectedAccountVote }) { |
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.
Wanted to double check—what type is yea
and nay
? We're accessing yea.pct
but I'm not sure this exists on the object anymore.
|
||
return ( | ||
parseInt( | ||
divideRoundBigInt( |
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 starting to look like we may want another utility :).
Maybe divideBN()
and we can give it a decimalsPrecision
option?
apps/voting/app/src/math-utils.js
Outdated
|
||
// Tolerate having too many digits by correcting the value. | ||
if (basePrecision > Number.MAX_SAFE_INTEGER) { | ||
digits = Math.floor(Math.log(Number.MAX_SAFE_INTEGER) / Math.log(10)) |
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.
Not sure about this:
- I think we should make this max precision value be a constant
- This value is actually only
15
, and and I think we should at least support 18 decimals (since that's what tokens use, as well as our contract'spctBase
exponent).
It's unlikely someone will want something this large, but I'm also wondering if we shouldn't just cap the precision at the pctBase
's exponent (since it'll just be 0s after that anyway).
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.
I think we should make this max precision value be a constant
Why? This is already on the Javascript Number
object, and so having this as a constant seems a bit redundant to me.
This value is actually only 15, and and I think we should at least support 18 decimals (since that's what tokens use, as well as our contract's pctBase exponent).
This is true, and relates to #1177 in terms of having an utility to safely scale up normal numbers to Bigints.
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.
Why? This is already on the Javascript Number object, and so having this as a constant seems a bit redundant to me.
Because Math.floor(Math.log(Number.MAX_SAFE_INTEGER) / Math.log(10))
is pure and doesn't need to be calculated every time
hey, I continued the last changes you requested here https://github.com/eliobricenov/aragon-apps/commits/voting-token-amount-fix-v2 Should I create a new PR with these changes? C.C @nivida |
6e14239
to
f7ef93b
Compare
This pr closes aragon/client#1347