React NativeAdam Miskiewicz from Exponent talks about mobile navigation and the ex-navigation React Native library at Exponent's office hours last week.
React Native Blog
Stay up-to-date with the latest React Native news and events.
Adam Miskiewicz from Exponent talks about mobile navigation and the ex-navigation React Native library at Exponent's office hours last week.
Adam Miskiewicz from Expo talks about mobile navigation and the ex-navigation React Native library at Expo's office hours last week.
Shortly after React Native was introduced, we started releasing every two weeks to help the community adopt new features, while keeping versions stable for production use. At Facebook we had to stabilize the codebase every two weeks for the release of our production iOS apps, so we decided to release the open source versions at the same pace. Now, many of the Facebook apps ship once per week, especially on Android. Because we ship from master weekly, we need to keep it quite stable. So the bi-weekly release cadence doesn't even benefit internal contributors anymore.
We frequently hear feedback from the community that the release rate is hard to keep up with. Tools like Exponent had to skip every other release in order to manage the rapid change in version. So it seems clear that the bi-weekly releases did not serve the community well.
We're happy to announce the new monthly release cadence, and the December 2016 release, v0.40, which has been stabilizing for all last month and is ready to adopt. (Just make sure to update headers in your native modules on iOS).
Although it may vary a few days to avoid weekends or handle unforeseen issues, you can now expect a given release to be available on the first day of the month, and released on the last.
The January release candidate is ready to try, and you can see what's new here.
To see what changes are coming and provide better feedback to React Native contributors, always use the current month's release candidate when possible. By the time each version is released at the end of the month, the changes it contains will have been shipped in production Facebook apps for over two weeks.
You can easily upgrade your app with the new react-native-git-upgrade command:
Shortly after React Native was introduced, we started releasing every two weeks to help the community adopt new features, while keeping versions stable for production use. At Facebook we had to stabilize the codebase every two weeks for the release of our production iOS apps, so we decided to release the open source versions at the same pace. Now, many of the Facebook apps ship once per week, especially on Android. Because we ship from master weekly, we need to keep it quite stable. So the bi-weekly release cadence doesn't even benefit internal contributors anymore.
We frequently hear feedback from the community that the release rate is hard to keep up with. Tools like Expo had to skip every other release in order to manage the rapid change in version. So it seems clear that the bi-weekly releases did not serve the community well.
We're happy to announce the new monthly release cadence, and the December 2016 release, v0.40, which has been stabilizing for all last month and is ready to adopt. (Just make sure to update headers in your native modules on iOS).
Although it may vary a few days to avoid weekends or handle unforeseen issues, you can now expect a given release to be available on the first day of the month, and released on the last.
The January release candidate is ready to try, and you can see what's new here.
To see what changes are coming and provide better feedback to React Native contributors, always use the current month's release candidate when possible. By the time each version is released at the end of the month, the changes it contains will have been shipped in production Facebook apps for over two weeks.
You can easily upgrade your app with the new react-native-git-upgrade command:
We hope this simpler approach will make it easier for the community to keep track of changes in React Native, and to adopt new versions as quickly as possible!
(Thanks go to Martin Konicek for coming up with this plan and Mike Grabowski for making it happen)
For the past year, we've been working on improving performance of animations that use the Animated library. Animations are very important to create a beautiful user experience but can also be hard to do right. We want to make it easy for developers to create performant animations without having to worry about some of their code causing it to lag.
The Animated API was designed with a very important constraint in mind, it is serializable. This means we can send everything about the animation to native before it has even started and allows native code to perform the animation on the UI thread without having to go through the bridge on every frame. It is very useful because once the animation has started, the JS thread can be blocked and the animation will still run smoothly. In practice this can happen a lot because user code runs on the JS thread and React renders can also lock JS for a long time.
This project started about a year ago, when Exponent built the li.st app on Android. Krzysztof Magiera was contracted to build the initial implementation on Android. It ended up working well and li.st was the first app to ship with native driven animations using Animated. A few months later, Brandon Withrow built the initial implementation on iOS. After that, Ryan Gomba and myself worked on adding missing features like support for Animated.event as well as squash bugs we found when using it in production apps. This was truly a community effort and I would like to thanks everyone that was involved as well as Exponent for sponsoring a large part of the development. It is now used by Touchable components in React Native as well as for navigation animations in the newly released React Navigation library.
First, let's check out how animations currently work using Animated with the JS driver. When using Animated, you declare a graph of nodes that represent the animations that you want to perform, and then use a driver to update an Animated value using a predefined curve. You may also update an Animated value by connecting it to an event of a View using Animated.event.
Here's a breakdown of the steps for an animation and where it happens:
requestAnimationFrame to execute on every frame and update the value it drives using the new value it calculates based on the animation curve.View.View is updated using setNativeProps.UIView or android.View is updated.As you can see, most of the work happens on the JS thread. If it is blocked the animation will skip frames. It also needs to go through the JS to Native bridge on every frame to update native views.
What the native driver does is move all of these steps to native. Since Animated produces a graph of animated nodes, it can be serialized and sent to native only once when the animation starts, eliminating the need to callback into the JS thread; the native code can take care of updating the views directly on the UI thread on every frame.
Here's an example of how we can serialize an animated value and an interpolation node (not the exact implementation, just an example).
Create the native value node, this is the value that will be animated:
For the past year, we've been working on improving performance of animations that use the Animated library. Animations are very important to create a beautiful user experience but can also be hard to do right. We want to make it easy for developers to create performant animations without having to worry about some of their code causing it to lag.
The Animated API was designed with a very important constraint in mind, it is serializable. This means we can send everything about the animation to native before it has even started and allows native code to perform the animation on the UI thread without having to go through the bridge on every frame. It is very useful because once the animation has started, the JS thread can be blocked and the animation will still run smoothly. In practice this can happen a lot because user code runs on the JS thread and React renders can also lock JS for a long time.
This project started about a year ago, when Expo built the li.st app on Android. Krzysztof Magiera was contracted to build the initial implementation on Android. It ended up working well and li.st was the first app to ship with native driven animations using Animated. A few months later, Brandon Withrow built the initial implementation on iOS. After that, Ryan Gomba and myself worked on adding missing features like support for Animated.event as well as squash bugs we found when using it in production apps. This was truly a community effort and I would like to thanks everyone that was involved as well as Expo for sponsoring a large part of the development. It is now used by Touchable components in React Native as well as for navigation animations in the newly released React Navigation library.
First, let's check out how animations currently work using Animated with the JS driver. When using Animated, you declare a graph of nodes that represent the animations that you want to perform, and then use a driver to update an Animated value using a predefined curve. You may also update an Animated value by connecting it to an event of a View using Animated.event.
Here's a breakdown of the steps for an animation and where it happens:
requestAnimationFrame to execute on every frame and update the value it drives using the new value it calculates based on the animation curve.View.View is updated using setNativeProps.UIView or android.View is updated.As you can see, most of the work happens on the JS thread. If it is blocked the animation will skip frames. It also needs to go through the JS to Native bridge on every frame to update native views.
What the native driver does is move all of these steps to native. Since Animated produces a graph of animated nodes, it can be serialized and sent to native only once when the animation starts, eliminating the need to callback into the JS thread; the native code can take care of updating the views directly on the UI thread on every frame.
Here's an example of how we can serialize an animated value and an interpolation node (not the exact implementation, just an example).
Create the native value node, this is the value that will be animated:
For the past year, we've been working on improving performance of animations that use the Animated library. Animations are very important to create a beautiful user experience but can also be hard to do right. We want to make it easy for developers to create performant animations without having to worry about some of their code causing it to lag.
Shortly after React Native was introduced, we started releasing every two weeks to help the community adopt new features, while keeping versions stable for production use. At Facebook we had to stabilize the codebase every two weeks for the release of our production iOS apps, so we decided to release the open source versions at the same pace. Now, many of the Facebook apps ship once per week, especially on Android. Because we ship from master weekly, we need to keep it quite stable. So the bi-weekly release cadence doesn't even benefit internal contributors anymore.
Upgrading to new versions of React Native has been difficult. You might have seen something like this before:
We have heard from many people that there is so much work happening with React Native, it can be tough to keep track of what's going on. To help communicate what work is in progress, we are now publishing a roadmap for React Native. At a high level, this work can be broken down into three priorities:
Today we are releasing React Native 0.36. Read on to learn more about what's new.
Adam Miskiewicz from Exponent talks about mobile navigation and the ex-navigation React Native library at Exponent's office hours last week.
After launching an app to the app stores, internationalization is the next step to further your audience reach. Over 20 countries and numerous people around the world use Right-to-Left (RTL) languages. Thus, making your app support RTL for them is necessary.
Last week I had the opportunity to attend the React Native Meetup at Zynga’s San Francisco office. With around 200 people in attendance, it served as a great place to meet other developers near me that are also interested in React Native.
Part of having a great developer experience is having great documentation. A lot goes into creating good docs - the ideal documentation is concise, helpful, accurate, complete, and delightful. Recently we've been working hard to make the docs better based on your feedback, and we wanted to share some of the improvements we've made.
React Native's goal is to give you the best possible developer experience. A big part of it is the time it takes between you save a file and be able to see the changes. Our goal is to get this feedback loop to be under 1 second, even as your app grows.
For the past year, we've been working on improving performance of animations that use the Animated library. Animations are very important to create a beautiful user experience but can also be hard to do right. We want to make it easy for developers to create performant animations without having to worry about some of their code causing it to lag.
Shortly after React Native was introduced, we started releasing every two weeks to help the community adopt new features, while keeping versions stable for production use. At Facebook we had to stabilize the codebase every two weeks for the release of our production iOS apps, so we decided to release the open source versions at the same pace. Now, many of the Facebook apps ship once per week, especially on Android. Because we ship from master weekly, we need to keep it quite stable. So the bi-weekly release cadence doesn't even benefit internal contributors anymore.
Upgrading to new versions of React Native has been difficult. You might have seen something like this before:
We have heard from many people that there is so much work happening with React Native, it can be tough to keep track of what's going on. To help communicate what work is in progress, we are now publishing a roadmap for React Native. At a high level, this work can be broken down into three priorities:
Today we are releasing React Native 0.36. Read on to learn more about what's new.
Adam Miskiewicz from Expo talks about mobile navigation and the ex-navigation React Native library at Expo's office hours last week.
After launching an app to the app stores, internationalization is the next step to further your audience reach. Over 20 countries and numerous people around the world use Right-to-Left (RTL) languages. Thus, making your app support RTL for them is necessary.
Last week I had the opportunity to attend the React Native Meetup at Zynga’s San Francisco office. With around 200 people in attendance, it served as a great place to meet other developers near me that are also interested in React Native.
Part of having a great developer experience is having great documentation. A lot goes into creating good docs - the ideal documentation is concise, helpful, accurate, complete, and delightful. Recently we've been working hard to make the docs better based on your feedback, and we wanted to share some of the improvements we've made.
React Native's goal is to give you the best possible developer experience. A big part of it is the time it takes between you save a file and be able to see the changes. Our goal is to get this feedback loop to be under 1 second, even as your app grows.
Both iOS and Android provide APIs for making apps accessible to people with disabilities. In addition, both platforms provide bundled assistive technologies, like the screen readers VoiceOver (iOS) and TalkBack (Android) for the visually impaired. Similarly, in React Native we have included APIs designed to provide developers with support for making apps more accessible. Take note, iOS and Android differ slightly in their approaches, and thus the React Native implementations may vary by platform.
In addition to this documentation, you might find this blog post about React Native accessibility to be useful.
When true, indicates that the view is an accessibility element. When a view is an accessibility element, it groups its children into a single selectable component. By default, all touchable elements are accessible.
On Android, ‘accessible={true}’ property for a react-native View will be translated into native ‘focusable={true}’.
Both iOS and Android provide APIs for making apps accessible to people with disabilities. In addition, both platforms provide bundled assistive technologies, like the screen readers VoiceOver (iOS) and TalkBack (Android) for the visually impaired. Similarly, in React Native we have included APIs designed to provide developers with support for making apps more accessible. Take note, iOS and Android differ slightly in their approaches, and thus the React Native implementations may vary by platform.
In addition to this documentation, you might find this blog post about React Native accessibility to be useful.
When true, indicates that the view is an accessibility element. When a view is an accessibility element, it groups its children into a single selectable component. By default, all touchable elements are accessible.
On Android, ‘accessible={true}’ property for a react-native View will be translated into native ‘focusable={true}’.
In the above example, we can't get accessibility focus separately on 'text one' and 'text two'. Instead we get focus on a parent view with 'accessible' property.
When a view is marked as accessible, it is a good practice to set an accessibilityLabel on the view, so that people who use VoiceOver know what element they have selected. VoiceOver will read this string when a user selects the associated element.
To use, set the accessibilityLabel property to a custom string on your View:
Sometimes it's useful to know whether or not the device has a screen reader that is currently active. The +
Sometimes it's useful to know whether or not the device has a screen reader that is currently active. The
AccessibilityInfo API is designed for this purpose. You can use it to query the current state of the
screen reader as well as to register to be notified when the state of the screen reader changes.
Here's a small example illustrating how to use AccessibilityInfo:
Display an iOS action sheet. The options object must contain one or more
+
Display an iOS action sheet. The options object must contain one or more
of:
options (array of strings) - a list of button titles (required)cancelButtonIndex (int) - index of cancel button in optionsdestructiveButtonIndex (int) - index of destructive button in optionstitle (string) - a title to show above the action sheetmessage (string) - a message to show below the titleDisplay the iOS share sheet. The options object should contain
one or both of message and url and can additionally have
a subject or excludedActivityTypes:
url (string) - a URL to sharemessage (string) - a message to sharesubject (string) - a subject for the messageexcludedActivityTypes (array) - the activities to exclude from the ActionSheetNOTE: if url points to a local file, or is a base64-encoded
diff --git a/releases/next/docs/activityindicator.html b/releases/next/docs/activityindicator.html
index 213f28a79c5..c0cc20ff978 100644
--- a/releases/next/docs/activityindicator.html
+++ b/releases/next/docs/activityindicator.html
@@ -1,5 +1,5 @@
-
Displays a circular loading indicator.
bool #Whether to show the indicator (true, the default) or hide it (false).
[object Object] #The foreground color of the spinner (default is gray).
[object Object], [object Object] #Size of the indicator (default is 'small'). -Passing a number to the size prop is only supported on Android.
bool #Whether the indicator should hide when not animating (true by default).
You can edit the content above on GitHub and send us a pull request!
Examples # | Edit on GitHub |
Displays a circular loading indicator.
Whether to show the indicator (true, the default) or hide it (false).
Size of the indicator (default is 'small'). +Passing a number to the size prop is only supported on Android.
Whether the indicator should hide when not animating (true by default).
You can edit the content above on GitHub and send us a pull request!
Examples # | Edit on GitHub |
You can edit the content above on GitHub and send us a pull request!
Examples # | Edit on GitHub |
You can edit the content above on GitHub and send us a pull request!
Examples # | Edit on GitHub |
Launches an alert dialog with the specified title and message.
Optionally provide a list of buttons. Tapping any button will fire the +
Launches an alert dialog with the specified title and message.
Optionally provide a list of buttons. Tapping any button will fire the respective onPress callback and dismiss the alert. By default, the only button will be an 'OK' button.
This is an API that works both on iOS and Android and can show static alerts. To show an alert that prompts the user to enter some information, diff --git a/releases/next/docs/alertios.html b/releases/next/docs/alertios.html index 7acc2664f20..ff81181dc4b 100644 --- a/releases/next/docs/alertios.html +++ b/releases/next/docs/alertios.html @@ -1,4 +1,4 @@ -
AlertIOS provides functionality to create an iOS alert dialog with a
+
AlertIOS provides functionality to create an iOS alert dialog with a
message or create a prompt for user input.
Creating an iOS alert:
You will need to build React Native from source if you want to work on a new feature/bug fix, try out the latest features which are not released yet, or maintain your own fork with patches that cannot be merged to the core.
Assuming you have the Android SDK installed, run android to open the Android SDK Manager.
Make sure you have the following installed:
build.gradle)build.gradle)Step 1: Set environment variables through your local shell.
Note: Files may vary based on shell flavor. See below for examples from common shells.
.bash_profile or .bashrc.zprofile or .zshrc.profile or $ENVExample:
You will need to build React Native from source if you want to work on a new feature/bug fix, try out the latest features which are not released yet, or maintain your own fork with patches that cannot be merged to the core.
Assuming you have the Android SDK installed, run android to open the Android SDK Manager.
Make sure you have the following installed:
build.gradle)build.gradle)Step 1: Set environment variables through your local shell.
Note: Files may vary based on shell flavor. See below for examples from common shells.
.bash_profile or .bashrc.zprofile or .zshrc.profile or $ENVExample:
Step 2: Create a local.properties file in the android directory of your react-native app with the following contents:
Example:
You can find further instructions on the official page.
First, you need to install react-native from your fork. For example, to install the master branch from the official repo, run the following:
Alternatively, you can clone the repo to your node_modules directory and run npm install inside the cloned repo.
Add gradle-download-task as dependency in android/build.gradle:
The Animated library is designed to make animations fluid, powerful, and
+
The Animated library is designed to make animations fluid, powerful, and
easy to build and maintain. Animated focuses on declarative relationships
between inputs and outputs, with configurable transforms in between, and
simple start/stop methods to control time-based animation execution.
The simplest workflow for creating an animation is to to create an
@@ -92,8 +92,9 @@ then calls setValue on the mapped outputs. e.g.
Config is an object that may have the following options:
listener: Optional async listener.useNativeDriver: Uses the native driver when true. Default false.Make any React component Animatable. Used to create Animated.View, etc.
Imperative API to attach an animated value to an event on a view. Prefer using
-Animated.event with useNativeDrive: true if possible.
Standard value class for driving animations. Typically initialized with
-new Animated.Value(0);
See also AnimatedValue.
2D value class for driving 2D animations, such as pan gestures.
See also AnimatedValueXY.
exported to use the Interpolation type in flow
See also AnimatedInterpolation.
Standard value for driving animations. One Animated.Value can drive
+Animated.event with useNativeDrive: true if possible.
Advanced imperative API for snooping on animated events that are passed in through props. Use +values directly where possible.
Standard value class for driving animations. Typically initialized with
+new Animated.Value(0);
See also AnimatedValue.
2D value class for driving 2D animations, such as pan gestures.
See also AnimatedValueXY.
exported to use the Interpolation type in flow
See also AnimatedInterpolation.
Standard value for driving animations. One Animated.Value can drive
multiple properties in a synchronized fashion, but can only be driven by one
mechanism at a time. Using a new mechanism (e.g. starting a new animation,
or calling setValue) will stop any previous ones.
Directly set the value. This will stop any animations running on the value diff --git a/releases/next/docs/animations.html b/releases/next/docs/animations.html index ee7980eb20e..734008c378e 100644 --- a/releases/next/docs/animations.html +++ b/releases/next/docs/animations.html @@ -1,4 +1,4 @@ -
Animations are very important to create a great user experience. +
Animations are very important to create a great user experience. Stationary objects must overcome inertia as they start moving. Objects in motion have momentum and rarely come to a stop immediately. Animations allow you to convey physically believable motion in your interface.
React Native provides two complementary animation systems: @@ -198,7 +198,7 @@ row below which would otherwise require explicit coordination between the components in order to animate them all in sync.
Note that although LayoutAnimation is very powerful and can be quite useful,
it provides much less control than Animated and other animation libraries, so
you may need to use another approach if you can't get LayoutAnimation to do
-what you want.
Note that in order to get this to work on Android you need to set the following flags via UIManager:
AppRegistry is the JS entry point to running all React Native apps. App
+
AppRegistry is the JS entry point to running all React Native apps. App
root components should register themselves with
AppRegistry.registerComponent, then the native system can load the bundle
for the app and then actually run the app when it's ready by invoking
diff --git a/releases/next/docs/appstate.html b/releases/next/docs/appstate.html
index f01b22ef7af..30519434510 100644
--- a/releases/next/docs/appstate.html
+++ b/releases/next/docs/appstate.html
@@ -1,4 +1,4 @@
-
AppState can tell you if the app is in the foreground or background,
+
AppState can tell you if the app is in the foreground or background,
and notify you when the state changes.
AppState is frequently used to determine the intent and proper behavior when handling push notifications.
active - The app is running in the foregroundbackground - The app is running in the background. The user is either
in another app or on the home screeninactive - This is a state that occurs when transitioning between
diff --git a/releases/next/docs/asyncstorage.html b/releases/next/docs/asyncstorage.html
index 8d73cf7b9b4..aaf1f4e20e2 100644
--- a/releases/next/docs/asyncstorage.html
+++ b/releases/next/docs/asyncstorage.html
@@ -1,4 +1,4 @@
-AsyncStorage is a simple, unencrypted, asynchronous, persistent, key-value storage
+
AsyncStorage is a simple, unencrypted, asynchronous, persistent, key-value storage
system that is global to the app. It should be used instead of LocalStorage.
It is recommended that you use an abstraction on top of AsyncStorage
instead of AsyncStorage directly for anything more than light usage since
it operates globally.
On iOS, AsyncStorage is backed by native code that stores small values in a
diff --git a/releases/next/docs/backandroid.html b/releases/next/docs/backandroid.html
index e51b10460a6..bd478beceb3 100644
--- a/releases/next/docs/backandroid.html
+++ b/releases/next/docs/backandroid.html
@@ -1,16 +1,4 @@
-
Detect hardware back button presses, and programmatically invoke the default back button -functionality to exit the app if there are no listeners or if none of the listeners return true. -The event subscriptions are called in reverse order (i.e. last registered subscription first), -and if one subscription returns true then subscriptions registered earlier will not be called.
Example:
You can edit the content above on GitHub and send us a pull request!
Detect hardware button presses for back navigation.
Android: Detect hardware back button presses, and programmatically invoke the default back button +functionality to exit the app if there are no listeners or if none of the listeners return true.
tvOS: Detect presses of the menu button on the TV remote. (Still to be implemented: +programmatically disable menu button handling +functionality to exit the app if there are no listeners or if none of the listeners return true.)
iOS: Not applicable.
The event subscriptions are called in reverse order (i.e. last registered subscription first), +and if one subscription returns true then subscriptions registered earlier will not be called.
Example:
You can edit the content above on GitHub and send us a pull request!
A basic button component that should render nicely on any platform. Supports +
A basic button component that should render nicely on any platform. Supports a minimal level of customization.
If this button doesn't look right for your app, you can build your own @@ -10,7 +10,7 @@ Or, take a look at the ="Learn More" color="#841584" accessibilityLabel="Learn more about this purple button" -/>
?string #Text to display for blindness accessibility features
?string #Color of the text (iOS), or background color of the button (Android)
?boolean #If true, disable all interactions for this component.
() => any #Handler to be called when the user taps the button
?string #Used to locate this view in end-to-end tests.
string #Text to display inside the button
You can edit the content above on GitHub and send us a pull request!
Examples # | Edit on GitHub |
Text to display for blindness accessibility features
Color of the text (iOS), or background color of the button (Android)
If true, disable all interactions for this component.
Handler to be called when the user taps the button
Used to locate this view in end-to-end tests.
Text to display inside the button
You can edit the content above on GitHub and send us a pull request!
Examples # | Edit on GitHub |
CameraRoll provides access to the local camera roll / gallery.
+
CameraRoll provides access to the local camera roll / gallery.
Before using this you must link the RCTCameraRoll library.
You can refer to Linking for help.
The user's permission is required in order to access the Camera Roll on devices running iOS 10 or later.
Fill out the NSCameraUsageDescription key in your Info.plist with a string that describes how your
@@ -131,7 +131,7 @@ exports.examples : 'Photos',
render(): React.Element<any> { return <CameraRollExample />; }
}
-];
Clipboard gives you an interface for setting and getting content from Clipboard on both iOS and Android
Get content of string type, this method returns a Promise, so you can use following code to get clipboard content
Clipboard gives you an interface for setting and getting content from Clipboard on both iOS and Android
Get content of string type, this method returns a Promise, so you can use following code to get clipboard content
Set content of string type. You can use following code to set clipboard content
Components in React Native are styled using JavaScript. Color properties usually match how CSS works on the web.
React Native supports rgb() and rgba() in both hexadecimal and functional notation:
'#f0f' (#rgb)'#ff00ff' (#rrggbb)
'rgb(255, 0, 255)'
'rgba(255, 255, 255, 1.0)'
'#f0ff' (#rgba)
'#ff00ff00' (#rrggbbaa)hsl() and hsla() is supported in functional notation:
'hsl(360, 100%, 100%)''hsla(360, 100%, 100%, 1.0)'transparent #This is a shortcut for rgba(0,0,0,0):
'transparent'You can also use color names as values. React Native follows the CSS3 specification:
You can edit the content above on GitHub and send us a pull request!
Components in React Native are styled using JavaScript. Color properties usually match how CSS works on the web.
React Native supports rgb() and rgba() in both hexadecimal and functional notation:
'#f0f' (#rgb)'#ff00ff' (#rrggbb)
'rgb(255, 0, 255)'
'rgba(255, 255, 255, 1.0)'
'#f0ff' (#rgba)
'#ff00ff00' (#rrggbbaa)hsl() and hsla() is supported in functional notation:
'hsl(360, 100%, 100%)''hsla(360, 100%, 100%, 1.0)'transparent #This is a shortcut for rgba(0,0,0,0):
'transparent'You can also use color names as values. React Native follows the CSS3 specification:
You can edit the content above on GitHub and send us a pull request!
In Integrating with Existing Apps guide and Native UI Components guide we learn how to embed React Native in a native component and vice versa. When we mix native and React Native components, we'll eventually find a need to communicate between these two worlds. Some ways to achieve that have been already mentioned in other guides. This article summarizes available techniques.
React Native is inspired by React, so the basic idea of the information flow is similar. The flow in React is one-directional. We maintain a hierarchy of components, in which each component depends only on its parent and its own internal state. We do this with properties: data is passed from a parent to its children in a top-down manner. If an ancestor component relies on the state of its descendant, one should pass down a callback to be used by the descendant to update the ancestor.
The same concept applies to React Native. As long as we are building our application purely within the framework, we can drive our app with properties and callbacks. But, when we mix React Native and native components, we need some special, cross-language mechanisms that would allow us to pass information between them.
Properties are the simplest way of cross-component communication. So we need a way to pass properties both from native to React Native, and from React Native to native.
In order to embed a React Native view in a native component, we use RCTRootView. RCTRootView is a UIView that holds a React Native app. It also provides an interface between native side and the hosted app.
RCTRootView has an initializer that allows you to pass arbitrary properties down to the React Native app. The initialProperties parameter has to be an instance of NSDictionary. The dictionary is internally converted into a JSON object that the top-level JS component can reference.
In Integrating with Existing Apps guide and Native UI Components guide we learn how to embed React Native in a native component and vice versa. When we mix native and React Native components, we'll eventually find a need to communicate between these two worlds. Some ways to achieve that have been already mentioned in other guides. This article summarizes available techniques.
React Native is inspired by React, so the basic idea of the information flow is similar. The flow in React is one-directional. We maintain a hierarchy of components, in which each component depends only on its parent and its own internal state. We do this with properties: data is passed from a parent to its children in a top-down manner. If an ancestor component relies on the state of its descendant, one should pass down a callback to be used by the descendant to update the ancestor.
The same concept applies to React Native. As long as we are building our application purely within the framework, we can drive our app with properties and callbacks. But, when we mix React Native and native components, we need some special, cross-language mechanisms that would allow us to pass information between them.
Properties are the simplest way of cross-component communication. So we need a way to pass properties both from native to React Native, and from React Native to native.
In order to embed a React Native view in a native component, we use RCTRootView. RCTRootView is a UIView that holds a React Native app. It also provides an interface between native side and the hosted app.
RCTRootView has an initializer that allows you to pass arbitrary properties down to the React Native app. The initialProperties parameter has to be an instance of NSDictionary. The dictionary is internally converted into a JSON object that the top-level JS component can reference.
Opens the standard Android date picker dialog.
Opens the standard Android date picker dialog.
Use DatePickerIOS to render a date/time picker (selector) on iOS. This is
+
Use DatePickerIOS to render a date/time picker (selector) on iOS. This is
a controlled component, so you must hook in to the onDateChange callback
and update the date prop in order for the component to update, otherwise
the user's change will be reverted immediately to reflect props.date as the
-source of truth.
Date #The currently selected date.
Date #Maximum date.
Restricts the range of possible date/time values.
Date #Minimum date.
Restricts the range of possible date/time values.
enum(1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30) #The interval at which minutes can be selected.
enum('date', 'time', 'datetime') #The date picker mode.
function #Date change handler.
This is called when the user changes the date or time in the UI. +source of truth.
The currently selected date.
Maximum date.
Restricts the range of possible date/time values.
Minimum date.
Restricts the range of possible date/time values.
The interval at which minutes can be selected.
The date picker mode.
Date change handler.
This is called when the user changes the date or time in the UI. The first and only argument is a Date object representing the new -date and time.
number #Timezone offset in minutes.
By default, the date picker will use the device's timezone. With this +date and time.
Timezone offset in minutes.
By default, the date picker will use the device's timezone. With this parameter, it is possible to force a certain timezone offset. For instance, to show times in Pacific Standard Time, pass -7 * 60.
You can edit the content above on GitHub and send us a pull request!
Examples # | Edit on GitHub |
You can access the developer menu by shaking your device or by selecting "Shake Gesture" inside the Hardware menu in the iOS Simulator. You can also use the Command⌘ + D keyboard shortcut when your app is running in the iPhone Simulator, or Command⌘ + M when running in an Android emulator.
The Developer Menu is disabled in release (production) builds.
Instead of recompiling your app every time you make a change, you can reload your app's JavaScript code instantly. To do so, select "Reload" from the Developer Menu. You can also press Command⌘ + R in the iOS Simulator, or press R twice on Android emulators.
If the
Command⌘+Rkeyboard shortcut does not seem to reload the iOS Simulator, go to the Hardware menu, select Keyboard, and make sure that "Connect Hardware Keyboard" is checked.
You can speed up your development times by having your app reload automatically any time your code changes. Automatic reloading can be enabled by selecting "Enable Live Reload" from the Developer Menu.
You may even go a step further and keep your app running as new versions of your files are injected into the JavaScript bundle automatically by enabling Hot Reloading from the Developer Menu. This will allow you to persist the app's state through reloads.
There are some instances where hot reloading cannot be implemented perfectly. If you run into any issues, use a full reload to reset your app.
You will need to rebuild your app for changes to take effect in certain situations:
Images.xcassets on iOS or the res/drawable folder on Android.Errors and warnings are displayed inside your app in development builds.
In-app errors are displayed in a full screen alert with a red background inside your app. This screen is known as a RedBox. You can use console.error() to manually trigger one.
Warnings will be displayed on screen with a yellow background. These alerts are known as YellowBoxes. Click on the alerts to show more information or to dismiss them.
As with a RedBox, you can use console.warn() to trigger a YellowBox.
YellowBoxes can be disabled during development by using console.disableYellowBox = true;. Specific warnings can be ignored programmatically by setting an array of prefixes that should be ignored: console.ignoredYellowBox = ['Warning: ...'];.
In CI/Xcode, YellowBoxes can also be disabled by setting the IS_TESTING environment variable.
RedBoxes and YellowBoxes are automatically disabled in release (production) builds.
You can display the console logs for an iOS or Android app by using the following commands in a terminal while the app is running:
You can access the developer menu by shaking your device or by selecting "Shake Gesture" inside the Hardware menu in the iOS Simulator. You can also use the Command⌘ + D keyboard shortcut when your app is running in the iPhone Simulator, or Command⌘ + M when running in an Android emulator.
The Developer Menu is disabled in release (production) builds.
Instead of recompiling your app every time you make a change, you can reload your app's JavaScript code instantly. To do so, select "Reload" from the Developer Menu. You can also press Command⌘ + R in the iOS Simulator, or press R twice on Android emulators.
If the
Command⌘+Rkeyboard shortcut does not seem to reload the iOS Simulator, go to the Hardware menu, select Keyboard, and make sure that "Connect Hardware Keyboard" is checked.
You can speed up your development times by having your app reload automatically any time your code changes. Automatic reloading can be enabled by selecting "Enable Live Reload" from the Developer Menu.
You may even go a step further and keep your app running as new versions of your files are injected into the JavaScript bundle automatically by enabling Hot Reloading from the Developer Menu. This will allow you to persist the app's state through reloads.
There are some instances where hot reloading cannot be implemented perfectly. If you run into any issues, use a full reload to reset your app.
You will need to rebuild your app for changes to take effect in certain situations:
Images.xcassets on iOS or the res/drawable folder on Android.Errors and warnings are displayed inside your app in development builds.
In-app errors are displayed in a full screen alert with a red background inside your app. This screen is known as a RedBox. You can use console.error() to manually trigger one.
Warnings will be displayed on screen with a yellow background. These alerts are known as YellowBoxes. Click on the alerts to show more information or to dismiss them.
As with a RedBox, you can use console.warn() to trigger a YellowBox.
YellowBoxes can be disabled during development by using console.disableYellowBox = true;. Specific warnings can be ignored programmatically by setting an array of prefixes that should be ignored: console.ignoredYellowBox = ['Warning: ...'];.
In CI/Xcode, YellowBoxes can also be disabled by setting the IS_TESTING environment variable.
RedBoxes and YellowBoxes are automatically disabled in release (production) builds.
You can display the console logs for an iOS or Android app by using the following commands in a terminal while the app is running:
You may also access these through Debug → Open System Log... in the iOS Simulator or by running adb logcat *:S ReactNative:V ReactNativeJS:V in a terminal while an Android app is running on a device or emulator.
To debug the JavaScript code in Chrome, select "Debug JS Remotely" from the Developer Menu. This will open a new tab at http://localhost:8081/debugger-ui.
Select Tools → Developer Tools from the Chrome Menu to open the Developer Tools. You may also access the DevTools using keyboard shortcuts (Command⌘ + Option⌥ + I on Mac, Ctrl + Shift + I on Windows). You may also want to enable Pause On Caught Exceptions for a better debugging experience.
It is currently not possible to use the "React" tab in the Chrome Developer Tools to inspect app widgets. You can use Nuclide's "React Native Inspector" as a workaround.
On iOS devices, open the file RCTWebSocketExecutor.m and change "localhost" to the IP address of your computer, then select "Debug JS Remotely" from the Developer Menu.
On Android 5.0+ devices connected via USB, you can use the adb command line tool to setup port forwarding from the device to your computer:
adb reverse tcp:8081 tcp:8081
Alternatively, select "Dev Settings" from the Developer Menu, then update the "Debug server host for device" setting to match the IP address of your computer.
If you run into any issues, it may be possible that one of your Chrome extensions is interacting in unexpected ways with the debugger. Try disabling all of your extensions and re-enabling them one-by-one until you find the problematic extension.
To use a custom JavaScript debugger in place of Chrome Developer Tools, set the REACT_DEBUGGER environment variable to a command that will start your custom debugger. You can then select "Debug JS Remotely" from the Developer Menu to start debugging.
The debugger will receive a list of all project roots, separated by a space. For example, if you set REACT_DEBUGGER="node /path/to/launchDebugger.js --port 2345 --type ReactNative", then the command node /path/to/launchDebugger.js --port 2345 --type ReactNative /path/to/reactNative/app will be used to start your debugger.
Custom debugger commands executed this way should be short-lived processes, and they shouldn't produce more than 200 kilobytes of output.
In android/app/build.gradle, add these lines in the dependencies section:
In android/app/src/main/java/com/{yourAppName}/MainApplication.java, add the following imports: