This project aims to expose native navigation container components to React Native. It is not designed to be used as a standalone library but rather as a dependency of a full-featured navigation library.
How can I take advantage of that?
Supported react-native version
Since version 2.0.0 react-native-screens requires RN v0.60+. Check 1.0.0-alpha for Expo support or older versions of React Native.
react-navigation (without Expo)Usage with
To configure react-navigation to use screens instead of plain RN Views for rendering screen views, follow the steps below:
- Add this library as a dependency to your project:
yarn add react-native-screens
- Link native modules this library ships with into your app:
react-native link react-native-screens
If you are not familiar with the concept of linking libraries read on here.
- Enable screens support before any of your navigation screens renders. Add the following code to your main application file (e.g. App.js):
Note that the above code needs to execute before the first render of a navigation screen. You can check the Example's app App.js file as a reference.
Make sure that the version of react-navigation you are using is 2.14.0 or higher
You are all set 🎉 – when screens are enabled in your application code react-navigation will automatically use them instead of relying on plain React Native Views.
react-navigation v1.0.0Usage in Expo with
- Add screens library as a dependency to your project – you can skip this step when using snack as the dependency will be imported when you import it in one of the JS files
yarn add react-native-screens
- Open your App.js file and add the following snippet somewhere near the top of the file (e.g. right after import statements):
- That's all 🎉 – enjoy faster navigation in your Expo app. Keep in mind screens are in the pretty early phase so please report if you discover some issues.
React-native-navigation library already uses native containers for rendering navigation scenes so wrapping these scenes with
<Screen> component does not provide any benefits. Yet if you would like to build a component that uses screens primitives under the hood (for example a view pager component) it is safe to use
<Screen> components for that as these work out of the box when rendered on react-native-navigation scenes.
Using native stack navigator
To take advantage of the native stack navigator primitive introduced in version 2.0 you need to use navigator creator function exported by react-native-screens package:
Then replace places when you use
createNativeStackNavigator. Note that not all the screen customization options are supported. There are some technical limitations to implementing some of the stack header options. Documenting the supported parameters is on an immediate roadmap and will be available soon.
Interop with other libraries
This library should work out of the box with all existing react-native libraries. If you experience problems with interoperability please report an issue.
Guide for navigation library authors
If you are building a navigation library you may want to use react-native-screens to have control over which parts of the React component tree are attached to the native view hierarchy. To do that react-native-screens provides you with two components documented below:
This component is a container for one or more
It does not accept other component types as direct children.
The role of the container is to control which of its children's screens should be attached to the view hierarchy.
It does that by monitoring the
active property of each of its children.
It is possible to have as many
active children as you'd like but for the component to be the most efficient, we should keep the number of active screens to a minimum.
In the case of a stack navigator or tabs navigator, we only want to have one active screen (the topmost view on a stack or the selected tab).
While transitioning between views we may want to activate a second screen for the duration of the transition, and then go back to just one active screen.
This component is a container for views we want to display on a navigation screen.
It is designed to only be rendered as a direct child of
In addition to plain React Native View props this component only accepts a single additional property called
active is set to
0, the parent container will detach its views from the native view hierarchy.
Otherwise, the views will be attached as long as the parent container is attached too.
Screen stack component expects one or more
Screen components as direct children and renders them in a platform-native stack container (for iOS it is
UINavigationController and for Android inside
Fragment container). For
Screen components placed as children of
active property is ignored and instead the screen that corresponds to the last child is rendered as active. All types of updates done to the list of children are acceptable when the top element is exchanged the container will use platform default (unless customized) animation to transition between screens.
StackScreen extends the capabilities of the
Screen component to allow additional customizations and to make it possible to handle events such as using hardware back or back gesture to dismiss the top screen. Below is the list of additional properties that can be used for
A callback that gets called when the current screen is dismissed by hardware back (on Android) or dismiss gesture (swipe back or down). The callback takes no arguments.
Allows for the customization of how the given screen should appear/disappear when pushed or popped at the top of the stack. The following values are currently supported:
"default"– uses a platform default animation
"fade"– fades screen in or out
"flip"– flips the screen, requires
stackPresentation: "modal"(iOS only)
"none"– the screen appears/disappears without an animation
Defines how the method that should be used to present the given screen. It is a separate property from
stackAnimation as the presentation mode can carry additional semantic. The allowed values are:
"push"– the new screen will be pushed onto a stack which on iOS means that the default animation will be slide from the side, the animation on Android may vary depending on the OS version and theme.
"modal"– the new screen will be presented modally. Besides, this allows for a nested stack to be rendered inside such screens
"transparentModal"– the new screen will be presented modally but also, the second to last screen will remain attached to the stack container such that if the top screen is non-opaque, the content below can still be seen. If
"modal"is used instead the below screen will get unmounted as soon as the transition ends.
The config component is expected to be rendered as a direct child of
<Screen>. It provides an ability to configure native navigation header that gets rendered as a part of the native screen stack. The component acts as a "virtual" element that is not directly rendered under
Screen. You can use its properties to customize platform native header for the parent screen and also render react-native components that you'd like to be displayed inside the header (e.g. in the title are or on the side).
Along with this component's properties that can be used to customize header behavior, one can also use one of the below component containers to render custom react-native content in different areas of the native header:
ScreenStackHeaderCenterView– the children will render in the center of the native navigation bar.
ScreenStackHeaderRightView– the children will render on the right-hand side of the navigation bar (or on the left-hand side in case LTR locales are set on the user's device).
ScreenStackHeaderLeftView– the children will render on the left-hand side of the navigation bar (or on the right-hand side in case LTR locales are set on the user's device).
Below is a list of properties that can be set with
When set to
true the header will be hidden while the parent
Screen is on the top of the stack. The default value is
Controls the color of items rendered on the header. This includes a back icon, back text (iOS only) and title text. If you want the title to have a different color use
A string representing screen title that will get rendered in the middle section of the header. On iOS, the title is centered on the header while on Android it is aligned to the left and placed next to the back button (if one is present).
Customize the font family to be used for the title.
Customize the size of the font to be used for the title.
Allows for setting text color of the title.
Controls the color of the navigation header.
Boolean that allows for disabling drop shadow under navigation header. The default value is
If set to
true the back button will not be rendered as a part of the navigation header.
If set to
true the back button will also be rendered while using
When set to
false the back swipe gesture will be disabled when the parent
Screen is on top of the stack. The default value is
translucent (iOS only)
When set to
true, it makes native navigation bar on iOS semi-transparent with blur effect. It is a common way of presenting a navigation bar introduced in iOS 11. The default value is
backTitle (iOS only)
Allows for controlling the string to be rendered next to the back button. By default, iOS uses the title of the previous screen.
backTitleFontFamily (iOS only)
Allows for customizing font family to be used for the back button title on iOS.
backTitleFontSize (iOS only)
Allows for customizing font size to be used for the back button title on iOS.
largeTitle (iOS only)
When set to
true it makes the title display using the large title effect.
largeTitleFontFamily (iOS only)
Customize the font family to be used for the large title.
largeTitleFontSize (iOS only)
Customize the size of the font to be used for the large title.
Guide for native component authors
If you are adding a new native component to be used from the React Native app, you may want it to respond to navigation lifecycle events.
A good example is a map component that shows the current user location. When the component is on the top-most screen, it should register for location updates and display the user's location on the map. But if we navigate away from a screen that has a map, e.g. by pushing a new screen on top of it or if it is in one of the tabs, and the user just switched to the previous app, we may want to stop listening to location updates.
To achieve that, we need to know at the native component level when our native view goes out of sight. With react-native-screens you can do that in the following way:
Navigation lifecycle on iOS
In order for your native view on iOS to be notified when its parent navigation container goes into background override
You can check our example app for a fully functional demo see RNSSampleLifecycleAwareView.m for more details.
Navigation lifecycle on Android
On Android, you can use LifecycleObserver interface which is a part of Android compat library to make your view handle lifecycle events. Check LifecycleAwareView.java from our example app for more details on that.
In addition to that, you will need to register for receiving these updates. This can be done using
Remember to call
LifecycleHelper.unregister before the view is dropped.
Please refer to SampleLifecycleAwareViewManager.java from our example app to see what are the best ways of using the above methods.
React native screens library is licensed under The MIT License.