Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat(iOS)!: change default animation curve & duration (#2477)
## 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
- Loading branch information