-
Notifications
You must be signed in to change notification settings - Fork 17
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
Show staked tokens on the staking page #591
Conversation
7f799f8
to
6352274
Compare
0e91381
to
fa0942b
Compare
}) => { | ||
const hasTokens = !!delegationTokens || !!unbondingTokens; | ||
|
||
const handleClickAction = () => alert('Not yet implemented; coming soon!'); |
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.
{/** @todo: Render an icon for each state */} | ||
<TableCell>{getStateLabel(validatorInfo)}</TableCell> | ||
|
||
{/** @todo: Render an icon for each state */} | ||
<TableCell>{getBondingStateLabel(validatorInfo)}</TableCell> |
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.
Per @hdevalence these aren't really needed
|
||
export const ValidatorsTable = ({ |
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.
Two main changes in this file:
- Remove the
<Card>
wrapper, since that's now provided by either<AllValidators />
or<Account />
. - Accept props for the validator infos/etc., rather than grabbing them from the context. This is needed because the parent components may be filtering the validator infos (such as the
<Account />
component, which only renders the validator infos for a given account).
@@ -1,42 +0,0 @@ | |||
import { getDisplayDenomFromView } from '@penumbra-zone/types'; |
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.
Moved to account/index.tsx
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 agree, the design feels a bit clunky. But honestly, no obvious notes from me how to improve it. We don't really have reference designs for the direction we are going.
In general, is the idea that the top boxes will show you who you've delegated to and those buttons allow you to delegate more to them specifically? When you click that button, will that give you a dialog box (or send you to a page) that prefills that validator in? Is a table the best design if the width doesn't allow all of the data to fit?
Overall, I think I'm far more accustomed to staking pages that say, look like Dimension's:
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 located this with the rest of our Getters? Or does this feel logically different?
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.
Yeah I'd thought about that too, but this feels different because it's actually converting the value from one type to another, kind of like the translators
directory. I don't know ... It certainly would be quite ergonomic to be able to chain this to a series of getters. Maybe there could be a class of getters that starts with as
, to indicate that they transform a value rather than just getting it? e.g., asBech32String
?
if (assetPatterns.delegationToken.test(displayDenom)) | ||
return displayDenom.replace(assetPatterns.delegationToken, '$<bech32IdentityKey>'); |
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.
How about we just grab the capture group. That way it's a little more typesafe if it changes:
const delegationMatch = assetPatterns.delegationToken.exec(displayDenom);
if (delegationMatch) {
const { bech32IdentityKey } = delegationMatch.groups as DelegationCaptureGroups;
return bech32IdentityKey;
}
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.
whoops, good call. Fixed.
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.
Instead of react-context, could we compose our state within zustand? I hesitate having multiple kinds of state managers in the app.
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.
Whoops 🤦🏻♂️ Will do
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.
@grod220 ah crap, hang on, gotta fix a few issues I missed
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.
unbondingToken: new RegExp( | ||
/.*unbonding_epoch_(?<epoch>[0-9]+)_penumbravalid1(?<id>[a-zA-HJ-NP-Z0-9]+)$/, | ||
/^uunbonding_epoch_(?<epoch>[0-9]+)_(?<bech32IdentityKey>penumbravalid1(?<id>[a-zA-HJ-NP-Z0-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.
Can you add bech32IdentityKey
to interface UnbondingCaptureGroups
?
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.
yep, done
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.
Yep, done
b8a6a41
to
89a4885
Compare
Yes, that UI is great. We should structure the four groups of rows I described to look like that. Importantly, we should only show one account at a time, rather than multiplexing different accounts in one view. |
<ValidatorInfoRow | ||
key={getValidator(validatorInfo).name} | ||
loading={loading} | ||
validatorInfo={validatorInfo} | ||
votingPowerByValidatorInfo={votingPowerByValidatorInfo} | ||
staking={renderStakingActions(validatorInfo)} | ||
/> |
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 should work towards the design in #569 (comment) , this should be a component for rendering a delegation token, and it should be the same component as is used for the user's delegations.
Does this PR try to work towards #569 (comment) ? It looks like we have separate logic for the different sections. If we have a single component rendering delegation tokens, I think this will be much simpler. We can orient that component's visual design around the screenshot that @grod220 posted. |
@hdevalence, sort of :) I started with the plan of creating a component that accepted both a value view and validator info, per your comment. However, I realized that it would mean that validators would be displayed in duplicate if a user has both unbonding tokens and delegation tokens for a given validator. So instead, I grouped the delegation and unbonding tokens for a given validator together with the relevant validator info, so that each validator is only rendered once per account that has delegation OR unbonding tokens for it. That said, is your concern more with the visual presentation of the tokens + validators? For the moment, I was just using the existing validator info rows from my previous PR, and then adding the token info in the rightmost column. I could try to redesign it a bit to highlight the token data more than the validator info, but that might be tricky since the only information to display about delegation/unbonding tokens is their balances. |
(Also, note that I haven't yet filtered the "Active validators" table at the bottom to only include validators that the user has no delegation/unbonding tokens in, FYI. That'll come later.) |
Sorry, one more note @hdevalence — I would like to redesign the ValueViewComponent for delegation/unbonding tokens specifically, so it's a bit more readable and portable. This design isn't very usable: |
da28e32
to
931d0fc
Compare
@@ -0,0 +1,96 @@ | |||
import { beforeEach, describe, expect, it, vi } from 'vitest'; |
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.
This file is pretty much moved from use-validator-infos.test.ts
, but with some changes to account for using Zustand instead of context
931d0fc
to
50bf143
Compare
50bf143
to
8e93235
Compare
🚨 300+ line changes are test files
In this PR
assetPatterns
, and fix their regex for security implications.Punting for now
Closes #587
Closes #588