-
Notifications
You must be signed in to change notification settings - Fork 4
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(staking): [LW-8751] show pool rewards in activity #624
feat(staking): [LW-8751] show pool rewards in activity #624
Conversation
ba836f9
to
6ae38aa
Compare
8d20a7b
to
e2b174b
Compare
adb956e
to
1b4ef33
Compare
d1e9ec4
to
7eee47d
Compare
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.
Will finish last couple of commits tomorrow
{t('package.core.transactionDetailBrowser.pools')} | ||
</div> | ||
<div className={styles.poolsList}> | ||
{poolRewards?.map(({ pool, amount }) => ( |
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.
{poolRewards?.map(({ pool, amount }) => ( | |
{poolRewards.map(({ pool, amount }) => ( |
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.
Great work! I have just minor comments. Please address them before pushing it forward 😉
@@ -2,7 +2,7 @@ | |||
import { ChainablePromiseElement } from 'webdriverio'; | |||
import CommonDrawerElements from './CommonDrawerElements'; | |||
|
|||
class TransactionDetailsPage extends CommonDrawerElements { | |||
class ActivityDetailsPage extends CommonDrawerElements { |
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 the filename should be also renamed
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.
Good catch - though actually this specific class seems to concern only "transaction" details so rather than the file I'd rename the class back to its original name
import type { RewardsInfo } from './RewardsInfo'; | ||
import { ActivityDetailHeaderBrowser } from './ActivityDetailHeaderBrowser'; | ||
|
||
// eslint-disable-next-line @typescript-eslint/no-explicit-any |
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.
Redundant comment. It is disabled at the top already
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.
fixed - I rather dropped the top comment in order to not needlessly relax the rule for the whole file
@@ -0,0 +1,354 @@ | |||
/* eslint-disable no-magic-numbers */ |
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 a pitty that this is recognised as a new file. I noticed that when you rename the file and make changes in it at the same time then git looses track and treats it as a new file. Try next time with making two separate commits, first for the rename and the second for the changes. I am not sure if it is worth fixing the history in this PR...
txSummary?: TxSummary[]; | ||
coinSymbol: string; | ||
tooltipContent?: string; | ||
rewards?: RewardsInfo; |
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.
So this is a change compared to the original file... But I don't see usages of this property. Could you please check the props and remove those unused 🙏
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.
besides "rewards" which are now consumed by the RewardsDetails
component all other props should be relevant
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 might be relevant to rename this component to ActivityDetailHeader
status: ActivityStatus; | ||
amountTransformer: (amount: string) => string; | ||
}; | ||
const TransactionDetailsProxy = withAddressBookContext<TransactionDetailsProxyProps>( |
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.
Please move this component to dedicated file.
status: ActivityStatus; | ||
amountTransformer: (amount: string) => string; | ||
}; | ||
const TransactionDetailsProxy = withAddressBookContext<TransactionDetailsProxyProps>( |
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 passing the TransactionDetailsProxyProps
in the "diamond" is redundant as TS will infer the props type from passed component
} | ||
|
||
const getTypeLabel = (type: ActivityType, t: ReturnType<typeof useTranslate>['t']) => { | ||
if (type === 'rewards') return t('package.core.transactionDetailBrowser.rewards'); |
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.
Please rename all the keys
if (type === 'rewards') return t('package.core.transactionDetailBrowser.rewards'); | |
if (type === 'rewards') return t('package.core.activityDetails.rewards'); |
BTW. I noticed the the key includes package.core
part while this component is placed in the browser. Could you check if that is correct? It might be either moving the translations or/and changing the key to reflect it is a browser code.
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 seems all translations for the browser are prefixed by packages.core
:
"package.core": { |
case Wallet.TransactionStatus.SPENDABLE: | ||
return ActivityStatus.SPENDABLE; | ||
default: | ||
assertUnreachable(status); |
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.
Consider an object instead of a function with a switch block. Having an object IMO it is cleaner and we can ensure the typesafety, and we won't have eslint complaining about the consistent return.
UISlice, | ||
BlockchainProviderSlice, | ||
SliceCreator | ||
} from '../types'; | ||
import { getAssetsInformation } from '@src/utils/get-assets-information'; | ||
import { rewardHistoryTransformer } from '@src/views/browser-view/features/activity/helpers/reward-history-transformer'; | ||
import { EpochNo } from '@cardano-sdk/core/dist/cjs/Cardano'; |
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.
Please reexport it from @lace/cardano
's Wallet
object and access through it.
Or, merge this import with the one in the 9th line
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.
using Wallet.Cardano.EpochNo
seems to work as well, fixed 👍
Signed-off-by: Rafael Korbaš <rafael.korbas@gmail.com>
Signed-off-by: Rafael Korbaš <rafael.korbas@gmail.com>
Signed-off-by: Rafael Korbaš <rafael.korbas@gmail.com>
Checklist
Proposed solution
Join rewardsHistory with wallet activity observable data and show it in wallet activity. The logic around showing the activity was at this point pretty complex and heavily relied on the activity being bound to a transaction which isn't the case for pool rewards which are just deposited to user's reward account at the end of the epoch. To avoid confusion down the round around that nuance, this PR also refactors the
TransactionDetailBrowser
component and the related "sub-components"/state in way that rewards activity is clearly split from "transactions" activity in a type-safe wayThe overall diff is pretty big and I would recommend reviewing this PR primarily by commits - the first commit introduces the rewards in the history in the least "invasive" way and the subsequent commits refactor the components/state in several stages, achieving the desired split of rewards from transactions activity at the end.
Testing
Note on designs: there are no Figma designs to validate the "Rewards" detail screen against. As per the conversation in the JIRA task, the Rewards detail screen has been implemented reusing existing elements as much as possible. Feel free to suggest improvements to the looks/layout of the Rewards detail screen
Screenshots
in case of rewards from multiple pools:
Allure report
allure-report-publisher
generated test report!smokeTests: ❌ test report for 8d20a7b9