diff --git a/blog/2017/03/01/better-list-views.html b/blog/2017/03/01/better-list-views.html new file mode 100644 index 00000000000..0888d42fc87 --- /dev/null +++ b/blog/2017/03/01/better-list-views.html @@ -0,0 +1,55 @@ +Better List Views in React Native
React Native Blog
Stay up-to-date with the latest React Native news and events.

Better List Views in React Native

Many of you have started playing with some of our new List components already after our teaser announcement in the community group, but we are officially announcing them today! No more ListViews or DataSources, stale rows, ignored bugs, or excessive memory consumption - with the just-released RN 0.43-rc.1 you can pick from the new suite of components what best fits your use-case, with great perf and feature sets out of the box:

<FlatList> #

This is the workhorse component for simple, performant lists. Provide an array of data and a renderItem function and you're good to go:

<FlatList + data={[{title: 'Title Text', key: 'item1'}, ...]} + renderItem={({item}) => <ListItem title={item.title}} +/>

<SectionList> #

If you want to render a set of data broken into logical sections, maybe with section headers (e.g. in an alphabetical address book), and potentially with heterogeneous data and rendering (such as a profile view with some buttons followed by a composer, then a photo grid, then a friend grid, and finally a list of stories), this is the way to go.

<SectionList + renderItem={({item}) => <ListItem title={item.title}} + renderSectionHeader={({section}) => <H1 title={section.key} />} + sections={[ // homogenous rendering between sections + {data: [...], key: ...}, + {data: [...], key: ...}, + {data: [...], key: ...}, + ]} +/> + +<SectionList + sections={[ // heterogeneous rendering between sections + {data: [...], key: ..., renderItem: ...}, + {data: [...], key: ..., renderItem: ...}, + {data: [...], key: ..., renderItem: ...}, + ]} +/>

<VirtualizedList> #

The implementation behind the scenes with a more flexible API. Especially handy if your data is not in a plain array (e.g. an immutable list).

Some Caveats #

  • The internal state of item subtrees is not preserved when content scrolls out of the render window. Make sure all your data is captured in the item data or external stores like Flux, Redux, or Relay.
  • These are based on PureComponent which means that they will not re-render if props remains shallow-equal. Make sure that everything your renderItem function depends on directly is passed as a prop that is not === after updates, otherwise your UI may not update on changes. This includes the data prop and parent component state. For example:

    <FlatList + data={this.state.data} + renderItem={({item}) => <MyItem + item={item} + onPress={() => this.setState((oldState) => ({ + selected: { // New instance breaks `===` + ...oldState.selected, // copy old data + [item.key]: !oldState.selected[item.key], // toggle + }})) + } + selected={ + !!this.state.selected[item.key] // renderItem depends on state + } + />} + selected={ // Can be any prop that doesn't collide with existing props + this.state.selected // A change to selected should re-render FlatList + } +/>
  • In order to constrain memory and enable smooth scrolling, content is rendered asynchronously offscreen. This means it's possible to scroll faster than the fill rate and momentarily see blank content. This is a tradeoff that can be adjusted to suit the needs of each application, and we are working on improving it behind the scenes.

  • By default, these new lists look for a key prop on each item and use that for the React key. Alternatively, you can provide a custom keyExtractor prop.

Features #

Lists are used in many contexts, so we packed the new components full of features to handle the majority of use cases out of the box:

  • Scroll loading (onEndReached).
  • Pull to refresh (onRefresh / refreshing).
  • Configurable viewability (VPV) callbacks (onViewableItemsChanged / viewabilityConfig).
  • Horizontal mode (horizontal).
  • Intelligent item and section separators.
  • Multi-column support (numColumns)
  • scrollToEnd, scrollToIndex, and scrollToItem
  • Better Flow typing.

Performance #

Besides simplifying the API, the new list components also have significant performance enhancements, the main one being nearly constant memory usage for any number of rows. This is done by 'virtualizing' elements that are outside of the render window by completely unmounting them from the component hierarchy and reclaiming the JS memory from the react components, along with the native memory from the shadow tree and the UI views. This has a catch which is that internal component state will not be preserved, so make sure you track any important state outside of the components themselves, e.g. in Relay or Redux or Flux store.

Limiting the render window also reduces the amount of work that needs to be done by React and the native platform, e.g from view traversals. Even if you are rendering the last of a million elements, with these new lists there is no need to iterate through all those elements in order to render. You can even jump to the middle with scrollToIndex without excessive rendering.

We've also made some improvements with scheduling which should help with application responsiveness. Items at the edge of the render window are rendered infrequently and at a lower priority after any active gestures or animations or other interactions have completed.

Advanced Usage #

By default, all items in the render window are re-rendered any time any props change. Often this is fine because there is a finite window of items, but if you want to further optimize performance you can implement shouldItemUpdate. If you do, be careful that your renderItem function does not depend on anything not compared in shouldItemUpdate.

If you can calculate the height of your rows without rendering them, you can improve the user experience by providing the getItemLayout prop. This makes it much smoother to scroll to specific items with e.g. scrollToIndex, and will improve the scroll indicator UI because the height of the content can be determined without rendering it.

If you have an alternative data type, like an immutable list, <VirtualizedList> is the way to go. It takes a getItem prop that lets you return the item data for any given index and has looser flow typing.

There are also a bunch of parameters you can tweak if you have an unusual use case. For example, you can use windowSize to trade off memory usage vs. user experience, maxToRenderPerBatch to adjust fill rate vs. responsiveness, onEndReachedThreshold to control when scroll loading happens, and more.

Future Work #

  • Migration of existing surfaces (ultimately deprecation of ListView).
  • More features as we see/hear the need (let us know!).
  • Sticky section header support.
  • More performance optimizations.
  • Support functional item components with state.
\ No newline at end of file diff --git a/blog/2017/03/13/better-list-views.html b/blog/2017/03/13/better-list-views.html new file mode 100644 index 00000000000..6f9cc0299f7 --- /dev/null +++ b/blog/2017/03/13/better-list-views.html @@ -0,0 +1,55 @@ +Better List Views in React Native
React Native Blog
Stay up-to-date with the latest React Native news and events.

Better List Views in React Native

Many of you have started playing with some of our new List components already after our teaser announcement in the community group, but we are officially announcing them today! No more ListViews or DataSources, stale rows, ignored bugs, or excessive memory consumption - with the latest React Native March 2017 release candidate (0.43-rc.1) you can pick from the new suite of components what best fits your use-case, with great perf and feature sets out of the box:

<FlatList> #

This is the workhorse component for simple, performant lists. Provide an array of data and a renderItem function and you're good to go:

<FlatList + data={[{title: 'Title Text', key: 'item1'}, ...]} + renderItem={({item}) => <ListItem title={item.title}} +/>

<SectionList> #

If you want to render a set of data broken into logical sections, maybe with section headers (e.g. in an alphabetical address book), and potentially with heterogeneous data and rendering (such as a profile view with some buttons followed by a composer, then a photo grid, then a friend grid, and finally a list of stories), this is the way to go.

<SectionList + renderItem={({item}) => <ListItem title={item.title}} + renderSectionHeader={({section}) => <H1 title={section.key} />} + sections={[ // homogenous rendering between sections + {data: [...], key: ...}, + {data: [...], key: ...}, + {data: [...], key: ...}, + ]} +/> + +<SectionList + sections={[ // heterogeneous rendering between sections + {data: [...], key: ..., renderItem: ...}, + {data: [...], key: ..., renderItem: ...}, + {data: [...], key: ..., renderItem: ...}, + ]} +/>

<VirtualizedList> #

The implementation behind the scenes with a more flexible API. Especially handy if your data is not in a plain array (e.g. an immutable list).

Features #

Lists are used in many contexts, so we packed the new components full of features to handle the majority of use cases out of the box:

  • Scroll loading (onEndReached).
  • Pull to refresh (onRefresh / refreshing).
  • Configurable viewability (VPV) callbacks (onViewableItemsChanged / viewabilityConfig).
  • Horizontal mode (horizontal).
  • Intelligent item and section separators.
  • Multi-column support (numColumns)
  • scrollToEnd, scrollToIndex, and scrollToItem
  • Better Flow typing.

Some Caveats #

  • The internal state of item subtrees is not preserved when content scrolls out of the render window. Make sure all your data is captured in the item data or external stores like Flux, Redux, or Relay.

  • These components are based on PureComponent which means that they will not re-render if props remains shallow-equal. Make sure that everything your renderItem function depends on directly is passed as a prop that is not === after updates, otherwise your UI may not update on changes. This includes the data prop and parent component state. For example:

    <FlatList + data={this.state.data} + renderItem={({item}) => <MyItem + item={item} + onPress={() => this.setState((oldState) => ({ + selected: { // New instance breaks `===` + ...oldState.selected, // copy old data + [item.key]: !oldState.selected[item.key], // toggle + }})) + } + selected={ + !!this.state.selected[item.key] // renderItem depends on state + } + />} + selected={ // Can be any prop that doesn't collide with existing props + this.state.selected // A change to selected should re-render FlatList + } +/>
  • In order to constrain memory and enable smooth scrolling, content is rendered asynchronously offscreen. This means it's possible to scroll faster than the fill rate and momentarily see blank content. This is a tradeoff that can be adjusted to suit the needs of each application, and we are working on improving it behind the scenes.

  • By default, these new lists look for a key prop on each item and use that for the React key. Alternatively, you can provide a custom keyExtractor prop.

Performance #

Besides simplifying the API, the new list components also have significant performance enhancements, the main one being nearly constant memory usage for any number of rows. This is done by 'virtualizing' elements that are outside of the render window by completely unmounting them from the component hierarchy and reclaiming the JS memory from the react components, along with the native memory from the shadow tree and the UI views. This has a catch which is that internal component state will not be preserved, so make sure you track any important state outside of the components themselves, e.g. in Relay or Redux or Flux store.

Limiting the render window also reduces the amount of work that needs to be done by React and the native platform, e.g from view traversals. Even if you are rendering the last of a million elements, with these new lists there is no need to iterate through all those elements in order to render. You can even jump to the middle with scrollToIndex without excessive rendering.

We've also made some improvements with scheduling which should help with application responsiveness. Items at the edge of the render window are rendered infrequently and at a lower priority after any active gestures or animations or other interactions have completed.

Advanced Usage #

Unlike ListView, all items in the render window are re-rendered any time any props change. Often this is fine because the windowing reduces the number of items to a constant number, but if your items are on the complex side, you should make sure to follow React best practices for performance and use React.PureComponent and/or shouldComponentUpdate as appropriate within your components to limit re-renders of the recursive subtree.

If you can calculate the height of your rows without rendering them, you can improve the user experience by providing the getItemLayout prop. This makes it much smoother to scroll to specific items with e.g. scrollToIndex, and will improve the scroll indicator UI because the height of the content can be determined without rendering it.

If you have an alternative data type, like an immutable list, <VirtualizedList> is the way to go. It takes a getItem prop that lets you return the item data for any given index and has looser flow typing.

There are also a bunch of parameters you can tweak if you have an unusual use case. For example, you can use windowSize to trade off memory usage vs. user experience, maxToRenderPerBatch to adjust fill rate vs. responsiveness, onEndReachedThreshold to control when scroll loading happens, and more.

Future Work #

  • Migration of existing surfaces (ultimately deprecation of ListView).
  • More features as we see/hear the need (let us know!).
  • Sticky section header support.
  • More performance optimizations.
  • Support functional item components with state.
\ No newline at end of file diff --git a/blog/2017/03/13/idx-the-existential-function.html b/blog/2017/03/13/idx-the-existential-function.html new file mode 100644 index 00000000000..c752d119c42 --- /dev/null +++ b/blog/2017/03/13/idx-the-existential-function.html @@ -0,0 +1,25 @@ +idx: The Existential Function
React Native Blog
Stay up-to-date with the latest React Native news and events.

idx: The Existential Function

At Facebook, we often need to access deeply nested values in data structures fetched with GraphQL. On the way to accessing these deeply nested values, it is common for one or more intermediate fields to be nullable. These intermediate fields may be null for a variety of reasons, from failed privacy checks to the mere fact that null happens to be the most flexible way to represent non-fatal errors.

Unfortunately, accessing these deeply nested values is currently tedious and verbose.

props.user && +props.user.friends && +props.user.friends[0] && +props.user.friends[0].friends

There is an ECMAScript proposal to introduce the existential operator which will make this much more convenient. But until a time when that proposal is finalized, we want a solution that improves our quality of life, maintains existing language semantics, and encourages type safety with Flow.

We came up with an existential function we call idx.

idx(props, _ => _.user.friends[0].friends)

The invocation in this code snippet behaves similarly to the boolean expression in the code snippet above, except with significantly less repetition. The idx function takes exactly two arguments:

  • Any value, typically an object or array into which you want to access a nested value.
  • A function that receives the first argument and accesses a nested value on it.

In theory, the idx function will try-catch errors that are the result of accessing properties on null or undefined. If such an error is caught, it will return either null or undefined. (And you can see how this might be implemented in idx.js.)

In practice, try-catching every nested property access is slow, and differentiating between specific kinds of TypeErrors is fragile. To deal with these shortcomings, we created a Babel plugin that transforms the above idx invocation into the following expression:

props.user == null ? props.user : +props.user.friends == null ? props.user.friends : +props.user.friends[0] == null ? props.user.friends[0] : +props.user.friends[0].friends

Finally, we added a custom Flow type declaration for idx that allows the traversal in the second argument to be properly type-checked while permitting nested access on nullable properties.

The function, Babel plugin, and Flow declaration are now available on GitHub. They are used by installing the idx and babel-plugin-idx npm packages, and adding “idx” to the list of plugins in your .babelrc file.

\ No newline at end of file diff --git a/blog/2017/03/13/introducing-create-react-native-app.html b/blog/2017/03/13/introducing-create-react-native-app.html new file mode 100644 index 00000000000..713e4401100 --- /dev/null +++ b/blog/2017/03/13/introducing-create-react-native-app.html @@ -0,0 +1,22 @@ +Introducing Create React Native App
React Native Blog
Stay up-to-date with the latest React Native news and events.

Introducing Create React Native App

Today we’re announcing Create React Native App: a new tool that makes it significantly easier to get started with a React Native project! It’s heavily inspired by the design of Create React App and is the product of a collaboration between Facebook and Expo (formerly Exponent).

Many developers struggle with installing and configuring React Native’s current native build dependencies, especially for Android. With Create React Native App, there’s no need to use Xcode or Android Studio, and you can develop for your iOS device using Linux or Windows. This is accomplished using the Expo app, which loads and runs CRNA projects written in pure JavaScript without compiling any native code.

Try creating a new project (replace with suitable yarn commands if you have it installed):

$ npm i -g create-react-native-app +$ create-react-native-app my-project +$ cd my-project +$ npm start

This will start the React Native packager and print a QR code. Open it in the Expo app to load your JavaScript. Calls to console.log are forwarded to your terminal. You can make use of any standard React Native APIs as well as the Expo SDK.

What about native code? #

Many React Native projects have Java or Objective-C/Swift dependencies that need to be compiled. The Expo app does include APIs for camera, video, contacts, and more, and bundles popular libraries like Airbnb’s react-native-maps, or Facebook authentication. However if you need a native code dependency that Expo doesn’t bundle then you’ll probably need to have your own build configuration for it. Just like Create React App, “ejecting” is supported by CRNA.

You can run npm run eject to get a project very similar to what react-native init would generate. At that point you’ll need Xcode and/or Android Studio just as you would if you started with react-native init , adding libraries with react-native link will work, and you’ll have full control over the native code compilation process.

Questions? Feedback? #

Create React Native App is now stable enough for general use, which means we’re very eager to hear about your experience using it! You can find me on Twitter or open an issue on the GitHub repository. Pull requests are very welcome!

\ No newline at end of file diff --git a/blog/feed.xml b/blog/feed.xml index 524836fb49e..9c6d840bd93 100644 --- a/blog/feed.xml +++ b/blog/feed.xml @@ -2,12 +2,48 @@ https://facebook.github.io/react-native/blog/ React Native Blog - 2017-02-14T00:00:00Z + 2017-03-13T00:00:00Z The best place to stay up-to-date with the latest React Native news and events. https://facebook.github.io/react-native/img/header_logo.png Copyright © 2017 Facebook Inc. Feed for Node.js + + <![CDATA[Introducing Create React Native App]]> + https://facebook.github.io/react-native/blog/2017/03/13/introducing-create-react-native-app.html + + + 2017-03-13T00:00:00Z + + + Adam Perry + https://github.com/dikaiosune + + + + <![CDATA[idx: The Existential Function]]> + https://facebook.github.io/react-native/blog/2017/03/13/idx-the-existential-function.html + + + 2017-03-13T00:00:00Z + + + Timothy Yung + https://github.com/yungsters + + + + <![CDATA[Better List Views in React Native]]> + https://facebook.github.io/react-native/blog/2017/03/13/better-list-views.html + + + 2017-03-13T00:00:00Z + + + Spencer Ahrens + https://github.com/sahrens + + <![CDATA[Using Native Driver for Animated]]> https://facebook.github.io/react-native/blog/2017/02/14/using-native-driver-for-animated.html diff --git a/blog/index.html b/blog/index.html index 0c9bec97cac..38924a70048 100644 --- a/blog/index.html +++ b/blog/index.html @@ -1,4 +1,4 @@ -React Native Blog
React Native Blog
Stay up-to-date with the latest React Native news and events.

Using Native Driver for Animated

For the past year, we've been working on improving performance of animations that use the Animated library. Animations are very important to create a beautiful user experience but can also be hard to do right. We want to make it easy for developers to create performant animations without having to worry about some of their code causing it to lag.

A Monthly Release Cadence: Releasing December and January RC

Shortly after React Native was introduced, we started releasing every two weeks to help the community adopt new features, while keeping versions stable for production use. At Facebook we had to stabilize the codebase every two weeks for the release of our production iOS apps, so we decided to release the open source versions at the same pace. Now, many of the Facebook apps ship once per week, especially on Android. Because we ship from master weekly, we need to keep it quite stable. So the bi-weekly release cadence doesn't even benefit internal contributors anymore.

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.

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

Introducing Create React Native App

Today we’re announcing Create React Native App: a new tool that makes it significantly easier to get started with a React Native project! It’s heavily inspired by the design of Create React App and is the product of a collaboration between Facebook and Expo (formerly Exponent).

idx: The Existential Function

At Facebook, we often need to access deeply nested values in data structures fetched with GraphQL. On the way to accessing these deeply nested values, it is common for one or more intermediate fields to be nullable. These intermediate fields may be null for a variety of reasons, from failed privacy checks to the mere fact that null happens to be the most flexible way to represent non-fatal errors.

Better List Views in React Native

Many of you have started playing with some of our new List components already after our teaser announcement in the community group, but we are officially announcing them today! No more ListViews or DataSources, stale rows, ignored bugs, or excessive memory consumption - with the latest React Native March 2017 release candidate (0.43-rc.1) you can pick from the new suite of components what best fits your use-case, with great perf and feature sets out of the box:

Using Native Driver for Animated

For the past year, we've been working on improving performance of animations that use the Animated library. Animations are very important to create a beautiful user experience but can also be hard to do right. We want to make it easy for developers to create performant animations without having to worry about some of their code causing it to lag.

A Monthly Release Cadence: Releasing December and January RC

Shortly after React Native was introduced, we started releasing every two weeks to help the community adopt new features, while keeping versions stable for production use. At Facebook we had to stabilize the codebase every two weeks for the release of our production iOS apps, so we decided to release the open source versions at the same pace. Now, many of the Facebook apps ship once per week, especially on Android. Because we ship from master weekly, we need to keep it quite stable. So the bi-weekly release cadence doesn't even benefit internal contributors anymore.

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.

Troubleshooting #

These are some common issues you may run into while setting up React Native. If you encounter something that is not listed here, try searching for the issue in GitHub.

Port already in use #

The React Native packager runs on port 8081. If another process is already using that port (such as McAfee Antivirus on Windows), you can either terminate that process, or change the port that the packager uses.

Terminating a process on port 8081 #

Run the following command on a Mac to find the id for the process that is listening on port 8081:

$ sudo lsof -i :8081

Then run the following to terminate the process:

$ kill -9 <PID>

On Windows you can find the process using port 8081 using Resource Monitor and stop it using Task Manager.

Using a port other than 8081 #

You can configure the packager to use a port other than 8081 by using the port parameter:

$ react-native start --port=8088

You will also need to update your applications to load the JavaScript bundle from the new port. Open the in-app Developer menu, then go to Dev SettingsDebug server host for device and replace 8081 with your port of choice.

NPM locking error #

If you encounter an error such as "npm WARN locking Error: EACCES" while using the React Native CLI, try running the following:

sudo chown -R $USER ~/.npm +Troubleshooting

Troubleshooting #

These are some common issues you may run into while setting up React Native. If you encounter something that is not listed here, try searching for the issue in GitHub.

Port already in use #

The React Native packager runs on port 8081. If another process is already using that port (such as McAfee Antivirus on Windows), you can either terminate that process, or change the port that the packager uses.

Terminating a process on port 8081 #

Run the following command on a Mac to find the id for the process that is listening on port 8081:

$ sudo lsof -i :8081

Then run the following to terminate the process:

$ kill -9 <PID>

On Windows you can find the process using port 8081 using Resource Monitor and stop it using Task Manager.

Using a port other than 8081 #

You can configure the packager to use a port other than 8081 by using the port parameter:

$ react-native start --port=8088

You will also need to update your applications to load the JavaScript bundle from the new port. Open the in-app Developer menu, then go to Dev SettingsDebug server host for device and replace 8081 with your port of choice.

NPM locking error #

If you encounter an error such as npm WARN locking Error: EACCES while using the React Native CLI, try running the following:

sudo chown -R $USER ~/.npm sudo chown -R $USER /usr/local/lib/node_modules

Missing libraries for React #

If you added React Native manually to your project, make sure you have included all the relevant dependencies that you are using, like RCTText.xcodeproj, RCTImage.xcodeproj. Next, the binaries built by these dependencies have to be linked to your app binary. Use the Linked Frameworks and Binaries section in the Xcode project settings. More detailed steps are here: Linking Libraries.

If you are using CocoaPods, verify that you have added React along with the subspecs to the Podfile. For example, if you were using the <Text />, <Image /> and fetch() APIs, you would need to add these in your Podfile:

pod 'React', :path => '../node_modules/react-native', :subspecs => [ 'RCTText', 'RCTImage', diff --git a/releases/next/docs/virtualizedlist.html b/releases/next/docs/virtualizedlist.html index 948d566f048..8b85c8d0d42 100644 --- a/releases/next/docs/virtualizedlist.html +++ b/releases/next/docs/virtualizedlist.html @@ -15,7 +15,7 @@ blank content. This is a tradeoff that can be adjusted to suit the needs of each and we are working on improving it behind the scenes.
  • By default, the list looks for a key prop on each item and uses that for the React key. Alternatively, you can provide a custom keyExtractor prop.
  • NOTE: LayoutAnimation and sticky section headers both have bugs when used with this and are therefore not officially supported yet.

    NOTE: removeClippedSubviews might not be necessary and may cause bugs. If you see issues with -content not rendering, try disabling it, and we may change the default there.

    Props #

    FooterComponent?: ?ReactClass<any> #

    HeaderComponent?: ?ReactClass<any> #

    SeparatorComponent?: ?ReactClass<any> #

    data?: any #

    The default accessor functions assume this is an Array<{key: string}> but you can override +content not rendering, try disabling it, and we may change the default there.

    Props #

    data?: any #

    The default accessor functions assume this is an Array<{key: string}> but you can override getItem, getItemCount, and keyExtractor to handle any type of index-based data.

    debug?: ?boolean #

    debug will turn on extra logging and visual overlays to aid with debugging both usage and implementation, but with a significant perf hit.

    disableVirtualization: boolean #

    DEPRECATED: Virtualization provides significant performance and memory optimizations, but fully unmounts react instances that are outside of the render window. You should only need to disable diff --git a/versions.html b/versions.html index da5fec0082c..ecbabafd055 100644 --- a/versions.html +++ b/versions.html @@ -1,4 +1,4 @@ -React Native Versions

    React Native Versions

    React Native follows a monthly release train. Every month, a new branch created off master enters the Release Candidate phase, and the previous Release Candidate branch is released and considered stable.

    Current Version (Stable)

    0.42DocumentationRelease Notes

    This is the version that is configured automatically when you run react-native init. We highly recommend using the current version of React Native when starting a new project.

    If you have an existing project that uses React Native, read the release notes to learn about new features and fixes. You can follow our guide to upgrade your app to the latest version.

    Pre-release Versions

    masterDocumentation
    0.43-RCDocumentationRelease Notes

    For those who live on the bleeding edge. Only recommended if you're actively contributing code to React Native, or if you need to verify how your application behaves in an upcoming release.

    Past Versions

    0.41DocumentationRelease Notes
    0.40DocumentationRelease Notes
    0.39DocumentationRelease Notes
    0.38DocumentationRelease Notes
    0.37DocumentationRelease Notes
    0.36DocumentationRelease Notes
    0.35DocumentationRelease Notes
    0.34DocumentationRelease Notes
    0.33DocumentationRelease Notes
    0.32DocumentationRelease Notes
    0.31DocumentationRelease Notes
    0.30DocumentationRelease Notes
    0.29DocumentationRelease Notes
    0.28DocumentationRelease Notes
    0.27DocumentationRelease Notes
    0.26DocumentationRelease Notes
    0.25DocumentationRelease Notes
    0.24DocumentationRelease Notes
    0.23DocumentationRelease Notes
    0.22DocumentationRelease Notes
    0.21DocumentationRelease Notes
    0.20DocumentationRelease Notes
    0.19DocumentationRelease Notes
    0.18DocumentationRelease Notes

    You can find past versions of React Native on GitHub. The release notes can be useful if you would like to learn when a specific feature or fix was released.

    You can also view the docs for a particular version of React Native by clicking on the Docs link next to the release in this page. You can come back to this page and switch the version of the docs you're reading at any time by clicking on the version number at the top of the page.

    React Native Versions

    React Native follows a monthly release train. Every month, a new branch created off master enters the Release Candidate phase, and the previous Release Candidate branch is released and considered stable.

    Current Version (Stable)

    0.42DocumentationRelease Notes

    This is the version that is configured automatically when you run react-native init. We highly recommend using the current version of React Native when starting a new project.

    If you have an existing project that uses React Native, read the release notes to learn about new features and fixes. You can follow our guide to upgrade your app to the latest version.

    Pre-release Versions

    masterDocumentation
    0.43-RCDocumentationRelease Notes

    For those who live on the bleeding edge. Only recommended if you're actively contributing code to React Native, or if you need to verify how your application behaves in an upcoming release.

    Past Versions

    0.41DocumentationRelease Notes
    0.40DocumentationRelease Notes
    0.39DocumentationRelease Notes
    0.38DocumentationRelease Notes
    0.37DocumentationRelease Notes
    0.36DocumentationRelease Notes
    0.35DocumentationRelease Notes
    0.34DocumentationRelease Notes
    0.33DocumentationRelease Notes
    0.32DocumentationRelease Notes
    0.31DocumentationRelease Notes
    0.30DocumentationRelease Notes
    0.29DocumentationRelease Notes
    0.28DocumentationRelease Notes
    0.27DocumentationRelease Notes
    0.26DocumentationRelease Notes
    0.25DocumentationRelease Notes
    0.24DocumentationRelease Notes
    0.23DocumentationRelease Notes
    0.22DocumentationRelease Notes
    0.21DocumentationRelease Notes
    0.20DocumentationRelease Notes
    0.19DocumentationRelease Notes
    0.18DocumentationRelease Notes

    You can find past versions of React Native on GitHub. The release notes can be useful if you would like to learn when a specific feature or fix was released.

    You can also view the docs for a particular version of React Native by clicking on the Docs link next to the release in this page. You can come back to this page and switch the version of the docs you're reading at any time by clicking on the version number at the top of the page.

    \ No newline at end of file