You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Description
> [!note]
> A big chunk of discussion for these changes is under initial PR by
@kirillzyusko, please see:
#2413
Associated PR in `react-navigation`:
* react-navigation/react-navigation#12233
Recently in
#2413@kirillzyusko noticed that our iOS animations (in particular
`simple_push` and `slide_from_left`) do not resemble native slide-in
animation as much as we wish and as we claim in our type definitions /
guide for library authors.
The approach suggested by @kirillzyusko in #2413 is as follows:
We add new prop (draft name) `animationInterpolation`; when specified it
allows to set `Interpolation.DEFAULT` which would use default
`UISpringTimingParameters` used by default by UIKit.
This solution has advantage of enabling easy extension in form of
exposing more timing animation curves.
At the same time it comes with disadvantage: setting default system
params (spring animation) disables ability to specify animation
duration, effectively disabling our `transitionDuration` prop (exposed
as `animationDuration` by react-navigation).
I don't want that ☝🏻 I want too keep `animationDuration` working as is,
therefore we need to approximate default spring timing curve as closely
as possible using damping ratio (initializer with damping ratio allows
for control over final transition duration).
According to Matt Neuburg's "Programming iOS 14" the params for default
spring are as follows:
- mass = 3,
- stiffness = 1000,
- damping = 500
We can compute damping ratio as: damping / (2 * sqrt(stiffness * mass))
=> giving us approximately 4,56 (overdamping) <- and this is what we'll
use now.
> [!important]
> Important side-effect of the refactor is the fact that
`animationDuration` now impacts duration of the completion animation
**after the gesture has been cancelled** during interactive dismissal.
I've decided on keeping this behaviour, but it has both pros and cons.
Any feedback on this would be welcome. See video below (animation
duration set to 2000ms).
https://github.com/user-attachments/assets/a13b2e5d-7b90-4597-a33a-956f2f393cd9
## Changes
The default animation time change applies to all animations. Maybe we
should consider applying it only to animations for which we use new
spring'y timing curves.
The animation curve change applies to `simple_push`, `slide_from_left`,
`slide_from_right`. The rest of animations kept EaseInOut curve.
## Test code and steps to reproduce
I've played around on test `Test1072`.
## Before / After
|Animation|Before|After|
|----------|------------|-------|
|`simple_push`|<video width="454" alt="image" src="">|<video width="452"
alt="image"
src="https://github.com/user-attachments/assets/4fb45c2f-d77b-4737-b5ee-8b406b90c15f">|
|`fade`|<video width="454" alt="image" src="">|<video width="454"
alt="image"
src="https://github.com/user-attachments/assets/59114dd5-bc45-4933-ab02-869b35e1725c">|
|`slide_from_bottom`|<video width="454" alt="image" src="">|<video
width="454" alt="image"
src="https://github.com/user-attachments/assets/4580fe9f-112d-4ead-8377-68c1caaf6d46">|
## Improvement possibilities
> [!note]
> 1. fade_from_bottom works ugly - it looks like the screen underneath
disappears immediately - we should look into it
> 2. add possibility of describing custom transition curves (new API
idea), or at least expose some presets
> 3. add prop to control "completion transition duraction"
## Checklist
- [x] Included code example that can be used to test this change
- [ ] Ensured that CI passes
0 commit comments