Skip to content
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

fix(wallet-mobile): tx history animation initial state #3124

Merged
merged 2 commits into from
Mar 13, 2024

Conversation

jorbuedo
Copy link
Contributor

related: #3123

@jorbuedo jorbuedo added the fix label Mar 12, 2024
@jorbuedo jorbuedo added this to the 4.26.0 milestone Mar 12, 2024
@jorbuedo jorbuedo self-assigned this Mar 12, 2024
@@ -18,6 +18,10 @@ const useAnimatedTxHistory = () => {
}))

React.useLayoutEffect(() => {
if (translateYOffset.value !== 0) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what will this do?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

translateYOffset.value is the shared value the blur and focus listeners are using. It's the position on the screen of the animated component. It starts being 2000 (so down below the visible screen) so that the animation can bring the component up into view.
This condition in particular checks that the component is not into view, to bring it into view.

The complexity of the component comes from having to listen to changes in navigation to animate in and out, plus the initial setup of the hook in which the listeners don't trigger (they're being setup), plus the different routes of the app: some using the same navigation without unmounting this hook, others unmounting this hook to use a different root component. Some transitions, like opening and closing the QR camera, interrupted the shared value animation, leaving it in an intermediate state different than 2000 or 0, so the component fell out of view when it was supposed to be in.

Between the previous changes to simplify the animation, and this condition to make sure it goes into view if it's not, everything should work as expected now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ty @jorbuedo now it makes sense to me, it also brings a question, just realized that all function calls on the txhistory should be wrapped within the InteractionManager, so it awaits until all animations have finished before triggering anything else.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mm depends on the functions I guess, we don't have to wait for the animation to finish before we start updating the wallet. Takes long enough already, no need to add the 1 sec of the animation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yap, the UI ones, like the navigations on the actions banner, it can be triggered while the animation on the history is still running

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i.e you pull it down, press Receive, it cuts the animation and move the user to the Receive funnel

Signed-off-by: Juliano Lazzarotto <[email protected]>
@stackchain stackchain changed the title fix: tx history animation initial state fix(wallet-mobile): tx history animation initial state Mar 13, 2024
@stackchain stackchain merged commit 73568c4 into develop Mar 13, 2024
2 checks passed
@stackchain stackchain deleted the yomo-1222-fix branch March 13, 2024 09:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants