WhoBuilt

Owning Transitions

Sep 14, 2018· 36 min· 2.5K views·Watch on YouTube

Speaker

Eric Vicenti, a React Navigation contributor, explains how React Navigation handles screen transitions and how developers can customize them, at a Callstack tech talk.

React Navigation’s origins

Vicenti traces the project from React Native’s early Navigator component through NavigationExperimental, which enabled native-driver animations but required substantial boilerplate. He and Expo’s Brent Vatne created React Navigation to make navigation easier to start with while keeping its logic, URL handling, views, and gestures customizable. He notes that apps including PlayStation, Urban Dictionary, and the NFL use it.

Separating navigation logic from views

React Navigation v2 clarified the division between navigation logic and the view that renders screens. Vicenti shows how `createNavigator` can combine a `StackRouter` with `StackView`, letting developers retain stack behavior while changing the view. For example, the stack can be configured to present screens as modals instead of cards.

Letting screens define transitions

Vicenti introduces a transitioner intended to let each screen manage its own animation and gesture. In his examples, screens define transition setup and execution, then render animated opacity or modal movement based on transition progress. He also shows how a shared `FadeTransition` component can reuse transition behavior across screens.

Gestures and shared elements

Vicenti explains that Gesture Handler tracks gestures on the native thread, while Reanimated lets gesture responses and follow-through animations run there as well. He demonstrates a custom swipe-to-dismiss modal and a shared-element example where product photos and labels animate between screens. The shared-element behavior is built outside the transitioner, which he presents as a test of whether the abstraction supports independently developed transitions.

Open questions and community work

Vicenti describes animating screens behind a modal as a possible future capability, while noting that the API and implementation are still speculative. He is optimistic that the transitioner could support UIKit-style effects, including animated headers and shared text, but says some keyboard behavior may remain beyond JavaScript-based navigation. He invites developers to experiment with the transitioner and contribute documentation, bug reports, and fixes.

Takeaways

  • Separate navigation state logic from screen rendering to make each easier to customize.
  • Let screens own their transitions when different routes need different animations or gestures.
  • Use native-thread gesture handling and animation tools when smooth gesture tracking matters.
  • Shared-element transitions can be implemented outside the navigator if the transition API exposes enough state.
  • Treat speculative APIs as experiments and invite focused feedback from the developer community.

Mentioned in this talk

Search inside this talk

What was claimed 12

Related talks