feat(staking): add more real data #1880
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
| poolData: PoolDataAccount, | ||
| ): PublisherData => { | ||
| return poolData.publishers | ||
| .filter((publisher) => !publisher.equals(PublicKey.default)) |
There was a problem hiding this comment.
This feels wrong if there were gaps in the publishers (which can't happen in the program though)
There was a problem hiding this comment.
yes there are a lot of assumptions based on that.
There was a problem hiding this comment.
Most important changes are:
- Calculate upcoming epoch APY rather than last epoch APY
- Move some stuff to
Promise.all - Validate publisher ranking response using schema instead of typecasting
- Remove the
publishers-rankingendpoint and instead use nextjs rewrites; also rewrite to web-api directly instead of rewriting to www.pyth.network
Everything else is optional / minor
| }, | ||
| }); | ||
| // TODO: use env var to support mainnet | ||
| const hermesClient = new HermesClient("https://hermes-beta.pyth.network"); |
There was a problem hiding this comment.
IMO this should be in a separate react context, it doesn't really make sense to be in this context as it's not associated to the wallet state (I should rename this hook as it's no longer just about staking accounts, it's now really a hook for the wallet state, where the list of stake accounts & the selected stake account is part of the wallet state -- and the Pyth Staking Client is here because it is only valid in certain wallet states).
| stakeAccount: | ||
| poolData.publisherStakeAccounts[index] === undefined || | ||
| poolData.publisherStakeAccounts[index].equals(PublicKey.default) | ||
| ? null |
There was a problem hiding this comment.
Minor preference but I suggest just using undefined instead of mixing undefined and null; the fact that javascript has both is a wart and it's very very easy to misuse them in subtle ways. For all intents and purposes they are typically used interchangeably, so best to just standardize on one and always use it. Due to the semantics of missing values, you generally can't avoid undefined, but null is generally only introduced in user code, so I generally suggest just standardizing on using undefined everywhere.
If you need a true ternary state, I will always recommend using the fake sum types pattern I shared with you earlier, it's far more explicit, easier to understand the intent, and less error-prone.
3 participants
No description provided.