feat(cash): move Give to the left-aligned amount header - #1357
Merged
Conversation
Give still drew the centred v1 amount field with its currency flag while Buy and Convert had moved to the left-aligned display-extra-large header. Node 9641:16762 puts Give on the same header, so turn on AmountEntryScreen's largeHeader and state the ceiling as "$X available" the way Convert and the v2 Get do. The v2 header carries no flag, so tapping the amount no longer opens region selection — canChangeCurrency now says as much, and changing currency is still reachable from the wallet balance. The over-max line stays give-specific: the cap is the lower of the balance and the per-transaction send limit, and "available" alone wouldn't explain a limit-bound cap.
Confirming an amount dispatched the success state and the bill on the same frame, so the button went from spinner straight to the bill overlay and the checkmark was never drawn. dispatchSuccessThen holds it for SuccessHoldDuration first — the same beat the username, name and photo screens already wait.
The bill's bottom inset is the management row's measured height, which only arrives a frame after the bill composes. Animating that first 0 -> measured change put the card half its own inset too low, so it appeared with the "Send as a Link" and "Cancel" pills over its bottom edge, held there for the 450ms animation delay, then slid up over another 450ms. Only the tip card needs the inset animated: it moves in lockstep with the tip modal sliding up. Everywhere else the inset now snaps, which lands while the enter spring is still carrying the card up from off-screen. Recorded Give at 15fps on an emulator: before, the card moves between frames 39 and 45; after, it is at its final position from the first frame it is visible and stays there. The tip card's full-screen present is unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Give still drew the centred v1 amount field with its currency flag, while Buy and Convert had already moved to the left-aligned display-extra-large header. Node 9641:16762 puts Give on the same header, so this turns on
AmountEntryScreen'slargeHeaderand states the ceiling as "$X available", the way Convert and the v2 Get do.The v2 header carries no flag, so tapping the amount no longer opens region selection —
canChangeCurrencynow says as much, and changing currency is still reachable from the wallet balance. The over-max line stays give-specific: the cap is the lower of the balance and the per-transaction send limit, and "available" alone wouldn't explain a limit-bound cap. The orphanedsubtitle_giveCashHintstring goes with it.Two things surfaced while working through the flow end to end:
The success checkmark was never drawn. Confirming an amount dispatched the success state and the bill on the same frame, so the button went from spinner straight to the bill overlay. It now goes through
dispatchSuccessThen, holding forSuccessHoldDurationfirst — the same beat the username, name and photo screens already wait.The bill appeared over the "Send as a Link" and "Cancel" pills. The bill's bottom inset is the management row's measured height, which only arrives a frame after the bill composes. Animating that first
0 -> measuredchange put the card half its own inset too low, held it there for the 450ms animation delay, then slid it up over another 450ms. Only the tip card needs the inset animated — it moves in lockstep with the tip modal sliding up — so everywhere else it now snaps, landing while the enter spring is still carrying the card up from off-screen. Recorded at 15fps on an emulator: before, the card moves between frames 39 and 45; after, it is at its final position from the first frame it is visible. The tip card's full-screen present is unchanged.