-
Notifications
You must be signed in to change notification settings - Fork 302
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
Feat/api voting list #3824
Feat/api voting list #3824
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
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. It does take a few seconds to load becuase of a subgraph query to fetch all pools on the veBAL page. Is that query needed? Does the veBAL table need to wait for it before showing?
const gaugeVoteWeightNormalized = scale(props.gauge.votesNextPeriod, -18); | ||
const gaugeVoteWeightNormalized = scale(props.pool.votesNextPeriod, -18); | ||
if (isVeBalGauge.value) { | ||
return gaugeVoteWeightNormalized.gte(bnum('0.1')); |
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 is this hard coded here instead of dynamically pulled like the rest? Can it be put into a const variable rather than a magic number.
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 decided to keep it as I found it cause the author probably wanted to explicitly enforce this concrete rule.
I will extract the magic number to a const just in case we are missing something.
That As we discussed in slack the main blocker here would be the decorator that wraps pools/gauges with voting data from onchain multicalls:
|
Co-authored-by: Gareth Fuller <[email protected]>
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.
Let's get Zekraken to do a round of testing just on voting to make sure that's all working correctly, but he can do that on beta.
The code is ready in canary but Franz is testing some new infra in production so we need to wait for him to finish. I will merge then. |
Description
Migrates vebal voting list to use new API endpoint
VeBalGetVotingList
(that is already deployed in production)Type of change
How should this be tested?
Please provide instructions so we can test. Please also list any relevant details for your test configuration.
Visual context
Please provide any relevant visual context for UI changes or additions. This could be static screenshots or a loom screencast.
Checklist:
master
if hotfix,develop
if not