Welcome to Knowledge Base!

KB at your finger tips

This is one stop global knowledge base where you can learn about all the products, solutions and support features.

Categories
All
Mobile-React Native
React Native Team Principles · React Native

React Native Team Principles

· 5 min read

The React Native team at Facebook is guided by principles that help determine how we prioritize our work on React Native. These principles represent our team specifically and do not necessarily represent every stakeholder in the React Native community. We are sharing these principles here to be more transparent about what drives us, how we make decisions, and how we focus our efforts.

Native Experience

Our top priority for React Native is to match the expectations people have for each platform . This is why React Native renders to platform primitives. We value native look-and-feel over cross-platform consistency.

For example, the TextInput in React Native renders to a UITextField on iOS. This ensures that integration with password managers and keyboard controls work out of the box. By using platform primitives, React Native apps are also able to stay up-to-date with design and behavior changes from new releases of Android and iOS.

In order to match the look-and-feel of native apps, we must also match their performance. This is where we focus our most ambitious efforts. For example, Facebook created Hermes, a new JavaScript Engine built from scratch for React Native on Android. Hermes significantly improves the start time of React Native apps. We are also working on major architectural changes that optimize the threading model and make React Native easier to interoperate with native code.

Massive Scale​

Hundreds of screens in the Facebook app are implemented with React Native. The Facebook app is used by billions of people on a huge range of devices. This is why we invest in the most challenging problems at scale.

Deploying React Native in our apps lets us identify problems that we wouldn’t see at a smaller scale. For example, Facebook focuses on improving performance across a broad spectrum of devices from the newest iPhone to many older generations of Android devices. This focus informs our architecture projects such as Hermes, Fabric, and TurboModules.

We have proven that React Native can scale to massive organizations too. When hundreds of developers are working on the same app, gradual adoption is a must. This is why we made sure that React Native can be adopted one screen at a time. Soon, we will be taking this one step further and enable migrating individual native views of an existing native screen to React Native.

A focus on massive scale means there are many things our team isn’t currently working on. For example, our team doesn’t drive the adoption of React Native in the industry. We also do not actively build solutions for problems that we don’t see at scale. We are proud that we have many partners and core contributors that are able to focus on those important areas for the community.

Developer Velocity​

Great user experiences are created iteratively. It should only take a few seconds to seeing the result of code changes in a running app. React Native's architecture enables it to provide near-instant feedback during development.

We often hear from teams that adopting React Native significantly improved their development velocity. These teams find that the instant feedback during development makes it much easier to try different ideas and add extra polish when they don’t have to interrupt their coding session for every little change. When we make changes to React Native, we make sure to preserve this quality of the developer experience.

Instant feedback is not the only way that React Native improves developer velocity. Teams can leverage the fast-growing ecosystem of high quality open source packages. Teams can also share business logic between Android, iOS, and the web. This helps them ship updates faster and reduce organizational silos between platform teams.

Every Platform​

When we introduced React Native in 2014, we presented it with our motto “Learn once, write anywhere” — and we mean anywhere . Developers should be able to reach as many people as possible without being limited by device model or operating system.

React Native targets very different platforms including mobile, desktop, web, TV, VR, game consoles, and more. We want to enable rich experiences on each platform instead of requiring developers to build for the lowest common denominator. To accomplish this, we focus on supporting the unique features of each platform. This ranges from varying input mechanisms (e.g. touch, pen, mouse) to fundamentally different consumption experiences like 3D environments in VR.

This principle informed our decision to implement React Native’s new core architecture in cross-platform C++ to promote parity across platforms. We are also refining the public interface targeted at other platform maintainers like Microsoft with Windows and macOS. We strive to enable any platforms to support React Native.

Declarative UI​

We don’t believe in deploying the exact same user interface on every platform, we believe in exposing each platform’s unique capabilities with the same declarative programming model . Our declarative programming model is React.

In our experience, the unidirectional data flow popularized by React makes applications easier to understand. We prefer to express a screen as a composition of declarative components rather than imperatively managed views. React’s success on the web and the direction of the new native Android and iOS frameworks show that the industry has also embraced declarative UI.

React popularized declarative user interfaces. However, there remain many unsolved problems that React is uniquely positioned to solve. React Native will continue to build on top of the innovations of React and remain at the forefront of the declarative user interface movement.

Tags:
  • announcement
React Native Documentation Update · React Native

React Native Documentation Update

· 3 min read

Last year we conducted user interviews and sent out a survey to learn more about how and when people use the React Native docs. With the data and guidance gleaned from 24 interviews and over 3000 survey responses, we've been able to work to improve React Native's documentation, and we're excited to share that progress today:

  • New Getting Started guides We launched new Getting Started with docs to explain what Native Components are to people with no mobile development background. We also included a refresher/introduction to React to help folks getting started with React for the first time!
  • New Testing guide We worked with Vojtech Novak to create a new illustrated testing guide that introduces app developers to different kinds of testing strategies and how they work in a React Native workflow.
  • New Security guide We worked with Kadi Kraman to create a new illustrated security guide that explains the basics of security in a React Native world and puts forth best in class solutions.
  • More illustrations We've added fancy new illustrations, including the new Pressable and introduction to React Native components docs
  • https://reactnative.dev After 5 years we finally moved to our own domain! reactnative.dev is easier to autocomplete from your browser bar and is easier to type out than our previous github.io address!
  • Site design and architecture improvements We've updated the design and site architecture to surface and categorize more of our guides and make content in the API reference more readable. Kudos especially to Bartosz Kaszubowski whose attention to detail and collaboration has made many of these changes possible quickly!
  • Updated Core Component and API docs We held a documentation drive to update reference docs! Thanks to these and other participants we were able to fully update the docs and add Snack examples to all of them in time for 0.62: Marta Dabrowka, Abraham Nnaji, Ahmed Talaat El-Hager, Mohamed Abdel Nasser Abdou, Danilo Britto, Mitul Savani, Kaio Duarte, Pablo Espinosa, Jesse Katsumata, I Gede Agastya Darma Laksana, Sebastião Bruno Kiafuka Fernando, Miguel Bolivar, Dani Akash, Luiz Celso de Faria Alves, and Bartosz Kaszubowski. With their contributions, these are the best and most up to date React Native docs yet!
  • Keep those PRs coming! We are able to consistently keep our open PRs under 10 per week! Thank you for sending them!

Thank you so much to everyone who participated in the interviews, the survey, and our documentation efforts! Your collaboration makes this possible.

What’s next?​

The global COVID-19 pandemic has impacted many community members’ jobs.

We are responding with additional content including:

  • New and improved Native Modules guides
  • Introductory content for people coming in to React Native for the first time

You can help!​

There are many ways you can help us write even better docs!

  1. If you see a typo, run into an issue with a guide, or something otherwise isn’t quite right, click that “Edit” button and submit a PR.
  2. Participate in our survey—this helps us understand how you use React Native and its documentation
  3. Write for us! We’re working on a tutorial section as well as guides for topics like offline apps, navigation, accessibility, debugging, animations, internationalization, and performance. If you or someone you admire or know is a perfect fit for any of these, please reach out to me!
Tags:
  • announcement
Read article
The GAAD Pledge - Improving React Native Accessibility · React Native

The GAAD Pledge - Improving React Native Accessibility

· 2 min read

Hello React Native Community,​

In May 2020 Facebook was the first company to take the GAAD pledge, by doing so they committed to making accessibility a core part of the React Native open source project. Since May, Facebook has spent that time thoughtfully reviewing and documenting accessibility gaps within React Native. So far the gap analysis has surfaced 90 issues, all of which have been translated to GitHub issues.

Overall, we found that React Native APIs provide strong support for accessibility. However, we also found many core components do not yet fully utilize platform accessibility APIs and support is missing for some platform specific features.

The enthusiasm and diversity of contributors have always played a critical role in the development of React Native and these gaps in accessibility are great opportunities for current and new contributors. If you have been interested in contributing to React Native, we encourage you to join us in making React Native more accessible.

To recognize contributors for their effort, when an accessibility issue is closed and attached to a pull request, contributors will get a shout out on Twitter from our community manager. Contributors whose pull requests are accepted into the codebase will be highlighted in our monthly issues update on the React Native blog.

Please join us in making React Native more accessible for everyone.

How you can help:​

  • New contributors should read the contribution guide and browse the list of 46 good first issues in the React Native GitHub.

  • Contributors interested in issues requiring a bit more effort should visit the project page for Improved React Native Accessibility to see the GitHub issues that need their knowledge of React Native.

  • Technical writers interested in updating React Native's documentation to reflect the accessibility gaps being closed should visit the React Native Docs.

  • Share this initiative with anyone who may be able to help!

  • Follow the GAAD Pledge Open Source Accessibility Community Manager for React Native on Twitter or Facebook to keep up to date on progress.

Tags:
  • announcement
Read article
Announcing React Native 0.64 with Hermes on iOS · React Native

Announcing React Native 0.64 with Hermes on iOS

· 4 min read

Today we’re releasing React Native 0.64 that ships with support for Hermes on iOS.

Hermes opt-in on iOS​

Hermes is an open source JavaScript engine optimized for running React Native. It improves performance by decreasing memory utilization, reducing download size and decreasing the time it takes for the app to become usable or “time to interactive” (TTI).

With this release, we are happy to announce that you can now use Hermes to build on iOS as well. To enable Hermes on iOS, set hermes_enabled to true in your Podfile and run pod install .

use_react_native!(
:path => config[:reactNativePath],
# to enable hermes on iOS, change `false` to `true` and then install pods
:hermes_enabled => true
)

Please keep in mind that Hermes support on iOS is still early stage. We are keeping it as an opt-in as we are running further benchmarking. We encourage you to try it on your own applications and let us know how it is working out for you!

Inline Requires enabled by default​

Inline Requires is a Metro configuration option that improves startup time by delaying execution of JavaScript modules until they are used, instead of at startup.

This feature has existed and been recommended for a few years as an opt-in configuration option, listed in the Performance section of our documentation. We are now enabling this option by default for new applications to help people have fast React Native applications without extra configuration.

Inline Requires is a Babel transform that takes module imports and converts them to be inline. As an example, Inline Requires transforms this module import call from being at the top of the file to where it is used.

Before:

import {MyFunction} from 'my-module';

const MyComponent = props => {
const result = MyFunction();

return <Text>{result}</Text>;
};

After:

const MyComponent = props => {
const result = require('my-module').MyFunction();

return <Text>{result}</Text>;
};

More information about Inline Requires is available in the Performance documentation.

View Hermes traces with Chrome​

Over the last year Facebook has sponsored the Major League Hacking fellowship, supporting contributions to React Native. Jessie Nguyen and Saphal Patro added the ability to use the Performance tab on Chrome DevTools to visualize the execution of your application when it is using Hermes.

For more information, check out the new documentation page.

Hermes with Proxy Support​

We have added Proxy support to Hermes, enabling compatibility with popular community projects like react-native-firebase and mobx. If you have been using these packages you can now migrate to Hermes for your project.

We plan to make Hermes the default JavaScript engine for Android in a coming release so we are working to resolve the remaining issues people have when using Hermes. Please open an issue on the Hermes GitHub repo if there are remaining issues holding back your app from adopting Hermes.

React 17​

React 17 does not include new developer-facing features or major breaking changes. For React Native applications, the main change is a new JSX transform enabling files to no longer need to import React to be able to use JSX.

More information about React 17 is available on the React blog.

Major Dependency Version Changes​

  • Dropped Android API levels 16-20. The Facebook app consistently drops support for Android versions with sufficiently low usage. As the Facebook app no longer supports these versions and is React Native’s main testing surface, React Native is dropping support as well.
  • Xcode 12 and CocoaPods 1.10 are required
  • Minimum Node support bumped from 10 to Node 12
  • Flipper bumped to 0.75.1

Thanks​

Thank you to the hundreds of contributors that helped make 0.64 possible! The 0.64 changelog includes all of the changes included in this release.

Tags:
  • announcement
  • release
Read article
The GAAD Pledge - March Accessibility Issues Update · React Native

The GAAD Pledge - March Accessibility Issues Update

· 3 min read

It has been four weeks since we reached out to the GitHub community with a thoroughly reviewed gap analysis and list of issues to improve React Native's accessibility. With the help of the React Native community, we are already making great progress on improving accessibility. Community members have been helping contributors, reviewing tests, and bringing attention to prior accessibility issues. Since March 8th the community has closed six issues with four pull requests and seven other pull requests are in the pipeline for review.

While this work continues, the React Native and Accessibility teams at Facebook are evaluating accessibility bugs and issues that were submitted prior to this initiative, to determine if they are already covered by our current gap analysis or if there are additional issues that need to be brought into the project. One new issue has already been discovered and moved into the project, four others directly mapped to existing issues and two others are expected to be closed by addressing existing issues that address the root cause of their issue.

Thank you to all the community members who have participated. You are truly moving the needle in making React Native more accessible for everyone!

Closed Pull Requests 🎉​

  • Added talkback support for button accessibility: disabled prop #31001 - closed by @huzaifaaak

  • feat: set disabled accessibilityState when TouchableHighlight is disabled #31135 closed by @natural_clar

  • [Android] Selected State does not annonce when TextInput Component selected #31144 closed by fabriziobertoglio1987

  • Added talkback support for TouchableNativeFeedback accessibility: disabled prop #31224 closed by @kyamashiro73

  • Accessibility/button test #31189 closed by @huzaifaaak

    • Adds a test for accessibilityState for button

Fixes​

  • Button component (fixed by #31001):

    • Now announces when it is disabled

    • Disables click functionality for screen readers when the button is disabled

    • Announces the selected state of the button

  • TextInput component (fixed by #31144):

    • Announces "selected" when the "selected" accessibilityState is set to true and the element is focused
  • TouchableHighlight component (fixed by #31135):

    • Disables click functionality for screen readers when the component is disabled
  • TouchableNativeFeedback component (fixed by #31224):

    • Disables click functionality for screen readers when the component is disabled

Other Progress​

Status Number of Issues
Issues To Do 53
In Progress Issues by the Community 8
In Progress Issues by React Native Team 5
Pull Request in Progress 3
Pull Request in Reviews 4

Get involved!​

  • New contributors should read the contribution guide and browse the list of 37 good first issues in the React Native GitHub.

  • Contributors interested in issues requiring a bit more effort should visit the project page for Improved React Native Accessibility to see the GitHub issues that need their knowledge of React Native.

  • Technical writers interested in updating React Native's documentation to reflect the accessibility gaps being closed should visit the React Native Docs.

  • Share this initiative with anyone who may be able to help!

  • Follow the GAAD Pledge Open Source Accessibility Community Manager for React Native on Twitter or Facebook to keep up to date on progress.

Tags:
  • announcement
Read article
The GAAD Pledge - One Year Later · React Native

The GAAD Pledge - One Year Later

· 4 min read

It has been one year since Facebook took the GAAD Pledge to make React Native accessible and the project has exceeded our expectations. We are excited to announce that this project will continue throughout 2021 and want to update everyone on our progress so far. Following a thorough analysis of the accessibility gaps in React Native last year, work began on filling these gaps.

We started with 90 outstanding gap analysis issues and from March 2021, when the project launched on GitHub, until now:

  • 11 issues have been closed by the community.

  • 19 issues were evaluated and closed by the React Native team.

  • 9 pull requests were merged.

  • 1 pull request was merged into the React Native docs.

We want to recognize and thank the React Native community for the significant progress towards a more accessible React Native over the past year. Every contributor's effort has counted in making progress on improving React Native Accessibility.

Fixes​

Two types of issues have been fixed in multiple components and one new functionality has been added to the API by the 9 pull requests.

  • An issue with Disabled state has been addressed in seven components

  • An issue with Selected state was addressed in two components

  • A new addition to the React Native API added the ability to query AccessibilityManager.getRecommendedTimeoutMillis().

Disabled State Announcement and Disable function​

One of the most prevalent issues found during the gap analysis was that some components do not announce or disable functionality. Now seven components announce their disabled state or disable click functionality.

Announces when Disabled

  • Button - #31001

  • Images - #31252

  • ImageBackground - #31252

Disables click functionality when the component has a disabled prop

  • Button - #31001

  • Text - React Native Team commit

  • Pressable - React Native Team commit

  • TouchableHighlight - #31135

  • TouchableOpacity - #31108

  • TouchableNativeFeedback - #31224

  • TouchableWithoutFeedback - #31297

Selected State Announcement​

There were some components that did not announce their selection when in focus. This behavior has now been fixed when the component is in focus and the AccessibilityState is set to selected or the component is changed to selected.

Announces when Selected

  • Button - #31001

  • TextInput - #31144

Accessibility Timeout Setting​

There was previously no way to query the accessibility timeout setting on Android. The fix added the ability to query AccessibilityManager.getRecommendedTimeoutMillis() . This queries the "Time to take action" before the UI elements auto-dismisses or auto-progresses.

Documentation Additions​

The React Native documentation must be updated to reflect each addition or change to the available APIs. The new addition to the React Native documentation covered the addition of getRecommendedTimeoutMillis() to AccessibilityInfo.

Community Involvement​

We want to thank all the contributors mentioned below who have submitted and merged pull requests as well as those who have reviewed and commented on issues.

Merged Pull Requests​

  • @huzaifaaak closed 3 issues with:
    • Added talkback support for button accessibility: disabled prop #31001
    • Accessibility/button test #31189
  • @natural_clar closed 1 issue with:
    • feat: set disabled accessibilityState when TouchableHighlight is disabled #31135
  • fabriziobertoglio1987 closed 2 issues with:
    • [Android] Selected State does not annonce when TextInput Component selected #31144
    • Accessibility Fix Image does not announce "disabled" #31252
  • @kyamashiro73 closed 1 issue with:
    • Added talkback support for TouchableNativeFeedback accessibility: disabled prop #31224
  • @grgr-dkrk closed 1 issue and added to the React Native documentation with:
    • add getRecommendedTimeoutMillis to AccessibilityInfo #31063
    • feat: add getRecommendedTimeoutMillis section on accessibilityInfo #2581
  • @crloscuesta closed 1 issue with:
    • Disable accessibilityState when TouchableWithoutFeedback is disabled #31297
  • @chakrihacker closed 1 issue with:
    • Disable TouchableOpacity when accessibility disabled is set #31108

Thank you to the community members who gave their time in other ways!

Simek, saurabhkacholiya, meehawk, intergalacticspacehighway, chrisglein, jychiao and Waltari10

Get Involved!​

We've come a long way but we're not done yet. We need your support to reach the finish line. Facebook's React Native team has committed to supporting contributors working on gap analysis issues. They will continue to respond to comments on Accessibility issues and triage pull requests. The React Native team is also tackling some of the toughest gap analysis issues. This work includes the correct translation of accessibilityRoles to other languages and specifying error text for specific components.

Join us in tackling the rest. There are still open accessibility issues on the Improved React Native Accessibility project board. Issues with Checked/Unchecked State, Entrance/exit from Collection, and Position in Collection are great opportunities for current and new contributors to contribute to a more accessible React Native.

Learn More​

Read about how the gap analysis was conducted on the Facebook Tech blog or about the launch of the GitHub issues on the React Native Blog.

Tags:
  • announcement
Read article