diff --git a/blog/2016/03/24/introducing-hot-reloading.html b/blog/2016/03/24/introducing-hot-reloading.html index a832bbf82fb..6ece2a8238a 100644 --- a/blog/2016/03/24/introducing-hot-reloading.html +++ b/blog/2016/03/24/introducing-hot-reloading.html @@ -1,4 +1,4 @@ -Introducing Hot Reloading

Introducing Hot Reloading

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.

We got close to this ideal via three main features:

  • Use JavaScript as the language doesn't have a long compilation cycle time.
  • Implement a tool called Packager that transforms es6/flow/jsx files into normal JavaScript that the VM can understand. It was designed as a server that keeps intermediate state in memory to enable fast incremental changes and uses multiple cores.
  • Build a feature called Live Reload that reloads the app on save.

At this point, the bottleneck for developers is no longer the time it takes to reload the app but losing the state of your app. A common scenario is to work on a feature that is multiple screens away from the launch screen. Every time you reload, you've got to click on the same path again and again to get back to your feature, making the cycle multiple-seconds long.

Hot Reloading #

The idea behind hot reloading is to keep the app running and to inject new versions of the files that you edited at runtime. This way, you don't lose any of your state which is especially useful if you are tweaking the UI.

A video is worth a thousand words. Check out the difference between Live Reload (current) and Hot Reload (new).

+Introducing Hot Reloading
React Native Blog
Stay up-to-date with the latest React Native news and events.

Introducing Hot Reloading

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.

We got close to this ideal via three main features:

  • Use JavaScript as the language doesn't have a long compilation cycle time.
  • Implement a tool called Packager that transforms es6/flow/jsx files into normal JavaScript that the VM can understand. It was designed as a server that keeps intermediate state in memory to enable fast incremental changes and uses multiple cores.
  • Build a feature called Live Reload that reloads the app on save.

At this point, the bottleneck for developers is no longer the time it takes to reload the app but losing the state of your app. A common scenario is to work on a feature that is multiple screens away from the launch screen. Every time you reload, you've got to click on the same path again and again to get back to your feature, making the cycle multiple-seconds long.

Hot Reloading #

The idea behind hot reloading is to keep the app running and to inject new versions of the files that you edited at runtime. This way, you don't lose any of your state which is especially useful if you are tweaking the UI.

A video is worth a thousand words. Check out the difference between Live Reload (current) and Hot Reload (new).

If you look closely, you can notice that it is possible to recover from a red box and you can also start importing modules that were not previously there without having to do a full reload.

Word of warning: because JavaScript is a very stateful language, hot reloading cannot be perfectly implemented. In practice, we found out that the current setup is working well for a large amount of usual use cases and a full reload is always available in case something gets messed up.

Hot reloading is available as of 0.22, you can enable it:

  • Open the developer menu
  • Tap on "Enable Hot Reloading"

Implementation in a nutshell #

Now that we've seen why we want it and how to use it, the fun part begins: how it actually works.

Hot Reloading is built on top of a feature Hot Module Replacement, or HMR. It was first introduced by Webpack and we implemented it inside of React Native Packager. HMR makes the Packager watch for file changes and send HMR updates to a thin HMR runtime included on the app.

In a nutshell, the HMR update contains the new code of the JS modules that changed. When the runtime receives them, it replaces the old modules' code with the new one:

The HMR update contains a bit more than just the module's code we want to change because replacing it, it's not enough for the runtime to pick up the changes. The problem is that the module system may have already cached the exports of the module we want to update. For instance, say you have an app composed of these two modules:

// log.js function log(message) { @@ -69,7 +69,7 @@ export default function } return store; -};

When you change a reducer, the code to accept that reducer will be sent to the client. Then the client will realize that the reducer doesn't know how to accept itself, so it will look for all the modules that refer it and try to accept them. Eventually, the flow will get to the single store, the configureStore module, which will accept the HMR update.

Conclusion #

If you are interested in helping making hot reloading better, I encourage you to read Dan Abramov's post around the future of hot reloading and to contribute. For example, Johny Days is going to make it work with multiple connected clients. We're relying on you all to maintain and improve this feature.

With React Native, we have the opportunity to rethink the way we build apps in order to make it a great developer experience. Hot reloading is only one piece of the puzzle, what other crazy hacks can we do to make it better?

\ No newline at end of file + \ No newline at end of file diff --git a/blog/2016/07/06/toward-better-documentation.html b/blog/2016/07/06/toward-better-documentation.html index 78f6f064a39..86d59ed1e41 100644 --- a/blog/2016/07/06/toward-better-documentation.html +++ b/blog/2016/07/06/toward-better-documentation.html @@ -1,4 +1,4 @@ -Toward Better Documentation

Toward Better Documentation

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.

Inline Examples #

When you learn a new library, a new programming language, or a new framework, there's a beautiful moment when you first write a bit of code, try it out, see if it works... and it does work. You created something real. We wanted to put that visceral experience right into our docs. Like this:

import React, { Component } from 'react'; +Toward Better Documentation
React Native Blog
Stay up-to-date with the latest React Native news and events.

Toward Better Documentation

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.

Inline Examples #

When you learn a new library, a new programming language, or a new framework, there's a beautiful moment when you first write a bit of code, try it out, see if it works... and it does work. You created something real. We wanted to put that visceral experience right into our docs. Like this:

import React, { Component } from 'react'; import { AppRegistry, Text, View } from 'react-native'; class ScratchPad extends Component { @@ -16,7 +16,7 @@ class ScratchPad extends } } -AppRegistry.registerComponent('ScratchPad', () => ScratchPad);

We think these inline examples, using the react-native-web-player module with help from Devin Abbott, are a great way to learn the basics of React Native, and we have updated our tutorial for new React Native developers to use these wherever possible. Check it out - if you have ever been curious to see what would happen if you modified just one little bit of sample code, this is a really nice way to poke around. Also, if you're building developer tools and you want to show a live React Native sample on your own site, react-native-web-player can make that straightforward.

The core simulation engine is provided by Nicolas Gallagher's react-native-web project, which provides a way to display React Native components like Text and View on the web. Check out react-native-web if you're interested in building mobile and web experiences that share a large chunk of the codebase.

Better Guides #

In some parts of React Native, there are multiple ways to do things, and we've heard feedback that we could provide better guidance.

We have a new guide to Navigation that compares the different approaches and advises on what you should use - Navigator, NavigatorIOS, NavigationExperimental. In the medium term, we're working towards improving and consolidating those interfaces. In the short term, we hope that a better guide will make your life easier.

We also have a new guide to handling touches that explains some of the basics of making button-like interfaces, and a brief summary of the different ways to handle touch events.

Another area we worked on is Flexbox. This includes tutorials on how to handle layout with Flexbox and how to control the size of components. It also includes an unsexy but hopefully-useful list of all the props that control layout in React Native.

Getting Started #

When you start getting a React Native development environment set up on your machine, you do have to do a bunch of installing and configuring things. It's hard to make installation a really fun and exciting experience, but we can at least make it as quick and painless as possible.

We built a new Getting Started workflow that lets you select your development operating system and your mobile operating system up front, to provide one concise place with all the setup instructions. We also went through the installation process to make sure everything worked and to make sure that every decision point had a clear recommendation. After testing it out on our innocent coworkers, we're pretty sure this is an improvement.

We also worked on the guide to integrating React Native into an existing app. Many of the largest apps that use React Native, like the Facebook app itself, actually build part of the app in React Native, and part of it using regular development tools. We hope this guide makes it easier for more people to build apps this way.

We Need Your Help #

Your feedback lets us know what we should prioritize. I know some people will read this blog post and think "Better docs? Pffft. The documentation for X is still garbage!". That's great - we need that energy. The best way to give us feedback depends on the sort of feedback.

If you find a mistake in the documentation, like inaccurate descriptions or code that doesn't actually work, file an issue. Tag it with "Documentation", so that it's easier to route it to the right people.

If there isn't a specific mistake, but something in the documentation is fundamentally confusing, it's not a great fit for a GitHub issue. Instead, complain on Product Pains about the area of the docs that could use help. This helps us prioritize when we are doing more general work like guide-writing.

Thanks for reading this far, and thanks for using React Native!

\ No newline at end of file + \ No newline at end of file diff --git a/blog/2016/08/12/react-native-meetup-san-francisco.html b/blog/2016/08/12/react-native-meetup-san-francisco.html index be5c9549ab6..e288f705ae4 100644 --- a/blog/2016/08/12/react-native-meetup-san-francisco.html +++ b/blog/2016/08/12/react-native-meetup-san-francisco.html @@ -1,4 +1,4 @@ -San Francisco Meetup Recap

San Francisco Meetup Recap

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.

I was particularly interested in learning more about how React and React Native are used at companies like Zynga, Netflix, and Airbnb. The agenda for the night would be as follows:

  • Rapid Prototyping in React
  • Designing APIs for React Native
  • Bridging the Gap: Using React Native in Existing Codebases

But first, the event started off with a quick introduction and a brief recap of recent news:

If one of these meetups is held near you, I highly recommend attending!

Rapid Prototyping in React at Zynga #

The first round of news was followed by a quick introduction by Zynga, our hosts for the evening. Abhishek Chadha talked about how they use React to quickly prototype new experiences on mobile, demoing a quick prototype of a Draw Something-like app. They use a similar approach as React Native, providing access to native APIs via a bridge. This was demonstrated when Abhishek used the device's camera to snap a photo of the audience and then drew a hat on someone's head.

Designing APIs for React Native at Netflix #

Up next, the first featured talk of the evening. Clarence Leung, Senior Software Engineer at Netflix, presented his talk on Designing APIs for React Native. First he noted the two main types of libraries one may work on: components such as tab bars and date pickers, and libraries that provide access to native services such as the camera roll or in-app payments. There are two ways one may approach when building a library for use in React Native:

  • Provide platform-specific components
  • A cross-platform library with a similar API for both iOS and Android

Each approach has its own considerations, and it’s up to you to determine what works best for your needs.

Approach #1

As an example of platform-specific components, Clarence talked about the DatePickerIOS and DatePickerAndroid from core React Native. On iOS, date pickers are rendered as part of the UI and can be easily embedded in an existing view, while date pickers on Android are presented modally. It makes sense to provide separate components in this case.

Approach #2

Photo pickers, on the other hand, are treated similarly on iOS and Android. There are some slight differences — Android does not group photos into folders like iOS does with Selfies, for example — but those are easily handled using if statements and the Platform component.

Regardless of which approach you settle on, it’s a good idea to minimize the API surface and build app-specific libraries. For example, iOS’s In-App Purchase framework supports one-time, consumable purchases, as well as renewable subscriptions. If your app will only need to support consumable purchases, you may get away with dropping support for subscriptions in your cross-platform library.

There was a brief Q&A session at the end of Clarence’s talk. One of the interesting tid bits that came out of it was that around 80% of the React Native code written for these libraries at Netflix is shared across both iOS and Android.

Bridging the Gap, Using React Native in Existing Codebases #

The final talk of the night was by Leland Richardson from Airbnb. The talk was focused on the use of React Native in existing codebases. I already know how easy it is to write a new app from scratch using React Native, so I was very interested to hear about Airbnb’s experience adopting React Native in their existing native apps.

Leland started off by talking about greenfield apps versus brownfield apps. Greenfield means to start a project without the need to consider any prior work. This is in contrast to brownfield projects where you need to take into account the existing project’s requirements, development processes, and all of the teams various needs.

When you’re working on a greenfield app, the React Native CLI sets up a single repository for both iOS and Android and everything just works. The first challenge against using React Native at Airbnb was the fact that the iOS and Android app each had their own repository. Multi-repo companies have some hurdles to get past before they can adopt React Native.

To get around this, Airbnb first set up a new repo for the React Native codebase. They used their continuous integration servers to mirror the iOS and Android repos into this new repo. After tests are run and the bundle is built, the build artifacts are synced back to the iOS and Android repos. This allows the mobile engineers to work on native code without altering their development enviroment. Mobile engineers don't need to install npm, run the packager, or remember to build the JavaScript bundle. The engineers writing actual React Native code do not have to worry about syncing their code across iOS and Android, as they work on the React Native repository directly.

This does come with some drawbacks, mainly they could not ship atomic updates. Changes that require a combination of native and JavaScript code would require three separate pull requests, all of which had to be carefully landed. In order to avoid conflicts, CI will fail to land changes back to the iOS and Android repos if master has changed since the build started. This would cause long delays during high commit frequency days (such as when new releases are cut).

Airbnb has since moved to a mono repo approach. Fortunately this was already under consideration, and once the iOS and Android teams became comfortable with using React Native they were happy to accelerate the move towards the mono repo.

This has solved most of the issues they had with the split repo approach. Leland did note that this does cause a higher strain on the version control servers, which may be an issue for smaller companies.

The Navigation Problem #

The second half of Leland's talk focused on a topic that is dear to me: the Navigation problem in React Native. He talked about the abundance of navigation libraries in React Native, both first party and third party. NavigationExperimental was mentioned as something that seemed promising, but ended up not being well suited for their use case.

In fact, none of the existing navigation libraries seem to work well for brownfield apps. A brownfield app requires that the navigation state be fully owned by the native app. For example, if a user’s session expires while a React Native view is being presented, the native app should be able to take over and present a login screen as needed.

Airbnb also wanted to avoid replacing native navigation bars with JavaScript versions as part of a transition, as the effect could be jarring. Initially they limited themselves to modally presented views, but this obviously presented a problem when it came to adopting React Native more widely within their apps.

They decided that they needed their own library. The library is called airbnb-navigation. The library has not yet being open sourced as it is strongly tied to Airbnb’s codebase, but it is something they’d like to release by the end of the year.

I won’t go into much detail into the library’s API, but here are some of the key takeaways:

  • One must preregister scenes ahead of time
  • Each scene is displayed within its own RCTRootView. They are presented natively on each platform (e.g. UINavigationControllers are used on iOS).
  • The main ScrollView in a scene should be wrapped in a ScrollScene component. Doing so allows you to take advantage of native behaviors such as tapping on the status bar to scroll to the top on iOS.
  • Transitions between scenes are handled natively, no need to worry about performance.
  • The Android back button is automatically supported.
  • They can take advantage of View Controller based navigation bar styling via a Navigator.Config UI-less component.

There’s also some considerations to keep in mind:

  • The navigation bar is not easily customized in JavaScript, as it is a native component. This is intentional, as using native navigation bars is a hard requirement for this type of library.
  • ScreenProps must be serialized/de-serialized whenever they're sent through the bridge, so care must be taken if sending too much data here.
  • Navigation state is owned by the native app (also a hard requirement for the library), so things like Redux cannot manipulate navigation state.

Leland's talk was also followed by a Q&A session. Overall, Airbnb is satisfied with React Native. They’re interested in using Code Push to fix any issues without going through the App Store, and their engineers love Live Reload, as they don't have to wait for the native app to be rebuilt after every minor change.

Closing Remarks #

The event ended with some additional React Native news:

Meetups provide a good opportunity to meet and learn from other developers in the community. I'm looking forward to attending more React Native meetups in the future. If you make it up to one of these, please look out for me and let me know how we can make React Native work better for you!

React Native Blog
Stay up-to-date with the latest React Native news and events.

San Francisco Meetup Recap

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.

I was particularly interested in learning more about how React and React Native are used at companies like Zynga, Netflix, and Airbnb. The agenda for the night would be as follows:

  • Rapid Prototyping in React
  • Designing APIs for React Native
  • Bridging the Gap: Using React Native in Existing Codebases

But first, the event started off with a quick introduction and a brief recap of recent news:

If one of these meetups is held near you, I highly recommend attending!

Rapid Prototyping in React at Zynga #

The first round of news was followed by a quick introduction by Zynga, our hosts for the evening. Abhishek Chadha talked about how they use React to quickly prototype new experiences on mobile, demoing a quick prototype of a Draw Something-like app. They use a similar approach as React Native, providing access to native APIs via a bridge. This was demonstrated when Abhishek used the device's camera to snap a photo of the audience and then drew a hat on someone's head.

Designing APIs for React Native at Netflix #

Up next, the first featured talk of the evening. Clarence Leung, Senior Software Engineer at Netflix, presented his talk on Designing APIs for React Native. First he noted the two main types of libraries one may work on: components such as tab bars and date pickers, and libraries that provide access to native services such as the camera roll or in-app payments. There are two ways one may approach when building a library for use in React Native:

  • Provide platform-specific components
  • A cross-platform library with a similar API for both iOS and Android

Each approach has its own considerations, and it’s up to you to determine what works best for your needs.

Approach #1

As an example of platform-specific components, Clarence talked about the DatePickerIOS and DatePickerAndroid from core React Native. On iOS, date pickers are rendered as part of the UI and can be easily embedded in an existing view, while date pickers on Android are presented modally. It makes sense to provide separate components in this case.

Approach #2

Photo pickers, on the other hand, are treated similarly on iOS and Android. There are some slight differences — Android does not group photos into folders like iOS does with Selfies, for example — but those are easily handled using if statements and the Platform component.

Regardless of which approach you settle on, it’s a good idea to minimize the API surface and build app-specific libraries. For example, iOS’s In-App Purchase framework supports one-time, consumable purchases, as well as renewable subscriptions. If your app will only need to support consumable purchases, you may get away with dropping support for subscriptions in your cross-platform library.

There was a brief Q&A session at the end of Clarence’s talk. One of the interesting tid bits that came out of it was that around 80% of the React Native code written for these libraries at Netflix is shared across both iOS and Android.

Bridging the Gap, Using React Native in Existing Codebases #

The final talk of the night was by Leland Richardson from Airbnb. The talk was focused on the use of React Native in existing codebases. I already know how easy it is to write a new app from scratch using React Native, so I was very interested to hear about Airbnb’s experience adopting React Native in their existing native apps.

Leland started off by talking about greenfield apps versus brownfield apps. Greenfield means to start a project without the need to consider any prior work. This is in contrast to brownfield projects where you need to take into account the existing project’s requirements, development processes, and all of the teams various needs.

When you’re working on a greenfield app, the React Native CLI sets up a single repository for both iOS and Android and everything just works. The first challenge against using React Native at Airbnb was the fact that the iOS and Android app each had their own repository. Multi-repo companies have some hurdles to get past before they can adopt React Native.

To get around this, Airbnb first set up a new repo for the React Native codebase. They used their continuous integration servers to mirror the iOS and Android repos into this new repo. After tests are run and the bundle is built, the build artifacts are synced back to the iOS and Android repos. This allows the mobile engineers to work on native code without altering their development enviroment. Mobile engineers don't need to install npm, run the packager, or remember to build the JavaScript bundle. The engineers writing actual React Native code do not have to worry about syncing their code across iOS and Android, as they work on the React Native repository directly.

This does come with some drawbacks, mainly they could not ship atomic updates. Changes that require a combination of native and JavaScript code would require three separate pull requests, all of which had to be carefully landed. In order to avoid conflicts, CI will fail to land changes back to the iOS and Android repos if master has changed since the build started. This would cause long delays during high commit frequency days (such as when new releases are cut).

Airbnb has since moved to a mono repo approach. Fortunately this was already under consideration, and once the iOS and Android teams became comfortable with using React Native they were happy to accelerate the move towards the mono repo.

This has solved most of the issues they had with the split repo approach. Leland did note that this does cause a higher strain on the version control servers, which may be an issue for smaller companies.

The Navigation Problem #

The second half of Leland's talk focused on a topic that is dear to me: the Navigation problem in React Native. He talked about the abundance of navigation libraries in React Native, both first party and third party. NavigationExperimental was mentioned as something that seemed promising, but ended up not being well suited for their use case.

In fact, none of the existing navigation libraries seem to work well for brownfield apps. A brownfield app requires that the navigation state be fully owned by the native app. For example, if a user’s session expires while a React Native view is being presented, the native app should be able to take over and present a login screen as needed.

Airbnb also wanted to avoid replacing native navigation bars with JavaScript versions as part of a transition, as the effect could be jarring. Initially they limited themselves to modally presented views, but this obviously presented a problem when it came to adopting React Native more widely within their apps.

They decided that they needed their own library. The library is called airbnb-navigation. The library has not yet being open sourced as it is strongly tied to Airbnb’s codebase, but it is something they’d like to release by the end of the year.

I won’t go into much detail into the library’s API, but here are some of the key takeaways:

  • One must preregister scenes ahead of time
  • Each scene is displayed within its own RCTRootView. They are presented natively on each platform (e.g. UINavigationControllers are used on iOS).
  • The main ScrollView in a scene should be wrapped in a ScrollScene component. Doing so allows you to take advantage of native behaviors such as tapping on the status bar to scroll to the top on iOS.
  • Transitions between scenes are handled natively, no need to worry about performance.
  • The Android back button is automatically supported.
  • They can take advantage of View Controller based navigation bar styling via a Navigator.Config UI-less component.

There’s also some considerations to keep in mind:

  • The navigation bar is not easily customized in JavaScript, as it is a native component. This is intentional, as using native navigation bars is a hard requirement for this type of library.
  • ScreenProps must be serialized/de-serialized whenever they're sent through the bridge, so care must be taken if sending too much data here.
  • Navigation state is owned by the native app (also a hard requirement for the library), so things like Redux cannot manipulate navigation state.

Leland's talk was also followed by a Q&A session. Overall, Airbnb is satisfied with React Native. They’re interested in using Code Push to fix any issues without going through the App Store, and their engineers love Live Reload, as they don't have to wait for the native app to be rebuilt after every minor change.

Closing Remarks #

The event ended with some additional React Native news:

Meetups provide a good opportunity to meet and learn from other developers in the community. I'm looking forward to attending more React Native meetups in the future. If you make it up to one of these, please look out for me and let me know how we can make React Native work better for you!

\ No newline at end of file + \ No newline at end of file diff --git a/blog/2016/08/19/right-to-left-support-for-react-native-apps.html b/blog/2016/08/19/right-to-left-support-for-react-native-apps.html index 59869879f0a..4729398b0c1 100644 --- a/blog/2016/08/19/right-to-left-support-for-react-native-apps.html +++ b/blog/2016/08/19/right-to-left-support-for-react-native-apps.html @@ -1,4 +1,4 @@ -Right-to-Left Layout Support For React Native Apps

Right-to-Left Layout Support For React Native Apps

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.

We're glad to announce that React Native has been improved to support RTL layouts. This is now available in the react-native master branch today, and will be available in the next RC: v0.33.0-rc.

This involved changing css-layout, the core layout engine used by RN, and RN core implementation, as well as specific OSS JS components to support RTL.

To battle test the RTL support in production, the latest version of the Facebook Ads Manager app (the first cross-platform 100% RN app) is now available in Arabic and Hebrew with RTL layouts for both iOS and Android. Here is how it looks like in those RTL languages:

+Right-to-Left Layout Support For React Native Apps

React Native Blog
Stay up-to-date with the latest React Native news and events.

Right-to-Left Layout Support For React Native Apps

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.

We're glad to announce that React Native has been improved to support RTL layouts. This is now available in the react-native master branch today, and will be available in the next RC: v0.33.0-rc.

This involved changing css-layout, the core layout engine used by RN, and RN core implementation, as well as specific OSS JS components to support RTL.

To battle test the RTL support in production, the latest version of the Facebook Ads Manager app (the first cross-platform 100% RN app) is now available in Arabic and Hebrew with RTL layouts for both iOS and Android. Here is how it looks like in those RTL languages:

@@ -81,7 +81,7 @@ _onDirectionChange = 'Check them out to see what they look like in RTL layout.' ); };

When working on a new feature, you can easily toggle this button and reload the app to see RTL layout. The benefit is you won't need to change the language setting to test, however some text alignment won't change, as explained in the next section. Therefore, it's always a good idea to test your app in the RTL language before launching.

Limitations and Future Plan #

The RTL support should cover most of the UX in your app; however, there are some limitations for now:

  • Text alignment behaviors differ in iOS and Android
    • In iOS, the default text alignment depends on the active language bundle, they are consistently on one side. In Android, the default text alignment depends on the language of the text content, i.e. English will be left-aligned and Arabic will be right-aligned.
    • In theory, this should be made consistent across platform, but some people may prefer one behavior to another when using an app. More user experience research may be needed to find out the best practice for text alignment.
  • There is no "true" left/right

    As discussed before, we map the left/right styles from the JS side to start/end, all left in code for RTL layout becomes "right" on screen, and right in code becomes "left" on screen. This is convenient because you don't need to change your product code too much, but it means there is no way to specify "true left" or "true right" in the code. In the future, allowing a component to control its direction regardless of the language may be necessary.

  • Make RTL support for gestures and animations more developer friendly

    Currently, there is still some programming effort required to make gestures and animations RTL compatible. - In the future, it would be ideal to find a way to make gestures and animations RTL support more developer friendly.

Try it Out! #

Check out the RTLExample in the UIExplorer to understand more about RTL support, and let us know how it works for you!

Finally, thank you for reading! We hope that the RTL support for React Native helps you grow your apps for international audience!

\ No newline at end of file + \ No newline at end of file diff --git a/blog/2016/09/08/exponent-talks-unraveling-navigation.html b/blog/2016/09/08/exponent-talks-unraveling-navigation.html index b6973bdca16..e6ff0f2e5f4 100644 --- a/blog/2016/09/08/exponent-talks-unraveling-navigation.html +++ b/blog/2016/09/08/exponent-talks-unraveling-navigation.html @@ -1,4 +1,4 @@ -Exponent Talks: Adam on Unraveling Navigation
React Native Blog
Stay up-to-date with the latest React Native news and events.
\ No newline at end of file + \ No newline at end of file diff --git a/blog/2016/10/25/0-36-headless-js-the-keyboard-api-and-more.html b/blog/2016/10/25/0-36-headless-js-the-keyboard-api-and-more.html index 84b0cd73d74..d8effd3c62a 100644 --- a/blog/2016/10/25/0-36-headless-js-the-keyboard-api-and-more.html +++ b/blog/2016/10/25/0-36-headless-js-the-keyboard-api-and-more.html @@ -1,4 +1,4 @@ -0.36: Headless JS, the Keyboard API, & more

0.36: Headless JS, the Keyboard API, & more

Today we are releasing React Native 0.36. Read on to learn more about what's new.

Headless JS #

Headless JS is a way to run tasks in JavaScript while your app is in the background. It can be used, for example, to sync fresh data, handle push notifications, or play music. It is only available on Android, for now.

To get started, define your async task in a dedicated file (e.g. SomeTaskName.js):

module.exports = async (taskData) => { +0.36: Headless JS, the Keyboard API, & more
React Native Blog
Stay up-to-date with the latest React Native news and events.

0.36: Headless JS, the Keyboard API, & more

Today we are releasing React Native 0.36. Read on to learn more about what's new.

Headless JS #

Headless JS is a way to run tasks in JavaScript while your app is in the background. It can be used, for example, to sync fresh data, handle push notifications, or play music. It is only available on Android, for now.

To get started, define your async task in a dedicated file (e.g. SomeTaskName.js):

module.exports = async (taskData) => { // Perform your task here. }

Next, register your task in on AppRegistry:

AppRegistry.registerHeadlessTask('SomeTaskName', () => require('SomeTaskName'));

Using Headless JS does require some native Java code to be written in order to allow you to start up the service when needed. Take a look at our new Headless JS docs to learn more!

The Keyboard API #

Working with the on-screen keyboard is now easier with Keyboard. You can now listen for native keyboard events and react to them. For example, to dismiss the active keyboard, simply call Keyboard.dismiss():

import { Keyboard } from 'react-native' @@ -11,7 +11,7 @@ Animated.spr }).start();

b will then follow a's spring animation and produce the value of 1 / a.

The basic usage is like this:

<Animated.View style={{transform: [{scale: a}]}}> <Animated.Image style={{transform: [{scale: b}]}} /> <Animated.View>

In this example, the inner image won't get stretched at all because the parent's scaling gets cancelled out. If you'd like to learn more, check out the Animations guide.

Dark Status Bars #

A new barStyle value has been added to StatusBar: dark-content. With this addition, you can now use barStyle on both iOS and Android. The behavior will now be the following:

  • default: Use the platform default (light on iOS, dark on Android).
  • light-content: Use a light status bar with black text and icons.
  • dark-content: Use a dark status bar with white text and icons.

...and more #

The above is just a sample of what has changed in 0.36. Check out the release notes on GitHub to see the full list of new features, bug fixes, and breaking changes.

You can upgrade to 0.36 by running the following commands in a terminal:

$ npm install --save react-native@0.36 -$ react-native upgrade
\ No newline at end of file + \ No newline at end of file diff --git a/blog/feed.xml b/blog/feed.xml index b2fa799c5f0..b9cd504f838 100644 --- a/blog/feed.xml +++ b/blog/feed.xml @@ -14,7 +14,7 @@ 2016-10-25T00:00:00Z - + Héctor Ramos https://twitter.com/hectorramos @@ -26,7 +26,7 @@ 2016-09-08T00:00:00Z - + Héctor Ramos https://twitter.com/hectorramos @@ -50,7 +50,7 @@ 2016-08-12T00:00:00Z - + Héctor Ramos https://twitter.com/hectorramos diff --git a/blog/index.html b/blog/index.html index 4741552c3a6..513bdbce122 100644 --- a/blog/index.html +++ b/blog/index.html @@ -1,4 +1,4 @@ -React Native Blog




Toward Better Documentation

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 Blog
Stay up-to-date with the latest React Native news and events.

San Francisco Meetup Recap

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.

Toward Better Documentation

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.

Introducing Hot Reloading

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.

\ No newline at end of file + \ No newline at end of file diff --git a/blog/page2/index.html b/blog/page2/index.html deleted file mode 100644 index 544a536e528..00000000000 --- a/blog/page2/index.html +++ /dev/null @@ -1,19 +0,0 @@ -React Native Blog
\ No newline at end of file diff --git a/releases/next/css/react-native.css b/releases/next/css/react-native.css index 4fdc9138d24..88dc7c107f6 100644 --- a/releases/next/css/react-native.css +++ b/releases/next/css/react-native.css @@ -625,10 +625,6 @@ h1:hover .hash-link, h2:hover .hash-link, h3:hover .hash-link, h4:hover .hash-li } } -.nav-blog li { - margin-bottom: 5px; -} - .home-section { margin: 50px 0; } @@ -749,11 +745,11 @@ h1:hover .hash-link, h2:hover .hash-link, h3:hover .hash-link, h4:hover .hash-li } .docs-prev { - float: left; + float: right; } .docs-next { - float: right; + float: left; } section.black content { @@ -827,7 +823,9 @@ h2 { } .docs-prevnext { - padding-top: 20px; + min-width: 320px; + max-width: 640px; + margin: 0 auto 40px; padding-bottom: 20px; } @@ -1656,7 +1654,7 @@ input#algolia-doc-search:focus { /** Blog **/ .entry-header { - margin: 40px 0 0 0; + margin: 0; } .entry-header h1 { @@ -1667,16 +1665,17 @@ input#algolia-doc-search:focus { .entry-header h4 { margin: 0 0 10px; - font-size: 12px; line-height: 16px; + font-size: 14px; } .entry-header .author { color: #5A6b77; + font-weight: 700; } .entry-header .date { - color: #66637A; + color: rgba(102,99,122,.5); } .entry-readmore { @@ -1689,6 +1688,20 @@ input#algolia-doc-search:focus { text-align: left; } +.entry-excerpt { + min-width: 320px; + max-width: 640px; + margin: 0 auto 40px; + padding-bottom: 40px; + border-bottom: 1px solid #EDEDED; +} + +.entry-body { + min-width: 320px; + max-width: 640px; + margin: 0 auto; +} + .small-title { font-size: 10px; color: #66637A; @@ -1819,6 +1832,11 @@ article li { } } +#mc_embed_signup { + clear:left; + width:100%; +} + /** Help **/ .helpSection h2 { font-size: 24px; @@ -1896,7 +1914,7 @@ footer .sitemap { display: flex; justify-content: space-between; max-width: 1080px; - margin: 0 auto 3em; + margin: 0 auto 1em; } footer .sitemap div { flex: 1; @@ -1914,10 +1932,18 @@ footer .sitemap .nav-home:hover, footer .sitemap .nav-home:focus { opacity: 1.0; } -@media screen and (max-width: 740px) { +@media screen and (max-width: 768px) { footer .sitemap { display: none; } + + footer .newsletter { + display: none; + } + + #mc_embed_signup { + display: none; + } } footer .sitemap a { @@ -1964,3 +1990,15 @@ footer .copyright { color: rgba(255, 255, 255, 0.4); text-align: center; } + +footer .newsletter { + display: flex; + justify-content: space-between; + max-width: 640px; + margin: 0 auto 1em; +} + +footer .newsletter h5 { + color: #05A5D1; + margin: 0 0 10px; +} diff --git a/releases/next/docs/accessibility.html b/releases/next/docs/accessibility.html index aceca135da4..4a2d8e3feb7 100644 --- a/releases/next/docs/accessibility.html +++ b/releases/next/docs/accessibility.html @@ -1,4 +1,4 @@ -Accessibility

Accessibility #

Native App Accessibility (iOS and Android) #

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.

Making Apps Accessible #

Accessibility properties #

accessible (iOS, Android) #

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}’.

<View accessible={true}> +Accessibility

Accessibility #

Native App Accessibility (iOS and Android) #

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.

Making Apps Accessible #

Accessibility properties #

accessible (iOS, Android) #

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}’.

<View accessible={true}> <Text>text one</Text> <Text>text two</Text> </View>

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.

accessibilityLabel (iOS, Android) #

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:

<TouchableOpacity accessible={true} accessibilityLabel={'Tap me!'} onPress={this._onPress}> @@ -38,7 +38,7 @@ <CustomRadioButton accessibleComponentType={this.state.radioButton} - onPress={this._onPress}/>

In the above example we've created a custom radio button that now behaves like a native one. More specifically, TalkBack now correctly announces changes to the radio button selection.

Testing VoiceOver Support (iOS) #

To enable VoiceOver, go to the Settings app on your iOS device. Tap General, then Accessibility. There you will find many tools that people use to use to make their devices more usable, such as bolder text, increased contrast, and VoiceOver.

To enable VoiceOver, tap on VoiceOver under "Vision" and toggle the switch that appears at the top.

At the very bottom of the Accessibility settings, there is an "Accessibility Shortcut". You can use this to toggle VoiceOver by triple clicking the Home button.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/actionsheetios.html b/releases/next/docs/actionsheetios.html index 9081d2cfdd7..a7713cb5768 100644 --- a/releases/next/docs/actionsheetios.html +++ b/releases/next/docs/actionsheetios.html @@ -1,4 +1,4 @@ -ActionSheetIOS

ActionSheetIOS #

Methods #

static showActionSheetWithOptions(options, callback) #

Display an iOS action sheet. The options object must contain one or more +ActionSheetIOS

ActionSheetIOS #

Methods #

static showActionSheetWithOptions(options, callback) #

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 options
  • destructiveButtonIndex (int) - index of destructive button in options
  • title (string) - a title to show above the action sheet
  • message (string) - a message to show below the title

static showShareActionSheetWithOptions(options, failureCallback, successCallback) #

Display 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 share
  • message (string) - a message to share
  • subject (string) - a subject for the message
  • excludedActivityTypes (array) - the activities to exclude from the ActionSheet

NOTE: if url points to a local file, or is a base64-encoded @@ -204,7 +204,7 @@ exports.examples return <ShareScreenshotExample />; } } -];

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/activityindicator.html b/releases/next/docs/activityindicator.html index 54a19283029..9ef9aad3109 100644 --- a/releases/next/docs/activityindicator.html +++ b/releases/next/docs/activityindicator.html @@ -1,4 +1,4 @@ -ActivityIndicator

ActivityIndicator #

Displays a circular loading indicator.

Props #

animating bool #

Whether to show the indicator (true, the default) or hide it (false).

color color #

The foreground color of the spinner (default is gray).

size enum('small', 'large'), number #

Size of the indicator (default is 'small'). +ActivityIndicator

ActivityIndicator #

Displays a circular loading indicator.

Props #

animating bool #

Whether to show the indicator (true, the default) or hide it (false).

color color #

The foreground color of the spinner (default is gray).

size enum('small', 'large'), number #

Size of the indicator (default is 'small'). Passing a number to the size prop is only supported on Android.

ioshidesWhenStopped 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
'use strict'; import React, { Component } from 'react'; @@ -180,7 +180,7 @@ const styles = StyleSheet: 'space-around', padding: 8, }, -});
\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/adsupportios.html b/releases/next/docs/adsupportios.html index c2bd22ef369..0c8bf5717b3 100644 --- a/releases/next/docs/adsupportios.html +++ b/releases/next/docs/adsupportios.html @@ -1,4 +1,4 @@ -AdSupportIOS

AdSupportIOS #

Methods #

static getAdvertisingId(onSuccess, onFailure) #

static getAdvertisingTrackingEnabled(onSuccess, onFailure) #

You can edit the content above on GitHub and send us a pull request!

Examples #

Edit on GitHub
'use strict'; +AdSupportIOS

AdSupportIOS #

Methods #

static getAdvertisingId(onSuccess, onFailure) #

static getAdvertisingTrackingEnabled(onSuccess, onFailure) #

You can edit the content above on GitHub and send us a pull request!

Examples #

Edit on GitHub
'use strict'; var React = require('react'); var ReactNative = require('react-native'); @@ -84,7 +84,7 @@ class AdSupportIOSExample extends : { fontWeight: '500', }, -});
\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/alert.html b/releases/next/docs/alert.html index e204fb45de6..8f6e176312f 100644 --- a/releases/next/docs/alert.html +++ b/releases/next/docs/alert.html @@ -1,4 +1,4 @@ -Alert

Alert #

Launches an alert dialog with the specified title and message.

Optionally provide a list of buttons. Tapping any button will fire the +Alert

Alert #

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, @@ -148,7 +148,7 @@ class AlertExample extends .exports = { AlertExample, SimpleAlertExampleBlock, -};

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/alertios.html b/releases/next/docs/alertios.html index 2a8a54b3f11..3c4956702f8 100644 --- a/releases/next/docs/alertios.html +++ b/releases/next/docs/alertios.html @@ -1,4 +1,4 @@ -AlertIOS

AlertIOS #

AlertIOS provides functionality to create an iOS alert dialog with a +AlertIOS

AlertIOS #

AlertIOS provides functionality to create an iOS alert dialog with a message or create a prompt for user input.

Creating an iOS alert:

AlertIOS.alert( 'Sync Complete', 'All your data are belong to us.' @@ -203,7 +203,7 @@ class PromptOptions extends : '#eeeeee', padding: 10, }, -});
\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/android-building-from-source.html b/releases/next/docs/android-building-from-source.html index 73ce2759e70..77418938b28 100644 --- a/releases/next/docs/android-building-from-source.html +++ b/releases/next/docs/android-building-from-source.html @@ -1,4 +1,4 @@ -Building React Native from source

Building React Native from source #

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.

Prerequisites #

Assuming you have the Android SDK installed, run android to open the Android SDK Manager.

Make sure you have the following installed:

  1. Android SDK version 23 (compileSdkVersion in build.gradle)
  2. SDK build tools version 23.0.1 (buildToolsVersion in build.gradle)
  3. Local Maven repository for Support Libraries (formerly Android Support Repository) >= 17 (for Android Support Library)
  4. Android NDK (download links and installation instructions below)

Point Gradle to your Android SDK: #

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: .bash_profile or .bashrc
  • zsh: .zprofile or .zshrc
  • ksh: .profile or $ENV

Example:

export ANDROID_SDK=/Users/your_unix_name/android-sdk-macosx +Building React Native from source

Building React Native from source #

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.

Prerequisites #

Assuming you have the Android SDK installed, run android to open the Android SDK Manager.

Make sure you have the following installed:

  1. Android SDK version 23 (compileSdkVersion in build.gradle)
  2. SDK build tools version 23.0.1 (buildToolsVersion in build.gradle)
  3. Local Maven repository for Support Libraries (formerly Android Support Repository) >= 17 (for Android Support Library)
  4. Android NDK (download links and installation instructions below)

Point Gradle to your Android SDK: #

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: .bash_profile or .bashrc
  • zsh: .zprofile or .zshrc
  • ksh: .profile or $ENV

Example:

export ANDROID_SDK=/Users/your_unix_name/android-sdk-macosx export ANDROID_NDK=/Users/your_unix_name/android-ndk/android-ndk-r10e

Step 2: Create a local.properties file in the android directory of your react-native app with the following contents:

Example:

sdk.dir=/Users/your_unix_name/android-sdk-macosx ndk.dir=/Users/your_unix_name/android-ndk/android-ndk-r10e

Download links for Android NDK #

  1. Mac OS (64-bit) - http://dl.google.com/android/repository/android-ndk-r10e-darwin-x86_64.zip
  2. Linux (64-bit) - http://dl.google.com/android/repository/android-ndk-r10e-linux-x86_64.zip
  3. Windows (64-bit) - http://dl.google.com/android/repository/android-ndk-r10e-windows-x86_64.zip
  4. Windows (32-bit) - http://dl.google.com/android/repository/android-ndk-r10e-windows-x86.zip

You can find further instructions on the official page.

Building the source #

1. Installing the fork #

First, you need to install react-native from your fork. For example, to install the master branch from the official repo, run the following:

npm install --save github:facebook/react-native#master

Alternatively, you can clone the repo to your node_modules directory and run npm install inside the cloned repo.

2. Adding gradle dependencies #

Add gradle-download-task as dependency in android/build.gradle:

... dependencies { @@ -28,7 +28,7 @@ dependencies { rootProject.allprojects { buildDir = "/path/to/build/directory/${rootProject.name}/${project.name}" } -}

Testing #

If you made changes to React Native and submit a pull request, all tests will run on your pull request automatically. To run the tests locally, see Testing.

Troubleshooting #

Gradle build fails in ndk-build. See the section about local.properties file above.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/android-ui-performance.html b/releases/next/docs/android-ui-performance.html index ef334101752..2b046f06372 100644 --- a/releases/next/docs/android-ui-performance.html +++ b/releases/next/docs/android-ui-performance.html @@ -1,4 +1,4 @@ -Profiling Android UI Performance

Profiling Android UI Performance #

We try our best to deliver buttery-smooth UI performance by default, but sometimes that just isn't possible. Remember, Android supports 10k+ different phones and is generalized to support software rendering: the framework architecture and need to generalize across many hardware targets unfortunately means you get less for free relative to iOS. But sometimes, there are things you can improve (and many times it's not native code's fault at all!).

The first step for debugging this jank is to answer the fundamental question of where your time is being spent during each 16ms frame. For that, we'll be using a standard Android profiling tool called systrace. But first...

Make sure that JS dev mode is OFF!

You should see __DEV__ === false, development-level warning are OFF, performance optimizations are ON in your application logs (which you can view using adb logcat)

Profiling with Systrace #

Systrace is a standard Android marker-based profiling tool (and is installed when you install the Android platform-tools package). Profiled code blocks are surrounded by markers start/end markers which are then visualized in a colorful chart format. Both the Android SDK and React Native framework provide standard markers that you can visualize.

Collecting a trace #

NOTE:

Systrace support was added in react-native v0.15. You will need to build with that version to collect a trace.

First, connect a device that exhibits the stuttering you want to investigate to your computer via USB and get it to the point right before the navigation/animation you want to profile. Run systrace as follows

$ <path_to_android_sdk>/platform-tools/systrace/systrace.py --time=10 -o trace.html sched gfx view -a <your_package_name>

A quick breakdown of this command:

  • time is the length of time the trace will be collected in seconds
  • sched, gfx, and view are the android SDK tags (collections of markers) we care about: sched gives you information about what's running on each core of your phone, gfx gives you graphics info such as frame boundaries, and view gives you information about measure, layout, and draw passes
  • -a <your_package_name> enables app-specific markers, specifically the ones built into the React Native framework. your_package_name can be found in the AndroidManifest.xml of your app and looks like com.example.app

Once the trace starts collecting, perform the animation or interaction you care about. At the end of the trace, systrace will give you a link to the trace which you can open in your browser.

Reading the trace #

After opening the trace in your browser (preferably Chrome), you should see something like this:

Example

If your trace .html file isn't opening correctly, check your browser console for the following:

ObjectObserveError

Since Object.observe was deprecated in recent browsers, you may have to open the file from the Google Chrome Tracing tool. You can do so by:

  • Opening tab in chrome chrome://tracing
  • Selecting load
  • Selecting the html file generated from the previous command.

HINT: Use the WASD keys to strafe and zoom

Enable VSync highlighting #

The first thing you should do is highlight the 16ms frame boundaries if you haven't already done that. Check this checkbox at the top right of the screen:

Enable VSync Highlighting

You should see zebra stripes as in the screenshot above. If you don't, try profiling on a different device: Samsung has been known to have issues displaying vsyncs while the Nexus series is generally pretty reliable.

Find your process #

Scroll until you see (part of) the name of your package. In this case, I was profiling com.facebook.adsmanager, which shows up as book.adsmanager because of silly thread name limits in the kernel.

On the left side, you'll see a set of threads which correspond to the timeline rows on the right. There are three/four threads we care about for our purposes: the UI thread (which has your package name or the name UI Thread), mqt_js and mqt_native_modules. If you're running on Android 5+, we also care about the Render Thread.

UI Thread #

This is where standard android measure/layout/draw happens. The thread name on the right will be your package name (in my case book.adsmanager) or UI Thread. The events that you see on this thread should look something like this and have to do with Choreographer, traversals, and DispatchUI:

UI Thread Example

JS Thread #

This is where JS is executed. The thread name will be either mqt_js or <...> depending on how cooperative the kernel on your device is being. To identify it if it doesn't have a name, look for things like JSCall, Bridge.executeJSCall, etc:

JS Thread Example

Native Modules Thread #

This is where native module calls (e.g. the UIManager) are executed. The thread name will be either mqt_native_modules or <...>. To identify it in the latter case, look for things like NativeCall, callJavaModuleMethod, and onBatchComplete:

Native Modules Thread Example

Bonus: Render Thread #

If you're using Android L (5.0) and up, you will also have a render thread in your application. This thread generates the actual OpenGL commands used to draw your UI. The thread name will be either RenderThread or <...>. To identify it in the latter case, look for things like DrawFrame and queueBuffer:

Render Thread Example

Identifying a culprit #

A smooth animation should look something like the following:

Smooth Animation

Each change in color is a frame -- remember that in order to display a frame, all our UI work needs to be done by the end of that 16ms period. Notice that no thread is working close to the frame boundary. An application rendering like this is rendering at 60FPS.

If you noticed chop, however, you might see something like this:

Choppy Animation from JS

Notice that the JS thread is executing basically all the time, and across frame boundaries! This app is not rendering at 60FPS. In this case, the problem lies in JS.

You might also see something like this:

Choppy Animation from UI

In this case, the UI and render threads are the ones that have work crossing frame boundaries. The UI that we're trying to render on each frame is requiring too much work to be done. In this case, the problem lies in the native views being rendered.

At this point, you'll have some very helpful information to inform your next steps.

JS Issues #

If you identified a JS problem, look for clues in the specific JS that you're executing. In the scenario above, we see RCTEventEmitter being called multiple times per frame. Here's a zoom-in of the JS thread from the trace above:

Too much JS

This doesn't seem right. Why is it being called so often? Are they actually different events? The answers to these questions will probably depend on your product code. And many times, you'll want to look into shouldComponentUpdate.

TODO: Add more tools for profiling JS

Native UI Issues #

If you identified a native UI problem, there are usually two scenarios:

  1. the UI you're trying to draw each frame involves to much work on the GPU, or
  2. You're constructing new UI during the animation/interaction (e.g. loading in new content during a scroll).

Too much GPU work #

In the first scenario, you'll see a trace that has the UI thread and/or Render Thread looking like this:

Overloaded GPU

Notice the long amount of time spent in DrawFrame that crosses frame boundaries. This is time spent waiting for the GPU to drain its command buffer from the previous frame.

To mitigate this, you should:

  • investigate using renderToHardwareTextureAndroid for complex, static content that is being animated/transformed (e.g. the Navigator slide/alpha animations)
  • make sure that you are not using needsOffscreenAlphaCompositing, which is disabled by default, as it greatly increases the per-frame load on the GPU in most cases.

If these don't help and you want to dig deeper into what the GPU is actually doing, you can check out Tracer for OpenGL ES.

Creating new views on the UI thread #

In the second scenario, you'll see something more like this:

Creating Views

Notice that first the JS thread thinks for a bit, then you see some work done on the native modules thread, followed by an expensive traversal on the UI thread.

There isn't an easy way to mitigate this unless you're able to postpone creating new UI until after the interaction, or you are able to simplify the UI you're creating. The react native team is working on a infrastructure level solution for this that will allow new UI to be created and configured off the main thread, allowing the interaction to continue smoothly.

Still stuck? #

If you are confused or stuck, please post ask on Stack Overflow with the react-native tag. If you are unable to get a response there, or find an issue with a core component, please File a Github issue.

You can edit the content above on GitHub and send us a pull request!

Profiling Android UI Performance #

We try our best to deliver buttery-smooth UI performance by default, but sometimes that just isn't possible. Remember, Android supports 10k+ different phones and is generalized to support software rendering: the framework architecture and need to generalize across many hardware targets unfortunately means you get less for free relative to iOS. But sometimes, there are things you can improve (and many times it's not native code's fault at all!).

The first step for debugging this jank is to answer the fundamental question of where your time is being spent during each 16ms frame. For that, we'll be using a standard Android profiling tool called systrace. But first...

Make sure that JS dev mode is OFF!

You should see __DEV__ === false, development-level warning are OFF, performance optimizations are ON in your application logs (which you can view using adb logcat)

Profiling with Systrace #

Systrace is a standard Android marker-based profiling tool (and is installed when you install the Android platform-tools package). Profiled code blocks are surrounded by markers start/end markers which are then visualized in a colorful chart format. Both the Android SDK and React Native framework provide standard markers that you can visualize.

Collecting a trace #

NOTE:

Systrace support was added in react-native v0.15. You will need to build with that version to collect a trace.

First, connect a device that exhibits the stuttering you want to investigate to your computer via USB and get it to the point right before the navigation/animation you want to profile. Run systrace as follows

$ <path_to_android_sdk>/platform-tools/systrace/systrace.py --time=10 -o trace.html sched gfx view -a <your_package_name>

A quick breakdown of this command:

  • time is the length of time the trace will be collected in seconds
  • sched, gfx, and view are the android SDK tags (collections of markers) we care about: sched gives you information about what's running on each core of your phone, gfx gives you graphics info such as frame boundaries, and view gives you information about measure, layout, and draw passes
  • -a <your_package_name> enables app-specific markers, specifically the ones built into the React Native framework. your_package_name can be found in the AndroidManifest.xml of your app and looks like com.example.app

Once the trace starts collecting, perform the animation or interaction you care about. At the end of the trace, systrace will give you a link to the trace which you can open in your browser.

Reading the trace #

After opening the trace in your browser (preferably Chrome), you should see something like this:

Example

If your trace .html file isn't opening correctly, check your browser console for the following:

ObjectObserveError

Since Object.observe was deprecated in recent browsers, you may have to open the file from the Google Chrome Tracing tool. You can do so by:

  • Opening tab in chrome chrome://tracing
  • Selecting load
  • Selecting the html file generated from the previous command.

HINT: Use the WASD keys to strafe and zoom

Enable VSync highlighting #

The first thing you should do is highlight the 16ms frame boundaries if you haven't already done that. Check this checkbox at the top right of the screen:

Enable VSync Highlighting

You should see zebra stripes as in the screenshot above. If you don't, try profiling on a different device: Samsung has been known to have issues displaying vsyncs while the Nexus series is generally pretty reliable.

Find your process #

Scroll until you see (part of) the name of your package. In this case, I was profiling com.facebook.adsmanager, which shows up as book.adsmanager because of silly thread name limits in the kernel.

On the left side, you'll see a set of threads which correspond to the timeline rows on the right. There are three/four threads we care about for our purposes: the UI thread (which has your package name or the name UI Thread), mqt_js and mqt_native_modules. If you're running on Android 5+, we also care about the Render Thread.

UI Thread #

This is where standard android measure/layout/draw happens. The thread name on the right will be your package name (in my case book.adsmanager) or UI Thread. The events that you see on this thread should look something like this and have to do with Choreographer, traversals, and DispatchUI:

UI Thread Example

JS Thread #

This is where JS is executed. The thread name will be either mqt_js or <...> depending on how cooperative the kernel on your device is being. To identify it if it doesn't have a name, look for things like JSCall, Bridge.executeJSCall, etc:

JS Thread Example

Native Modules Thread #

This is where native module calls (e.g. the UIManager) are executed. The thread name will be either mqt_native_modules or <...>. To identify it in the latter case, look for things like NativeCall, callJavaModuleMethod, and onBatchComplete:

Native Modules Thread Example

Bonus: Render Thread #

If you're using Android L (5.0) and up, you will also have a render thread in your application. This thread generates the actual OpenGL commands used to draw your UI. The thread name will be either RenderThread or <...>. To identify it in the latter case, look for things like DrawFrame and queueBuffer:

Render Thread Example

Identifying a culprit #

A smooth animation should look something like the following:

Smooth Animation

Each change in color is a frame -- remember that in order to display a frame, all our UI work needs to be done by the end of that 16ms period. Notice that no thread is working close to the frame boundary. An application rendering like this is rendering at 60FPS.

If you noticed chop, however, you might see something like this:

Choppy Animation from JS

Notice that the JS thread is executing basically all the time, and across frame boundaries! This app is not rendering at 60FPS. In this case, the problem lies in JS.

You might also see something like this:

Choppy Animation from UI

In this case, the UI and render threads are the ones that have work crossing frame boundaries. The UI that we're trying to render on each frame is requiring too much work to be done. In this case, the problem lies in the native views being rendered.

At this point, you'll have some very helpful information to inform your next steps.

JS Issues #

If you identified a JS problem, look for clues in the specific JS that you're executing. In the scenario above, we see RCTEventEmitter being called multiple times per frame. Here's a zoom-in of the JS thread from the trace above:

Too much JS

This doesn't seem right. Why is it being called so often? Are they actually different events? The answers to these questions will probably depend on your product code. And many times, you'll want to look into shouldComponentUpdate.

TODO: Add more tools for profiling JS

Native UI Issues #

If you identified a native UI problem, there are usually two scenarios:

  1. the UI you're trying to draw each frame involves to much work on the GPU, or
  2. You're constructing new UI during the animation/interaction (e.g. loading in new content during a scroll).

Too much GPU work #

In the first scenario, you'll see a trace that has the UI thread and/or Render Thread looking like this:

Overloaded GPU

Notice the long amount of time spent in DrawFrame that crosses frame boundaries. This is time spent waiting for the GPU to drain its command buffer from the previous frame.

To mitigate this, you should:

  • investigate using renderToHardwareTextureAndroid for complex, static content that is being animated/transformed (e.g. the Navigator slide/alpha animations)
  • make sure that you are not using needsOffscreenAlphaCompositing, which is disabled by default, as it greatly increases the per-frame load on the GPU in most cases.

If these don't help and you want to dig deeper into what the GPU is actually doing, you can check out Tracer for OpenGL ES.

Creating new views on the UI thread #

In the second scenario, you'll see something more like this:

Creating Views

Notice that first the JS thread thinks for a bit, then you see some work done on the native modules thread, followed by an expensive traversal on the UI thread.

There isn't an easy way to mitigate this unless you're able to postpone creating new UI until after the interaction, or you are able to simplify the UI you're creating. The react native team is working on a infrastructure level solution for this that will allow new UI to be created and configured off the main thread, allowing the interaction to continue smoothly.

Still stuck? #

If you are confused or stuck, please post ask on Stack Overflow with the react-native tag. If you are unable to get a response there, or find an issue with a core component, please File a Github issue.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/animated.html b/releases/next/docs/animated.html index 6a0e66b73ac..d2e4ec13d43 100644 --- a/releases/next/docs/animated.html +++ b/releases/next/docs/animated.html @@ -1,4 +1,4 @@ -Animated

Animated #

Animations are an important part of modern UX, and the Animated +Animated

Animated #

Animations are an important part of modern UX, and the Animated library is designed to make them fluid, powerful, and easy to build and maintain.

The simplest workflow is to create an Animated.Value, hook it up to one or more style attributes of an animated component, and then drive updates either @@ -350,7 +350,7 @@ exports.examples : 10, alignItems: 'center', }, -});

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/animations.html b/releases/next/docs/animations.html index a9b8e4e3a59..5639b1014ee 100644 --- a/releases/next/docs/animations.html +++ b/releases/next/docs/animations.html @@ -1,4 +1,4 @@ -Animations

Animations #

Fluid, meaningful animations are essential to the mobile user experience. Like +Animations

Animations #

Fluid, meaningful animations are essential to the mobile user experience. Like everything in React Native, Animation APIs for React Native are currently under development, but have started to coalesce around two complementary systems: LayoutAnimation for animated global layout transactions, and Animated for @@ -378,7 +378,7 @@ make them customizable, React Native exposes a pop: CustomLeftToRightGesture, } });

Run this example

For further information about customizing scene transitions, read the -source.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/appregistry.html b/releases/next/docs/appregistry.html index 6988d684eea..ebb4cba0379 100644 --- a/releases/next/docs/appregistry.html +++ b/releases/next/docs/appregistry.html @@ -1,4 +1,4 @@ -AppRegistry

AppRegistry #

AppRegistry is the JS entry point to running all React Native apps. App +AppRegistry

AppRegistry #

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 @@ -12,7 +12,7 @@ sure the JS execution environment is setup before other modules are the only argument; when the promise is resolved or rejected the native side is notified of this event and it may decide to destroy the JS context.

static startHeadlessTask(taskId, taskKey, data) #

Only called from native code. Starts a headless task.

@param taskId the native id for this task instance to keep track of its execution @param taskKey the key for the task to start -@param data the data to pass to the task

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/appstate.html b/releases/next/docs/appstate.html index 113c8e181d2..a014f29be00 100644 --- a/releases/next/docs/appstate.html +++ b/releases/next/docs/appstate.html @@ -1,4 +1,4 @@ -AppState

AppState #

AppState can tell you if the app is in the foreground or background, +AppState

AppState #

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.

App States #

  • active - The app is running in the foreground
  • background - The app is running in the background. The user is either in another app or on the home screen
  • inactive - This is a state that occurs when transitioning between @@ -117,7 +117,7 @@ exports.examples : 'In the IOS simulator, hit Shift+Command+M to simulate a memory warning.', render(): React.Element<any> { return <AppStateSubscription showMemoryWarnings={true} />; } }, -];
\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/asyncstorage.html b/releases/next/docs/asyncstorage.html index 4195e8baf5d..dd4905d7c53 100644 --- a/releases/next/docs/asyncstorage.html +++ b/releases/next/docs/asyncstorage.html @@ -1,4 +1,4 @@ -AsyncStorage

AsyncStorage #

AsyncStorage is a simple, unencrypted, asynchronous, persistent, key-value storage +AsyncStorage

AsyncStorage #

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 @@ -217,7 +217,7 @@ exports.examples : 'Basics - getItem, setItem, removeItem', render(): React.Element<any> { return <BasicStorageExample />; } }, -];

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/backandroid.html b/releases/next/docs/backandroid.html index 44fd8bec48a..988cc6d5160 100644 --- a/releases/next/docs/backandroid.html +++ b/releases/next/docs/backandroid.html @@ -1,4 +1,4 @@ -BackAndroid

BackAndroid #

Detect hardware back button presses, and programmatically invoke the default back button +BackAndroid

BackAndroid #

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.

Example:

BackAndroid.addEventListener('hardwareBackPress', function() { // this.onMainScreen and this.goBack are just examples, you need to use your own implementation here // Typically you would use the navigator here to go to the last state. @@ -8,7 +8,7 @@ functionality to exit the app if there are no listeners or if none of the listen return true; } return false; -});

Methods #

static exitApp(0) #

static addEventListener(eventName, handler) #

static removeEventListener(eventName, handler) #

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/button.html b/releases/next/docs/button.html index 9706732a161..1ebea7b714a 100644 --- a/releases/next/docs/button.html +++ b/releases/next/docs/button.html @@ -1,4 +1,4 @@ -Button

Button #

A basic button component that should render nicely on any platform. Supports +Button

Button #

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 @@ -97,7 +97,7 @@ exports.examples ); }, }, -];

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/cameraroll.html b/releases/next/docs/cameraroll.html index 35c7495b564..1227e8e1fa2 100644 --- a/releases/next/docs/cameraroll.html +++ b/releases/next/docs/cameraroll.html @@ -1,4 +1,4 @@ -CameraRoll

CameraRoll #

CameraRoll provides access to the local camera roll / gallery. +CameraRoll

CameraRoll #

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.

Methods #

static saveImageWithTag(tag) #

static saveToCameraRoll(tag, type?) #

Saves the photo or video to the camera roll / gallery.

On Android, the tag must be a local image or video URI, such as "file:///sdcard/img.png".

On iOS, the tag can be any image URI (including local, remote asset-library and base64 data URIs) or a local video file URI (remote or data URIs are not supported for saving video at this time).

If the tag has a file extension of .mov or .mp4, it will be inferred as a video. Otherwise @@ -129,7 +129,7 @@ exports.examples : 'Photos', render(): React.Element<any> { return <CameraRollExample />; } } -];

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/clipboard.html b/releases/next/docs/clipboard.html index 657e2581e06..d567b454626 100644 --- a/releases/next/docs/clipboard.html +++ b/releases/next/docs/clipboard.html @@ -1,4 +1,4 @@ -Clipboard

Clipboard #

Clipboard gives you an interface for setting and getting content from Clipboard on both iOS and Android

Methods #

static getString(0) #

Get content of string type, this method returns a Promise, so you can use following code to get clipboard content

async _getContent() { +Clipboard

Clipboard #

Clipboard gives you an interface for setting and getting content from Clipboard on both iOS and Android

Methods #

static getString(0) #

Get content of string type, this method returns a Promise, so you can use following code to get clipboard content

async _getContent() { var content = await Clipboard.getString(); }

static setString(content) #

Set content of string type. You can use following code to set clipboard content

_setContent() { Clipboard.setString('hello world'); @@ -50,7 +50,7 @@ exports.examples return <ClipboardExample/>; } } -];
\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/colors.html b/releases/next/docs/colors.html index fc8344a5811..5717cebc308 100644 --- a/releases/next/docs/colors.html +++ b/releases/next/docs/colors.html @@ -1,4 +1,4 @@ -Colors

Colors #

The following formats are supported:

  • '#f0f' (#rgb)
  • '#f0fc' (#rgba)
  • '#ff00ff' (#rrggbb)
  • '#ff00ff00' (#rrggbbaa)
  • 'rgb(255, 255, 255)'
  • 'rgba(255, 255, 255, 1.0)'
  • 'hsl(360, 100%, 100%)'
  • 'hsla(360, 100%, 100%, 1.0)'
  • 'transparent'
  • 'red'
  • 0xff00ff00 (0xrrggbbaa)

For the named colors, React Native follows the CSS3 specification:

  • aliceblue (#f0f8ff)
  • antiquewhite (#faebd7)
  • aqua (#00ffff)
  • aquamarine (#7fffd4)
  • azure (#f0ffff)
  • beige (#f5f5dc)
  • bisque (#ffe4c4)
  • black (#000000)
  • blanchedalmond (#ffebcd)
  • blue (#0000ff)
  • blueviolet (#8a2be2)
  • brown (#a52a2a)
  • burlywood (#deb887)
  • cadetblue (#5f9ea0)
  • chartreuse (#7fff00)
  • chocolate (#d2691e)
  • coral (#ff7f50)
  • cornflowerblue (#6495ed)
  • cornsilk (#fff8dc)
  • crimson (#dc143c)
  • cyan (#00ffff)
  • darkblue (#00008b)
  • darkcyan (#008b8b)
  • darkgoldenrod (#b8860b)
  • darkgray (#a9a9a9)
  • darkgreen (#006400)
  • darkgrey (#a9a9a9)
  • darkkhaki (#bdb76b)
  • darkmagenta (#8b008b)
  • darkolivegreen (#556b2f)
  • darkorange (#ff8c00)
  • darkorchid (#9932cc)
  • darkred (#8b0000)
  • darksalmon (#e9967a)
  • darkseagreen (#8fbc8f)
  • darkslateblue (#483d8b)
  • darkslategray (#2f4f4f)
  • darkslategrey (#2f4f4f)
  • darkturquoise (#00ced1)
  • darkviolet (#9400d3)
  • deeppink (#ff1493)
  • deepskyblue (#00bfff)
  • dimgray (#696969)
  • dimgrey (#696969)
  • dodgerblue (#1e90ff)
  • firebrick (#b22222)
  • floralwhite (#fffaf0)
  • forestgreen (#228b22)
  • fuchsia (#ff00ff)
  • gainsboro (#dcdcdc)
  • ghostwhite (#f8f8ff)
  • gold (#ffd700)
  • goldenrod (#daa520)
  • gray (#808080)
  • green (#008000)
  • greenyellow (#adff2f)
  • grey (#808080)
  • honeydew (#f0fff0)
  • hotpink (#ff69b4)
  • indianred (#cd5c5c)
  • indigo (#4b0082)
  • ivory (#fffff0)
  • khaki (#f0e68c)
  • lavender (#e6e6fa)
  • lavenderblush (#fff0f5)
  • lawngreen (#7cfc00)
  • lemonchiffon (#fffacd)
  • lightblue (#add8e6)
  • lightcoral (#f08080)
  • lightcyan (#e0ffff)
  • lightgoldenrodyellow (#fafad2)
  • lightgray (#d3d3d3)
  • lightgreen (#90ee90)
  • lightgrey (#d3d3d3)
  • lightpink (#ffb6c1)
  • lightsalmon (#ffa07a)
  • lightseagreen (#20b2aa)
  • lightskyblue (#87cefa)
  • lightslategray (#778899)
  • lightslategrey (#778899)
  • lightsteelblue (#b0c4de)
  • lightyellow (#ffffe0)
  • lime (#00ff00)
  • limegreen (#32cd32)
  • linen (#faf0e6)
  • magenta (#ff00ff)
  • maroon (#800000)
  • mediumaquamarine (#66cdaa)
  • mediumblue (#0000cd)
  • mediumorchid (#ba55d3)
  • mediumpurple (#9370db)
  • mediumseagreen (#3cb371)
  • mediumslateblue (#7b68ee)
  • mediumspringgreen (#00fa9a)
  • mediumturquoise (#48d1cc)
  • mediumvioletred (#c71585)
  • midnightblue (#191970)
  • mintcream (#f5fffa)
  • mistyrose (#ffe4e1)
  • moccasin (#ffe4b5)
  • navajowhite (#ffdead)
  • navy (#000080)
  • oldlace (#fdf5e6)
  • olive (#808000)
  • olivedrab (#6b8e23)
  • orange (#ffa500)
  • orangered (#ff4500)
  • orchid (#da70d6)
  • palegoldenrod (#eee8aa)
  • palegreen (#98fb98)
  • paleturquoise (#afeeee)
  • palevioletred (#db7093)
  • papayawhip (#ffefd5)
  • peachpuff (#ffdab9)
  • peru (#cd853f)
  • pink (#ffc0cb)
  • plum (#dda0dd)
  • powderblue (#b0e0e6)
  • purple (#800080)
  • rebeccapurple (#663399)
  • red (#ff0000)
  • rosybrown (#bc8f8f)
  • royalblue (#4169e1)
  • saddlebrown (#8b4513)
  • salmon (#fa8072)
  • sandybrown (#f4a460)
  • seagreen (#2e8b57)
  • seashell (#fff5ee)
  • sienna (#a0522d)
  • silver (#c0c0c0)
  • skyblue (#87ceeb)
  • slateblue (#6a5acd)
  • slategray (#708090)
  • slategrey (#708090)
  • snow (#fffafa)
  • springgreen (#00ff7f)
  • steelblue (#4682b4)
  • tan (#d2b48c)
  • teal (#008080)
  • thistle (#d8bfd8)
  • tomato (#ff6347)
  • turquoise (#40e0d0)
  • violet (#ee82ee)
  • wheat (#f5deb3)
  • white (#ffffff)
  • whitesmoke (#f5f5f5)
  • yellow (#ffff00)
  • yellowgreen (#9acd32)

You can edit the content above on GitHub and send us a pull request!

Colors #

The following formats are supported:

  • '#f0f' (#rgb)
  • '#f0fc' (#rgba)
  • '#ff00ff' (#rrggbb)
  • '#ff00ff00' (#rrggbbaa)
  • 'rgb(255, 255, 255)'
  • 'rgba(255, 255, 255, 1.0)'
  • 'hsl(360, 100%, 100%)'
  • 'hsla(360, 100%, 100%, 1.0)'
  • 'transparent'
  • 'red'
  • 0xff00ff00 (0xrrggbbaa)

For the named colors, React Native follows the CSS3 specification:

  • aliceblue (#f0f8ff)
  • antiquewhite (#faebd7)
  • aqua (#00ffff)
  • aquamarine (#7fffd4)
  • azure (#f0ffff)
  • beige (#f5f5dc)
  • bisque (#ffe4c4)
  • black (#000000)
  • blanchedalmond (#ffebcd)
  • blue (#0000ff)
  • blueviolet (#8a2be2)
  • brown (#a52a2a)
  • burlywood (#deb887)
  • cadetblue (#5f9ea0)
  • chartreuse (#7fff00)
  • chocolate (#d2691e)
  • coral (#ff7f50)
  • cornflowerblue (#6495ed)
  • cornsilk (#fff8dc)
  • crimson (#dc143c)
  • cyan (#00ffff)
  • darkblue (#00008b)
  • darkcyan (#008b8b)
  • darkgoldenrod (#b8860b)
  • darkgray (#a9a9a9)
  • darkgreen (#006400)
  • darkgrey (#a9a9a9)
  • darkkhaki (#bdb76b)
  • darkmagenta (#8b008b)
  • darkolivegreen (#556b2f)
  • darkorange (#ff8c00)
  • darkorchid (#9932cc)
  • darkred (#8b0000)
  • darksalmon (#e9967a)
  • darkseagreen (#8fbc8f)
  • darkslateblue (#483d8b)
  • darkslategray (#2f4f4f)
  • darkslategrey (#2f4f4f)
  • darkturquoise (#00ced1)
  • darkviolet (#9400d3)
  • deeppink (#ff1493)
  • deepskyblue (#00bfff)
  • dimgray (#696969)
  • dimgrey (#696969)
  • dodgerblue (#1e90ff)
  • firebrick (#b22222)
  • floralwhite (#fffaf0)
  • forestgreen (#228b22)
  • fuchsia (#ff00ff)
  • gainsboro (#dcdcdc)
  • ghostwhite (#f8f8ff)
  • gold (#ffd700)
  • goldenrod (#daa520)
  • gray (#808080)
  • green (#008000)
  • greenyellow (#adff2f)
  • grey (#808080)
  • honeydew (#f0fff0)
  • hotpink (#ff69b4)
  • indianred (#cd5c5c)
  • indigo (#4b0082)
  • ivory (#fffff0)
  • khaki (#f0e68c)
  • lavender (#e6e6fa)
  • lavenderblush (#fff0f5)
  • lawngreen (#7cfc00)
  • lemonchiffon (#fffacd)
  • lightblue (#add8e6)
  • lightcoral (#f08080)
  • lightcyan (#e0ffff)
  • lightgoldenrodyellow (#fafad2)
  • lightgray (#d3d3d3)
  • lightgreen (#90ee90)
  • lightgrey (#d3d3d3)
  • lightpink (#ffb6c1)
  • lightsalmon (#ffa07a)
  • lightseagreen (#20b2aa)
  • lightskyblue (#87cefa)
  • lightslategray (#778899)
  • lightslategrey (#778899)
  • lightsteelblue (#b0c4de)
  • lightyellow (#ffffe0)
  • lime (#00ff00)
  • limegreen (#32cd32)
  • linen (#faf0e6)
  • magenta (#ff00ff)
  • maroon (#800000)
  • mediumaquamarine (#66cdaa)
  • mediumblue (#0000cd)
  • mediumorchid (#ba55d3)
  • mediumpurple (#9370db)
  • mediumseagreen (#3cb371)
  • mediumslateblue (#7b68ee)
  • mediumspringgreen (#00fa9a)
  • mediumturquoise (#48d1cc)
  • mediumvioletred (#c71585)
  • midnightblue (#191970)
  • mintcream (#f5fffa)
  • mistyrose (#ffe4e1)
  • moccasin (#ffe4b5)
  • navajowhite (#ffdead)
  • navy (#000080)
  • oldlace (#fdf5e6)
  • olive (#808000)
  • olivedrab (#6b8e23)
  • orange (#ffa500)
  • orangered (#ff4500)
  • orchid (#da70d6)
  • palegoldenrod (#eee8aa)
  • palegreen (#98fb98)
  • paleturquoise (#afeeee)
  • palevioletred (#db7093)
  • papayawhip (#ffefd5)
  • peachpuff (#ffdab9)
  • peru (#cd853f)
  • pink (#ffc0cb)
  • plum (#dda0dd)
  • powderblue (#b0e0e6)
  • purple (#800080)
  • rebeccapurple (#663399)
  • red (#ff0000)
  • rosybrown (#bc8f8f)
  • royalblue (#4169e1)
  • saddlebrown (#8b4513)
  • salmon (#fa8072)
  • sandybrown (#f4a460)
  • seagreen (#2e8b57)
  • seashell (#fff5ee)
  • sienna (#a0522d)
  • silver (#c0c0c0)
  • skyblue (#87ceeb)
  • slateblue (#6a5acd)
  • slategray (#708090)
  • slategrey (#708090)
  • snow (#fffafa)
  • springgreen (#00ff7f)
  • steelblue (#4682b4)
  • tan (#d2b48c)
  • teal (#008080)
  • thistle (#d8bfd8)
  • tomato (#ff6347)
  • turquoise (#40e0d0)
  • violet (#ee82ee)
  • wheat (#f5deb3)
  • white (#ffffff)
  • whitesmoke (#f5f5f5)
  • yellow (#ffff00)
  • yellowgreen (#9acd32)

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/communication-ios.html b/releases/next/docs/communication-ios.html index 90360a068a1..b5f4b7d8806 100644 --- a/releases/next/docs/communication-ios.html +++ b/releases/next/docs/communication-ios.html @@ -1,4 +1,4 @@ -Communication between native and React Native

Communication between native and React Native #

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.

Introduction #

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 own internal state. We do this with properties: data is passed from a parent to its children in a top-down manner. If we have an ancestor component that rely on the state of its descendant, the recommended solution would be to pass down a callback that would 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 #

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.

Passing properties from native to React 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.

NSArray *imageList = @[@"http://foo.com/bar1.png", +Communication between native and React Native

Communication between native and React Native #

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.

Introduction #

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 own internal state. We do this with properties: data is passed from a parent to its children in a top-down manner. If we have an ancestor component that rely on the state of its descendant, the recommended solution would be to pass down a callback that would 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 #

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.

Passing properties from native to React 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.

NSArray *imageList = @[@"http://foo.com/bar1.png", @"http://foo.com/bar2.png"]; NSDictionary *props = @{@"images" : imageList}; @@ -74,7 +74,7 @@ Making a dimension flexible in both JS and native leads to undefined behavior. F newFrame.size = rootView.intrinsicSize; rootView.frame = newFrame; -}

In the example we have a FlexibleSizeExampleView view that holds a root view. We create the root view, initialize it and set the delegate. The delegate will handle size updates. Then, we set the root view's size flexibility to RCTRootViewSizeFlexibilityHeight, which means that rootViewDidChangeIntrinsicSize: method will be called every time the React Native content changes its height. Finally, we set the root view's width and position. Note that we set there height as well, but it has no effect as we made the height RN-dependent.

You can checkout full source code of the example here.

It's fine to change root view's size flexibility mode dynamically. Changing flexibility mode of a root view will schedule a layout recalculation and the delegate rootViewDidChangeIntrinsicSize: method will be called once the content size is known.

Note: React Native layout calculation is performed on a special thread, while native UI view updates are done on the main thread. This may cause temporary UI inconsistencies between native and React Native. This is a known problem and our team is working on synchronizing UI updates coming from different sources.

Note: React Native does not perform any layout calculations until the root view becomes a subview of some other views. If you want to hide React Native view until its dimensions are known, add the root view as a subview and make it initially hidden (use UIView's hidden property). Then change its visibility in the delegate method.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/datepickerandroid.html b/releases/next/docs/datepickerandroid.html index e271da42f0c..9551ac3de3e 100644 --- a/releases/next/docs/datepickerandroid.html +++ b/releases/next/docs/datepickerandroid.html @@ -1,4 +1,4 @@ -DatePickerAndroid

DatePickerAndroid #

Opens the standard Android date picker dialog.

Example #

try { +DatePickerAndroid

DatePickerAndroid #

Opens the standard Android date picker dialog.

Example #

try { const {action, year, month, day} = await DatePickerAndroid.open({ // Use `new Date()` for current date. // May 25 2020. Month 0 is January. @@ -115,7 +115,7 @@ class DatePickerAndroidExample extends }, }); -module.exports = DatePickerAndroidExample;
\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/datepickerios.html b/releases/next/docs/datepickerios.html index d7f90b50c23..16a866075ae 100644 --- a/releases/next/docs/datepickerios.html +++ b/releases/next/docs/datepickerios.html @@ -1,4 +1,4 @@ -DatePickerIOS

DatePickerIOS #

Use DatePickerIOS to render a date/time picker (selector) on iOS. This is +DatePickerIOS

DatePickerIOS #

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 @@ -155,7 +155,7 @@ exports.examples : '500', fontSize: 14, }, -});

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/debugging.html b/releases/next/docs/debugging.html index dfb9eeb0369..913371b8fa1 100644 --- a/releases/next/docs/debugging.html +++ b/releases/next/docs/debugging.html @@ -1,4 +1,4 @@ -Debugging

Debugging #

Accessing the In-App Developer Menu #

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.

Reloading JavaScript #

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⌘ + R keyboard 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.

Automatic reloading #

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:

  • You have added new resources to your native app's bundle, such as an image in Images.xcassets on iOS or the res/drawable folder on Android.
  • You have modified native code (Objective-C/Swift on iOS or Java/C++ on Android).

In-app Errors and Warnings #

Errors and warnings are displayed inside your app in development builds.

Errors #

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 #

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: ...'];

RedBoxes and YellowBoxes are automatically disabled in release (production) builds.

Accessing console logs #

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:

$ react-native log-ios +Debugging

Debugging #

Accessing the In-App Developer Menu #

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.

Reloading JavaScript #

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⌘ + R keyboard 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.

Automatic reloading #

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:

  • You have added new resources to your native app's bundle, such as an image in Images.xcassets on iOS or the res/drawable folder on Android.
  • You have modified native code (Objective-C/Swift on iOS or Java/C++ on Android).

In-app Errors and Warnings #

Errors and warnings are displayed inside your app in development builds.

Errors #

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 #

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: ...'];

RedBoxes and YellowBoxes are automatically disabled in release (production) builds.

Accessing console logs #

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:

$ react-native log-ios $ react-native log-android

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.

Chrome Developer Tools #

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.

Debugging on a device with Chrome Developer Tools #

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.

Debugging using a custom JavaScript debugger #

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.

Debugging with Stetho on Android #

  1. In android/app/build.gradle, add these lines in the dependencies section:

    compile 'com.facebook.stetho:stetho:1.3.1' compile 'com.facebook.stetho:stetho-okhttp3:1.3.1'
  2. In android/app/src/main/java/com/{yourAppName}/MainApplication.java, add the following imports:

    import com.facebook.react.modules.network.ReactCookieJarContainer; import com.facebook.stetho.Stetho; @@ -16,7 +16,7 @@ import java.util.addNetworkInterceptor(new StethoInterceptor()) .build(); OkHttpClientProvider.replaceOkHttpClient(client); -}
  3. Run react-native run-android

  4. In a new chrome tab, open : chrome://inspect, click on 'Inspect device' (the one followed by "Powered by Stetho")

Debugging native code #

When working with native code (e.g. when writing native modules) you can launch the app from Android Studio or Xcode and take advantage of the debugging features (setup breakpoints, etc.) as you would in case of building a standard native app.

Performance Monitor #

You can enable a performance overlay to help you debug performance problems by selecting "Perf Monitor" in the Developer Menu.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/dimensions.html b/releases/next/docs/dimensions.html index 4ea208e2dab..4e51888c860 100644 --- a/releases/next/docs/dimensions.html +++ b/releases/next/docs/dimensions.html @@ -1,11 +1,11 @@ -Dimensions

Dimensions #

Methods #

static set(dims) #

This should only be called from native code by sending the +Dimensions

Dimensions #

Methods #

static set(dims) #

This should only be called from native code by sending the didUpdateDimensions event.

@param {object} dims Simple string-keyed object of dimensions to set

static get(dim) #

Initial dimensions are set before runApplication is called so they should be available before any other require's are run, but may be updated later.

Note: Although dimensions are available immediately, they may change (e.g due to device rotation) so any rendering logic or styles that depend on these constants should try to call this function on every render, rather than caching the value (for example, using inline styles rather than setting a value in a StyleSheet).

Example: var {height, width} = Dimensions.get('window');

@param {string} dim Name of dimension as defined when calling set. -@returns {Object?} Value for the dimension.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/direct-manipulation.html b/releases/next/docs/direct-manipulation.html index 0be287612b6..4e5d8665eec 100644 --- a/releases/next/docs/direct-manipulation.html +++ b/releases/next/docs/direct-manipulation.html @@ -1,4 +1,4 @@ -Direct Manipulation

Direct Manipulation #

It is sometimes necessary to make changes directly to a component +Direct Manipulation

Direct Manipulation #

It is sometimes necessary to make changes directly to a component without using state/props to trigger a re-render of the entire subtree. When using React in the browser for example, you sometimes need to directly modify a DOM node, and the same is true for views in mobile @@ -136,7 +136,7 @@ the jerky animation each 250ms when setState triggers a re-render.< shouldComponentUpdate you can avoid the unnecessary overhead involved in reconciling unchanged component subtrees, to the point where it may be performant enough to -use setState instead of setNativeProps.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/drawerlayoutandroid.html b/releases/next/docs/drawerlayoutandroid.html index 50ce7b448b2..a5d4152d116 100644 --- a/releases/next/docs/drawerlayoutandroid.html +++ b/releases/next/docs/drawerlayoutandroid.html @@ -1,4 +1,4 @@ -DrawerLayoutAndroid

DrawerLayoutAndroid #

React component that wraps the platform DrawerLayout (Android only). The +DrawerLayoutAndroid

DrawerLayoutAndroid #

React component that wraps the platform DrawerLayout (Android only). The Drawer (typically used for navigation) is rendered with renderNavigationView and direct children are the main view (where your content goes). The navigation view is initially not visible on the screen, but can be pulled in from the @@ -37,7 +37,7 @@ from the edge of the window.

renderNavigationView function #

The navigation view that will be rendered to the side of the screen and can be pulled in.

statusBarBackgroundColor color #

Make the drawer take the entire screen and draw the background of the status bar to allow it to open over the status bar. It will only have an -effect on API 21+.

Methods #

openDrawer(0) #

Opens the drawer.

closeDrawer(0) #

Closes the drawer.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/easing.html b/releases/next/docs/easing.html index 72be5c73a7b..438455a73bf 100644 --- a/releases/next/docs/easing.html +++ b/releases/next/docs/easing.html @@ -1,9 +1,9 @@ -Easing

Easing #

This class implements common easing functions. The math is pretty obscure, +Easing

Easing #

This class implements common easing functions. The math is pretty obscure, but this cool website has nice visual illustrations of what they represent: http://xaedes.de/dev/transitions/

Methods #

static step0(n) #

static step1(n) #

static linear(t) #

static ease(t) #

static quad(t) #

static cubic(t) #

static poly(n) #

static sin(t) #

static circle(t) #

static exp(t) #

static elastic(bounciness) #

A simple elastic interaction, similar to a spring. Default bounciness is 1, which overshoots a little bit once. 0 bounciness doesn't overshoot at all, and bounciness of N > 1 will overshoot about N times.

Wolfram Plots:

http://tiny.cc/elastic_b_1 (default bounciness = 1) - http://tiny.cc/elastic_b_3 (bounciness = 3)

static back(s) #

static bounce(t) #

static bezier(x1, y1, x2, y2) #

static in(easing) #

static out(easing) #

Runs an easing function backwards.

static inOut(easing) #

Makes any easing function symmetrical.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/flexbox.html b/releases/next/docs/flexbox.html index 36f58e7f5bd..d44e251a3e0 100644 --- a/releases/next/docs/flexbox.html +++ b/releases/next/docs/flexbox.html @@ -1,4 +1,4 @@ -Layout with Flexbox

Layout with Flexbox #

A component can specify the layout of its children using the flexbox algorithm. Flexbox is designed to provide a consistent layout on different screen sizes.

You will normally use a combination of flexDirection, alignItems, and justifyContent to achieve the right layout.

Flexbox works the same way in React Native as it does in CSS on the web, with a few exceptions. The defaults are different, with flexDirection defaulting to column instead of row, and alignItems defaulting to stretch instead of flex-start, and the flex parameter only supports a single number.

Flex Direction #

Adding flexDirection to a component's style determines the primary axis of its layout. Should the children be organized horizontally (row) or vertically (column)? The default is column.

import React, { Component } from 'react'; +Layout with Flexbox

Layout with Flexbox #

A component can specify the layout of its children using the flexbox algorithm. Flexbox is designed to provide a consistent layout on different screen sizes.

You will normally use a combination of flexDirection, alignItems, and justifyContent to achieve the right layout.

Flexbox works the same way in React Native as it does in CSS on the web, with a few exceptions. The defaults are different, with flexDirection defaulting to column instead of row, and alignItems defaulting to stretch instead of flex-start, and the flex parameter only supports a single number.

Flex Direction #

Adding flexDirection to a component's style determines the primary axis of its layout. Should the children be organized horizontally (row) or vertically (column)? The default is column.

import React, { Component } from 'react'; import { AppRegistry, View } from 'react-native'; class FlexDirectionBasics extends Component { @@ -58,7 +58,7 @@ class AlignItemsBasics extends } }; -AppRegistry.registerComponent('AwesomeProject', () => AlignItemsBasics);

Going Deeper #

We've covered the basics, but there are many other styles you may need for layouts. The full list of props that control layout is documented here.

We're getting close to being able to build a real application. One thing we are still missing is a way to take user input, so let's move on to learn how to handle text input with the TextInput component.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/geolocation.html b/releases/next/docs/geolocation.html index 5fcc1229c44..b330df9f550 100644 --- a/releases/next/docs/geolocation.html +++ b/releases/next/docs/geolocation.html @@ -1,4 +1,4 @@ -Geolocation

Geolocation #

The Geolocation API extends the web spec: +Geolocation

Geolocation #

The Geolocation API extends the web spec: https://developer.mozilla.org/en-US/docs/Web/API/Geolocation

As a browser polyfill, this API is available through the navigator.geolocation global - you do not need to import it.

iOS #

You need to include the NSLocationWhenInUseUsageDescription key in Info.plist to enable geolocation. Geolocation is enabled by default @@ -80,7 +80,7 @@ class GeolocationExample extends : { fontWeight: '500', }, -});

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/gesture-responder-system.html b/releases/next/docs/gesture-responder-system.html index c9c9f50dab5..1078efb6050 100644 --- a/releases/next/docs/gesture-responder-system.html +++ b/releases/next/docs/gesture-responder-system.html @@ -1,4 +1,4 @@ -Gesture Responder System

Gesture Responder System #

Gesture recognition on mobile devices is much more complicated than web. A touch can go through several phases as the app determines what the user's intention is. For example, the app needs to determine if the touch is scrolling, sliding on a widget, or tapping. This can even change during the duration of a touch. There can also be multiple simultaneous touches.

The touch responder system is needed to allow components to negotiate these touch interactions without any additional knowledge about their parent or child components. This system is implemented in ResponderEventPlugin.js, which contains further details and documentation.

Best Practices #

Users can feel huge differences in the usability of web apps vs. native, and this is one of the big causes. Every action should have the following attributes:

  • Feedback/highlighting- show the user what is handling their touch, and what will happen when they release the gesture
  • Cancel-ability- when making an action, the user should be able to abort it mid-touch by dragging their finger away

These features make users more comfortable while using an app, because it allows people to experiment and interact without fear of making mistakes.

TouchableHighlight and Touchable* #

The responder system can be complicated to use. So we have provided an abstract Touchable implementation for things that should be "tappable". This uses the responder system and allows you to easily configure tap interactions declaratively. Use TouchableHighlight anywhere where you would use a button or link on web.

Responder Lifecycle #

A view can become the touch responder by implementing the correct negotiation methods. There are two methods to ask the view if it wants to become responder:

  • View.props.onStartShouldSetResponder: (evt) => true, - Does this view want to become responder on the start of a touch?
  • View.props.onMoveShouldSetResponder: (evt) => true, - Called for every touch move on the View when it is not the responder: does this view want to "claim" touch responsiveness?

If the View returns true and attempts to become the responder, one of the following will happen:

  • View.props.onResponderGrant: (evt) => {} - The View is now responding for touch events. This is the time to highlight and show the user what is happening
  • View.props.onResponderReject: (evt) => {} - Something else is the responder right now and will not release it

If the view is responding, the following handlers can be called:

  • View.props.onResponderMove: (evt) => {} - The user is moving their finger
  • View.props.onResponderRelease: (evt) => {} - Fired at the end of the touch, ie "touchUp"
  • View.props.onResponderTerminationRequest: (evt) => true - Something else wants to become responder. Should this view release the responder? Returning true allows release
  • View.props.onResponderTerminate: (evt) => {} - The responder has been taken from the View. Might be taken by other views after a call to onResponderTerminationRequest, or might be taken by the OS without asking (happens with control center/ notification center on iOS)

evt is a synthetic touch event with the following form:

  • nativeEvent
    • changedTouches - Array of all touch events that have changed since the last event
    • identifier - The ID of the touch
    • locationX - The X position of the touch, relative to the element
    • locationY - The Y position of the touch, relative to the element
    • pageX - The X position of the touch, relative to the root element
    • pageY - The Y position of the touch, relative to the root element
    • target - The node id of the element receiving the touch event
    • timeStamp - A time identifier for the touch, useful for velocity calculation
    • touches - Array of all current touches on the screen

Capture ShouldSet Handlers #

onStartShouldSetResponder and onMoveShouldSetResponder are called with a bubbling pattern, where the deepest node is called first. That means that the deepest component will become responder when multiple Views return true for *ShouldSetResponder handlers. This is desirable in most cases, because it makes sure all controls and buttons are usable.

However, sometimes a parent will want to make sure that it becomes responder. This can be handled by using the capture phase. Before the responder system bubbles up from the deepest component, it will do a capture phase, firing on*ShouldSetResponderCapture. So if a parent View wants to prevent the child from becoming responder on a touch start, it should have a onStartShouldSetResponderCapture handler which returns true.

  • View.props.onStartShouldSetResponderCapture: (evt) => true,
  • View.props.onMoveShouldSetResponderCapture: (evt) => true,

PanResponder #

For higher-level gesture interpretation, check out PanResponder.

You can edit the content above on GitHub and send us a pull request!

Gesture Responder System #

Gesture recognition on mobile devices is much more complicated than web. A touch can go through several phases as the app determines what the user's intention is. For example, the app needs to determine if the touch is scrolling, sliding on a widget, or tapping. This can even change during the duration of a touch. There can also be multiple simultaneous touches.

The touch responder system is needed to allow components to negotiate these touch interactions without any additional knowledge about their parent or child components. This system is implemented in ResponderEventPlugin.js, which contains further details and documentation.

Best Practices #

Users can feel huge differences in the usability of web apps vs. native, and this is one of the big causes. Every action should have the following attributes:

  • Feedback/highlighting- show the user what is handling their touch, and what will happen when they release the gesture
  • Cancel-ability- when making an action, the user should be able to abort it mid-touch by dragging their finger away

These features make users more comfortable while using an app, because it allows people to experiment and interact without fear of making mistakes.

TouchableHighlight and Touchable* #

The responder system can be complicated to use. So we have provided an abstract Touchable implementation for things that should be "tappable". This uses the responder system and allows you to easily configure tap interactions declaratively. Use TouchableHighlight anywhere where you would use a button or link on web.

Responder Lifecycle #

A view can become the touch responder by implementing the correct negotiation methods. There are two methods to ask the view if it wants to become responder:

  • View.props.onStartShouldSetResponder: (evt) => true, - Does this view want to become responder on the start of a touch?
  • View.props.onMoveShouldSetResponder: (evt) => true, - Called for every touch move on the View when it is not the responder: does this view want to "claim" touch responsiveness?

If the View returns true and attempts to become the responder, one of the following will happen:

  • View.props.onResponderGrant: (evt) => {} - The View is now responding for touch events. This is the time to highlight and show the user what is happening
  • View.props.onResponderReject: (evt) => {} - Something else is the responder right now and will not release it

If the view is responding, the following handlers can be called:

  • View.props.onResponderMove: (evt) => {} - The user is moving their finger
  • View.props.onResponderRelease: (evt) => {} - Fired at the end of the touch, ie "touchUp"
  • View.props.onResponderTerminationRequest: (evt) => true - Something else wants to become responder. Should this view release the responder? Returning true allows release
  • View.props.onResponderTerminate: (evt) => {} - The responder has been taken from the View. Might be taken by other views after a call to onResponderTerminationRequest, or might be taken by the OS without asking (happens with control center/ notification center on iOS)

evt is a synthetic touch event with the following form:

  • nativeEvent
    • changedTouches - Array of all touch events that have changed since the last event
    • identifier - The ID of the touch
    • locationX - The X position of the touch, relative to the element
    • locationY - The Y position of the touch, relative to the element
    • pageX - The X position of the touch, relative to the root element
    • pageY - The Y position of the touch, relative to the root element
    • target - The node id of the element receiving the touch event
    • timeStamp - A time identifier for the touch, useful for velocity calculation
    • touches - Array of all current touches on the screen

Capture ShouldSet Handlers #

onStartShouldSetResponder and onMoveShouldSetResponder are called with a bubbling pattern, where the deepest node is called first. That means that the deepest component will become responder when multiple Views return true for *ShouldSetResponder handlers. This is desirable in most cases, because it makes sure all controls and buttons are usable.

However, sometimes a parent will want to make sure that it becomes responder. This can be handled by using the capture phase. Before the responder system bubbles up from the deepest component, it will do a capture phase, firing on*ShouldSetResponderCapture. So if a parent View wants to prevent the child from becoming responder on a touch start, it should have a onStartShouldSetResponderCapture handler which returns true.

  • View.props.onStartShouldSetResponderCapture: (evt) => true,
  • View.props.onMoveShouldSetResponderCapture: (evt) => true,

PanResponder #

For higher-level gesture interpretation, check out PanResponder.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/getting-started.html b/releases/next/docs/getting-started.html index c947a36c3ce..226cd25cdd6 100644 --- a/releases/next/docs/getting-started.html +++ b/releases/next/docs/getting-started.html @@ -1,4 +1,4 @@ -Getting Started

Getting Started #

Welcome to React Native! This page will help you install React Native on +Getting Started

Getting Started #

Welcome to React Native! This page will help you install React Native on your system, so that you can build apps with it right away. If you already have React Native installed, you can skip ahead to the Tutorial.

The instructions are a bit different depending on your development operating system, and whether you want to start developing for iOS or Android. If you @@ -199,7 +199,7 @@ if (!foundHash) { display('platform', isMac ? 'ios' : 'android'); } -

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/handling-text-input.html b/releases/next/docs/handling-text-input.html index 6eec13d41b1..4bf8dd0855b 100644 --- a/releases/next/docs/handling-text-input.html +++ b/releases/next/docs/handling-text-input.html @@ -1,4 +1,4 @@ -Handling Text Input

Handling Text Input #

TextInput is a basic component that allows the user to enter text. It has an onChangeText prop that takes +Handling Text Input

Handling Text Input #

TextInput is a basic component that allows the user to enter text. It has an onChangeText prop that takes a function to be called every time the text changed, and an onSubmitEditing prop that takes a function to be called when the text is submitted.

For example, let's say that as the user types, you're translating their words into a different language. In this new language, every single word is written the same way: 🍕. So the sentence "Hello there Bob" would be translated as "🍕🍕🍕".

import React, { Component } from 'react'; import { AppRegistry, Text, TextInput, View } from 'react-native'; @@ -25,7 +25,7 @@ class PizzaTranslator extends } } -AppRegistry.registerComponent('PizzaTranslator', () => PizzaTranslator);

In this example, we store text in the state, because it changes over time.

There are a lot more things you might want to do with a text input. For example, you could validate the text inside while the user types. For more detailed examples, see the React docs on controlled components, or the reference docs for TextInput.

Text input is probably the simplest example of a component whose state naturally changes over time. Next, let's look at another type of component like this is one that controls layout, and learn about the ScrollView.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/handling-touches.html b/releases/next/docs/handling-touches.html index 347e30b4d89..ede11521c58 100644 --- a/releases/next/docs/handling-touches.html +++ b/releases/next/docs/handling-touches.html @@ -1,4 +1,4 @@ -Handling Touches

Handling Touches #

Users interact with mobile apps mainly through touch. They can use a combination of gestures, such as tapping on a button, scrolling a list, or zooming on a map.

React Native provides components to handle common gestures, such as taps and swipes, as well as a comprehensive gesture responder system to allow for more advanced gesture recognition.

Tappable Components #

You can use "Touchable" components when you want to capture a tapping gesture. They take a function through the onPress props which will be called when the touch begins and ends within the bounds of the component.

Example:

class MyButton extends Component { +Handling Touches

Handling Touches #

Users interact with mobile apps mainly through touch. They can use a combination of gestures, such as tapping on a button, scrolling a list, or zooming on a map.

React Native provides components to handle common gestures, such as taps and swipes, as well as a comprehensive gesture responder system to allow for more advanced gesture recognition.

Tappable Components #

You can use "Touchable" components when you want to capture a tapping gesture. They take a function through the onPress props which will be called when the touch begins and ends within the bounds of the component.

Example:

class MyButton extends Component { _onPressButton() { console.log("You tapped the button!"); } @@ -10,7 +10,7 @@ </TouchableHighlight> ); } -}

Tappable components should provide feedback that show the user what is handling their touch, and what will happen when they lift their finger. The user should also be able to cancel a tap by dragging their finger away.

Which component you use will depend on what kind of feedback you want to provide:

  • Generally, you can use TouchableHighlight anywhere you would use a button or link on web. The view's background will be darkened when the user presses down on the button.

  • You may consider using TouchableNativeFeedback on Android to display ink surface reaction ripples that respond to the user's touch.

  • TouchableOpacity can be used to provide feedback by reducing the opacity of the button, allowing the background to be seen through while the user is pressing down.

  • If you need to handle a tap gesture but you don't want any feedback to be displayed, use TouchableWithoutFeedback.

Long presses #

In some cases, you may want to detect when a user presses and holds a view for a set amount of time. These long presses can be handled by passing a function to the onLongPress props of any of the touchable components listed above.

Scrolling lists and swiping views #

A common pattern to many mobile apps is the scrollable list of items. Users interact with these using panning or swiping gestures. The ScrollView component displays a list of items that can be scrolled using these gestures.

ScrollViews can scroll vertically or horizontally, and can be configured to allow paging through views using swiping gestures by using the pagingEnabled props. Swiping horizontally between views can also be implemented on Android using the ViewPagerAndroid component.

A ListView is a special kind of ScrollView that is best suited for displaying long vertical lists of items. It can also display section headers and footers, similar to UITableViews on iOS.

Pinch-to-zoom #

A ScrollView with a single item can be used to allow the user to zoom content. Set up the maximumZoomScale and minimumZoomScale props and your user will be able to use pinch and expand gestures to zoom in and out.

Handling additional gestures #

If you want to allow a user to drag a view around the screen, or you want to implement your own custom pan/drag gesture, take a look at the PanResponder API or the gesture responder system docs.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/headless-js-android.html b/releases/next/docs/headless-js-android.html index b76c74a2f09..fb8b9a6de17 100644 --- a/releases/next/docs/headless-js-android.html +++ b/releases/next/docs/headless-js-android.html @@ -1,4 +1,4 @@ -Headless JS

Headless JS #

Headless JS is a way to run tasks in JavaScript while your app is in the background. It can be used, for example, to sync fresh data, handle push notifications, or play music.

The JS API #

A task is a simple async function that you register on AppRegistry, similar to registering React applications:

AppRegistry.registerHeadlessTask('SomeTaskName', () => require('SomeTaskName'));

Then, in SomeTaskName.js:

module.exports = async (taskData) => { +Headless JS

Headless JS #

Headless JS is a way to run tasks in JavaScript while your app is in the background. It can be used, for example, to sync fresh data, handle push notifications, or play music.

The JS API #

A task is a simple async function that you register on AppRegistry, similar to registering React applications:

AppRegistry.registerHeadlessTask('SomeTaskName', () => require('SomeTaskName'));

Then, in SomeTaskName.js:

module.exports = async (taskData) => { // do stuff }

You can do anything in your task as long as it doesn't touch UI: network requests, timers and so on. Once your task completes (i.e. the promise is resolved), React Native will go into "paused" mode (unless there are other tasks running, or there is a foreground app).

The Java API #

Yes, this does still require some native code, but it's pretty thin. You need to extend HeadlessJsTaskService and override getTaskConfig, e.g.:

public class MyTaskService extends FbHeadlessJsTaskService { @@ -13,7 +13,7 @@ } return null; } -}

Now, whenever you start your service, e.g. as a periodic task or in response to some system event / broadcast, JS will spin up, run your task, then spin down.

Caveats #

  • By default, your app will crash if you try to run a task while the app is in the foreground. This is to prevent developers from shooting themselves in the foot by doing a lot of work in a task and slowing the UI. There is a way around this.
  • If you start your service from a BroadcastReceiver, make sure to call HeadlessJsTaskService.acquireWakelockNow() before returning from onReceive().

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/height-and-width.html b/releases/next/docs/height-and-width.html index 0774f8e2236..4d0b6a3bf66 100644 --- a/releases/next/docs/height-and-width.html +++ b/releases/next/docs/height-and-width.html @@ -1,4 +1,4 @@ -Height and Width

Height and Width #

A component's height and width determine its size on the screen.

Fixed Dimensions #

The simplest way to set the dimensions of a component is by adding a fixed width and height to style. All dimensions in React Native are unitless, and represent density-independent pixels.

import React, { Component } from 'react'; +Height and Width

Height and Width #

A component's height and width determine its size on the screen.

Fixed Dimensions #

The simplest way to set the dimensions of a component is by adding a fixed width and height to style. All dimensions in React Native are unitless, and represent density-independent pixels.

import React, { Component } from 'react'; import { AppRegistry, View } from 'react-native'; class FixedDimensionsBasics extends Component { @@ -31,7 +31,7 @@ class FlexDimensionsBasics extends } }; -AppRegistry.registerComponent('AwesomeProject', () => FlexDimensionsBasics);

After you can control a component's size, the next step is to learn how to lay it out on the screen.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/image.html b/releases/next/docs/image.html index e29216fa130..a8af9b8fb22 100644 --- a/releases/next/docs/image.html +++ b/releases/next/docs/image.html @@ -1,4 +1,4 @@ -Image

Image #

A React component for displaying different types of images, +Image

Image #

A React component for displaying different types of images, including network images, static resources, temporary local images, and images from local disk, such as the camera roll.

This example shows both fetching and displaying an image from local storage as well as on from network.

import React, { Component } from 'react'; @@ -799,7 +799,7 @@ exports.examples : '500', color: 'blue', }, -});
\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/imageeditor.html b/releases/next/docs/imageeditor.html index 6ada13976ad..f3dba2f5984 100644 --- a/releases/next/docs/imageeditor.html +++ b/releases/next/docs/imageeditor.html @@ -1,9 +1,9 @@ -ImageEditor

ImageEditor #

Methods #

static cropImage(uri, cropData, success, failure) #

Crop the image specified by the URI param. If URI points to a remote +ImageEditor

ImageEditor #

Methods #

static cropImage(uri, cropData, success, failure) #

Crop the image specified by the URI param. If URI points to a remote image, it will be downloaded automatically. If the image cannot be loaded/downloaded, the failure callback will be called.

If the cropping process is successful, the resultant cropped image will be stored in the ImageStore, and the URI returned in the success callback will point to the image in the store. Remember to delete the -cropped image from the ImageStore when you are done with it.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/imagepickerios.html b/releases/next/docs/imagepickerios.html index 19b4bc756a3..7d86967b22e 100644 --- a/releases/next/docs/imagepickerios.html +++ b/releases/next/docs/imagepickerios.html @@ -1,4 +1,4 @@ -ImagePickerIOS

ImagePickerIOS #

Methods #

static canRecordVideos(callback) #

static canUseCamera(callback) #

static openCameraDialog(config, successCallback, cancelCallback) #

static openSelectDialog(config, successCallback, cancelCallback) #

You can edit the content above on GitHub and send us a pull request!

ImagePickerIOS #

Methods #

static canRecordVideos(callback) #

static canUseCamera(callback) #

static openCameraDialog(config, successCallback, cancelCallback) #

static openSelectDialog(config, successCallback, cancelCallback) #

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/images.html b/releases/next/docs/images.html index ad32ee24618..4dbe3787369 100644 --- a/releases/next/docs/images.html +++ b/releases/next/docs/images.html @@ -1,4 +1,4 @@ -Images

Images #

Static Image Resources #

As of 0.14 release, React Native provides a unified way of managing images in your iOS and Android apps. To add a static image to your app, place it somewhere in your source code tree and reference it like this:

<Image source={require('./my-icon.png')} />

The image name is resolved the same way JS modules are resolved. In the example above the packager will look for my-icon.png in the same folder as the component that requires it. Also if you have my-icon.ios.png and my-icon.android.png, the packager will pick the file depending on the platform you are running on.

You can also use @2x, @3x, etc. suffix in the file name to provide images for different screen densities. For example, if you have the following file structure:

. +Images

Images #

Static Image Resources #

As of 0.14 release, React Native provides a unified way of managing images in your iOS and Android apps. To add a static image to your app, place it somewhere in your source code tree and reference it like this:

<Image source={require('./my-icon.png')} />

The image name is resolved the same way JS modules are resolved. In the example above the packager will look for my-icon.png in the same folder as the component that requires it. Also if you have my-icon.ios.png and my-icon.android.png, the packager will pick the file depending on the platform you are running on.

You can also use @2x, @3x, etc. suffix in the file name to provide images for different screen densities. For example, if you have the following file structure:

. ├── button.js └── img ├── check@2x.png @@ -21,7 +21,7 @@ using local resources that are outside of Images.xcassets.

< <Image source={...}> <Text>Inside</Text> </Image> -);

iOS Border Radius Styles #

Please note that the following corner specific, border radius style properties are currently ignored by iOS's image component:

  • borderTopLeftRadius
  • borderTopRightRadius
  • borderBottomLeftRadius
  • borderBottomRightRadius

Off-thread Decoding #

Image decoding can take more than a frame-worth of time. This is one of the major sources of frame drops on the web because decoding is done in the main thread. In React Native, image decoding is done in a different thread. In practice, you already need to handle the case when the image is not downloaded yet, so displaying the placeholder for a few more frames while it is decoding does not require any code change.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/imagestore.html b/releases/next/docs/imagestore.html index 1b41f2ad5e5..79651901c7a 100644 --- a/releases/next/docs/imagestore.html +++ b/releases/next/docs/imagestore.html @@ -1,4 +1,4 @@ -ImageStore

ImageStore #

Methods #

static hasImageForTag(uri, callback) #

Check if the ImageStore contains image data for the specified URI. +ImageStore

ImageStore #

Methods #

static hasImageForTag(uri, callback) #

Check if the ImageStore contains image data for the specified URI. @platform ios

static removeImageForTag(uri) #

Delete an image from the ImageStore. Images are stored in memory and must be manually removed when you are finished with them, otherwise they will continue to use up RAM until the app is terminated. It is safe to @@ -16,7 +16,7 @@ will be called.

Note that it is very inefficient to transfer large quantit data between JS and native code, so you should avoid calling this more than necessary. To display an image in the ImageStore, you can just pass the URI to an <Image/> component; there is no need to retrieve the -base64 data.

You can edit the content above on GitHub and send us a pull request!

\ No newline at end of file + \ No newline at end of file diff --git a/releases/next/docs/integration-with-existing-apps.html b/releases/next/docs/integration-with-existing-apps.html index 2d492b9b8c1..836a70961f7 100644 --- a/releases/next/docs/integration-with-existing-apps.html +++ b/releases/next/docs/integration-with-existing-apps.html @@ -1,4 +1,4 @@ -Integration With Existing Apps

Integration With Existing Apps #

+Integration With Existing Apps

Integration With Existing Apps #