-
Notifications
You must be signed in to change notification settings - Fork 96
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(TokenEnterAmount): add new flow to EnterAmount.tsx #6245
Conversation
6f89ffd
to
1aa17d6
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6245 +/- ##
==========================================
- Coverage 88.95% 88.93% -0.02%
==========================================
Files 739 739
Lines 31644 31609 -35
Branches 5892 5883 -9
==========================================
- Hits 28149 28113 -36
+ Misses 3450 3296 -154
- Partials 45 200 +155
... and 68 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
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.
amazing work!!! it looks really great 🚀 i had some small ponderings, and i think you may also need to adjust the e2e tests for the send flow?
@@ -355,58 +225,62 @@ function EnterAmount({ | |||
> | |||
<View style={styles.inputContainer}> | |||
<Text style={styles.title}>{t('sendEnterAmountScreen.title')}</Text> |
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.
(i think this is outdated)
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.
@kathaypacific should be outdated as it was missing after initial merge with "max" functionality but then I fixed it.
src/components/TokenEnterAmount.tsx
Outdated
return value.replaceAll(groupingSeparator, '').replaceAll(decimalSeparator, '.') | ||
} | ||
|
||
export function roundLocalNumber(value: BigNumber | null) { |
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.
export function roundLocalNumber(value: BigNumber | null) { | |
export function roundFiatValue(value: BigNumber | null) { |
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.
side thought, no need to address now but i wonder if this will be handy to have as a general function that can be used in other places like the transaction feed....
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.
@kathaypacific I think it definitely will be. Considering that it is currently only used in this file - there's no point in moving it to a general utility yet file but we should keep this in mind for when its gonna be useful.
@@ -48,6 +49,16 @@ export function formatNumber(value: string) { | |||
.replaceAll('_', groupingSeparator) | |||
} | |||
|
|||
export function unformatNumberForProcessing(value: string) { |
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.
export function unformatNumberForProcessing(value: string) { | |
export function formatNumberToStandard(value: string) { |
or parseNumberToStandardFormat
or applyUSNumberFormatting
?
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.
@kathaypacific hmm, I'm still unsure on this one. It is only used in a single place so far to actually un-format already formatted number that comes from the input and format it for the processing purposes. I think it makes a more clear distinction for the specific purpose of the function:
- it unformats the number (which implies it was formatted in the first place)
- it formats it specifically for processing
I've only made is a separate function to simplify description as otherwise I'd need to write a comment explaining what it does and why, which feels more concise in a form of a clear function name.
In case of formatNumberToStandard/parseNumberToStandardFormat
- we need to define what we mean by "standard". And in case of applyUSNumberFormatting
- we need to understand why we specifically use US
number formatting (even though I'm not sure it's US specific as up to this point I thought this was a general format that everyone uses and was always using it myself 😄)
At least, that's my train of though. What do you think about it?
src/components/TokenEnterAmount.tsx
Outdated
handleToggleAmountType, | ||
handleAmountInputChange, | ||
handlePercentage, |
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.
handlePercentage, | |
handleSelectPercentageAmount, |
src/send/EnterAmount.tsx
Outdated
tokenBottomSheetRef.current?.close() | ||
const onSelectToken: TokenBottomSheetProps['onTokenSelected'] = (selectedToken) => { | ||
setToken(selectedToken) | ||
setAmount('') |
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.
ah, i was wondering how this setAmount
would be used. generally i don't like the pattern of components that have a state and give other components access to the state and the state setter because it gives consumers of this component the ability to do a lot (and blurs the responsibility of the consumer and the component, since the component can be controlled absolutely).
if the consumers only need to be able to reset the amount
, what do you think about changing the return property of useEnterAmount
here from setAmount
to something like resetAmount
?
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.
@kathaypacific I totally agree and I tried to refrain from exposing this state setter till the very end but in this particular case it felt like it was the clearest way to do this without trying to overcomplicate it.
I will rename it to replaceAmount
as I already have an identical functionality incoming in Swap flow (cause we have two fields there and second is always un-editable and have to be set programatically).
// NOTE: analytics is already fired by the bottom sheet, don't need one here | ||
} | ||
|
||
const onSelectPercentageAmount = (percentage: number) => { | ||
setTokenAmountInput(token.balance.multipliedBy(percentage).toFormat({ decimalSeparator })) | ||
setEnteredIn('token') | ||
handlePercentage(percentage) | ||
setSelectedPercentage(percentage) |
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.
the handlePercentage
and setSelectedPercentage
calls in series made me think that it might make sense to move the EnterAmountOptions
into TokenEnterAmount
, what do you think? (not in this PR, but seems like a fun friday afternoon thing for someone at some point)
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.
@kathaypacific agree!
src/send/EnterAmount.tsx
Outdated
const isAmountLessThanBalance = | ||
processedAmounts.token.bignum && processedAmounts.token.bignum.lte(token.balance) | ||
const showLowerAmountError = | ||
processedAmounts.token.bignum && !isAmountLessThanBalance && !disableBalanceCheck |
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.
could this be simplified to const showLowerAmountError = processedAmounts.token.bignum && processedAmounts.token.bignum.gt(token.balance) && !disableBalanceCheck
?
src/send/EnterAmount.tsx
Outdated
}, FETCH_UPDATED_TRANSACTIONS_DEBOUNCE_TIME_MS) | ||
return () => clearTimeout(debouncedRefreshTransactions) | ||
}, | ||
[processedAmounts.token.bignum, token] |
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.
should we try to use primitive values here? i'm not sure how effective BigNumber and TokenBalance is at triggering this effect
[processedAmounts.token.bignum, token] | |
[processedAmounts.token.bignum.toString(), token.tokenId] |
src/send/EnterAmount.tsx
Outdated
onOpenTokenPicker={tokenSelectionDisabled ? undefined : onOpenTokenPicker} | ||
/> | ||
|
||
{!!maxFeeAmount && ( |
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 is also something that we can consider as a follow up, wanted to note it while it's fresh in my mind. i think one of the goals of the enter amount work is also to standardise errors and the fees display. so perhaps it makes sense to move these parts into the TokenEnterAmount (or have a component that wraps them, idk). i think that there's going to be some amount of duplication for handling these things in the various flows
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.
@kathaypacific I'm all for it! I will create a task for this and would love to work on it!
src/send/EnterAmount.test.tsx
Outdated
@@ -158,12 +160,12 @@ describe('EnterAmount', () => { | |||
}) | |||
|
|||
expect(getByTestId('SendEnterAmount/TokenAmountInput')).toBeTruthy() | |||
expect(getByTestId('SendEnterAmount/LocalAmountInput')).toBeTruthy() | |||
// expect(getByTestId('SendEnterAmount/Max')).toBeTruthy() |
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.
remove?
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.
🥳
ios/Podfile.lock
Outdated
@@ -1339,4 +1339,4 @@ SPEC CHECKSUMS: | |||
|
|||
PODFILE CHECKSUM: e49ec411923f9bb1906dff8d0e27d0aa410bf3ad | |||
|
|||
COCOAPODS: 1.16.2 | |||
COCOAPODS: 1.15.2 |
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.
ah, perhaps we don't include this change since it's unrelated
📸 Snapshot TestBase build not foundNo build was found for the base commit 1ea0927. This is required to generate a snapshot diff for your pull request. It's possible that you created a branch off the base commit before all of the CI steps have finished processing, e.g. the one that uploads a build to our system. If that's the case, no problem! Just wait and this will eventually resolve. 🛸 Powered by Emerge Tools |
hey @sviderock this is awesome!! i will merge in your absence :) i added a few minor changes after testing on android, noting it here in case you disagree with the changes / have ideas for how to fix the issues in a better way:
here are some "before changes" screenshots: Screen_Recording_20241202_113305_Valora.dev.mp4after changes video: Screen_Recording_20241202_131828_Valora.dev.mp4 |
Description
3/5 PR for new Enter Amount component. This PR uses the new component and hook in the Send flow. A lot of tests are adjusted to follow the new flow.
AmountInput
component was moved purely for compatibility withEarnEnterAmount
component. This is an outdated boilerplate code which will be removed in the next PR (4/5). Most of the line changes is this specific component and a lot of tests' adjusting. There's really not many changes other than replacing boilerplate code with the same code from a reusable hook.Test plan
Changes a bunch of test files to relate to the new changes. All the tests related to
MAX
button are skipped for now.send.flow.mp4
Related issues
Backwards compatibility
Yes
Network scalability
If a new NetworkId and/or Network are added in the future, the changes in this PR will: