From d339be5f35f92b1dfd979b60a383de0e10fdd9a4 Mon Sep 17 00:00:00 2001 From: Travis CI Date: Tue, 17 Mar 2015 02:34:24 +0000 Subject: [PATCH] update website --- docs/activityindicatorios.html | 3 +-- docs/image.html | 6 +++--- docs/network.html | 4 ++-- docs/pixelratio.html | 20 ++++++++------------ docs/pixels.html | 2 +- docs/scrollview.html | 3 +-- docs/timers.html | 2 +- 7 files changed, 17 insertions(+), 23 deletions(-) diff --git a/docs/activityindicatorios.html b/docs/activityindicatorios.html index 47a2285ef67..4b494c3d65e 100644 --- a/docs/activityindicatorios.html +++ b/docs/activityindicatorios.html @@ -1,5 +1,4 @@ -React Native | Build Native Apps Using React
React Native

Quick Start

Guides

components

apis

ActivityIndicatorIOS

Props #

animating bool #

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

color string #

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

size enum(// default -'small', 'large') #

Next →
© 2015 Facebook Inc.
React Native

Quick Start

Guides

components

apis

ActivityIndicatorIOS

Props #

animating bool #

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

color string #

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

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

Next →
© 2015 Facebook Inc.
React Native

Quick Start

Guides

components

apis

Network

One of React Native goal is to be a playground where we can experiment with different architectures and crazy ideas. Since browsers are not flexible enough, we had no choice but to reimplement the entire stack. In the places that we did not intend to change, we tried to be as faithful as possible to the browser APIs, the networking stack is a great example.

XMLHttpRequest #

XMLHttpRequest API is implemented on-top of iOS networking apis. The notable difference from web is the security model: you can read from arbitrary websites on the internet, there isn't no concept of CORS.

var request = new XMLHttpRequest(); +React Native | Build Native Apps Using React
React Native

Quick Start

Guides

components

apis

Network

One of React Native goal is to be a playground where we can experiment with different architectures and crazy ideas. Since browsers are not flexible enough, we had no choice but to reimplement the entire stack. In the places that we did not intend to change, we tried to be as faithful as possible to the browser APIs. The networking stack is a great example.

XMLHttpRequest #

XMLHttpRequest API is implemented on-top of iOS networking apis. The notable difference from web is the security model: you can read from arbitrary websites on the internet since there is no concept of CORS.

var request = new XMLHttpRequest(); request.onreadystatechange = (e) => { if (request.readyState !== 4) { return; @@ -12,7 +12,7 @@ request.onreadystatechange }; request.open('GET', 'https://mywebsite.com/endpoint.php'); -request.send();

Please follow the MDN Documentation for a description of the API.

As a developer, you're probably not going to use XMLHttpRequest directly as its API is very tedious to work with. But the fact that it is implemented and compatible with the browser one gives you the ability to use third-party libraries such as Parse JS SDK or super-agent directly from npm.

Fetch #

fetch is a better API being worked on by the standard committee and already available in Chrome. It is available in React Native by default.

fetch('https://mywebsite.com/endpoint.php') +request.send();

Please follow the MDN Documentation for a complete description of the API.

As a developer, you're probably not going to use XMLHttpRequest directly as its API is very tedious to work with. But the fact that it is implemented and compatible with the browser API gives you the ability to use third-party libraries such as Parse JS SDK or super-agent directly from npm.

Fetch #

fetch is a better networking API being worked on by the standard committee and is already available in Chrome. It is available in React Native by default.

fetch('https://mywebsite.com/endpoint.php') .then((response) => response.text()) .then((responseText) => { console.log(responseText); diff --git a/docs/pixelratio.html b/docs/pixelratio.html index 994078ab3af..870c75e584e 100644 --- a/docs/pixelratio.html +++ b/docs/pixelratio.html @@ -1,16 +1,12 @@ -React Native | Build Native Apps Using React
React Native

Quick Start

Guides

components

apis

PixelRatio

PixelRatio class gives access to the device pixel density.

Some examples: - - PixelRatio.get() === 2 - - iPhone 4, 4S - - iPhone 5, 5c, 5s - - iPhone 6

  • PixelRatio.get() === 3
    • iPhone 6 plus

There are a few use cases for using PixelRatio:

== Displaying a line that's as thin as the device permits

A width of 1 is actually pretty thick on an iPhone 4+, we can do one that's -thinner using a width of 1 / PixelRatio.get(). It's a technique that works -on all the devices independent of their pixel density.

style={{ borderWidth: 1 / PixelRatio.get() }}

== Fetching a correctly sized image

You should get a higher resolution image if you are on a high pixel density +React Native | Build Native Apps Using React

React Native

Quick Start

Guides

components

apis

PixelRatio

PixelRatio class gives access to the device pixel density.

There are a few use cases for using PixelRatio:

Displaying a line that's as thin as the device permits #

A width of 1 is actually pretty thick on an iPhone 4+, we can do one that's +thinner using a width of 1 / PixelRatio.get(). It's a technique that works +on all the devices independent of their pixel density.

style={{ borderWidth: 1 / PixelRatio.get() }}

Fetching a correctly sized image #

You should get a higher resolution image if you are on a high pixel density device. A good rule of thumb is to multiply the size of the image you display -by the pixel ratio.

var image = getImage({ - width: 200 PixelRatio.get(), - height: 100 PixelRatio.get() - }); - <Image source={image} style={{width: 200, height: 100}} />

Methods #

static get() #

static startDetecting() #

Next →
© 2015 Facebook Inc.
React Native

Quick Start

Guides

components

apis

Physical vs Logical Pixels

Pixel Grid Snapping #

In iOS, you can specify positions and dimensions for elements with arbitrary precision, for example 29.674825. But, ultimately the physical display only have a fixed number of pixels, for example 640×960 for iphone 4 or 750×1334 for iphone 6. iOS tries to be as faithful as possible to the user value by spreading one original pixel into multiple ones to be trick the eye. The downside of this technique is that it makes the resulting element look blurry.

In practice, we found out that developers do not want this feature and they have to work around it by doing manual rounding in order to avoid having blurry elements. In React Native, we are rounding all the pixels automatically.

We have to be careful when to do this rounding. You never want to work with rounded and unrounded values at the same time as you're going to accumulate rounding errors. Having even one rounding error is deadly because a one pixel border may vanish or be twice as big.

In React Native, everything in JS and within the layout engine work with arbitrary precision numbers. It's only when we set the position and dimensions of the native element on the main thread that we round. Also, rounding is done relative to the root rather than the parent, again to avoid accumulating rounding errors.

Displaying a line that's as thin as the device permits #

A width of 1 is actually 2 physical pixels thick on an iPhone 4 and ~3 physical pixels thick on an iphone 6+. If you want to display a line that's as thin as possible, you can use a width of 1 / PixelRatio.get(). It's a technique that works on all the devices independent of their pixel density.

style={{ borderWidth: 1 / PixelRatio.get() }}

Fetching a correctly sized image #

You should get a higher resolution image if you are on a high pixel density device. A good rule of thumb is to multiply the size of the image you display by the pixel ratio.

var image = getImage({ +React Native | Build Native Apps Using React
React Native

Quick Start

Guides

components

apis

Physical vs Logical Pixels

Pixel Grid Snapping #

In iOS, you can specify positions and dimensions for elements with arbitrary precision, for example 29.674825. But, ultimately the physical display only have a fixed number of pixels, for example 640×960 for iphone 4 or 750×1334 for iphone 6. iOS tries to be as faithful as possible to the user value by spreading one original pixel into multiple ones to trick the eye. The downside of this technique is that it makes the resulting element look blurry.

In practice, we found out that developers do not want this feature and they have to work around it by doing manual rounding in order to avoid having blurry elements. In React Native, we are rounding all the pixels automatically.

We have to be careful when to do this rounding. You never want to work with rounded and unrounded values at the same time as you're going to accumulate rounding errors. Having even one rounding error is deadly because a one pixel border may vanish or be twice as big.

In React Native, everything in JS and within the layout engine work with arbitrary precision numbers. It's only when we set the position and dimensions of the native element on the main thread that we round. Also, rounding is done relative to the root rather than the parent, again to avoid accumulating rounding errors.

Displaying a line that's as thin as the device permits #

A width of 1 is actually 2 physical pixels thick on an iPhone 4 and 3 physical pixels thick on an iphone 6+. If you want to display a line that's as thin as possible, you can use a width of 1 / PixelRatio.get(). It's a technique that works on all the devices independent of their pixel density.

style={{ borderWidth: 1 / PixelRatio.get() }}

Fetching a correctly sized image #

You should get a higher resolution image if you are on a high pixel density device. A good rule of thumb is to multiply the size of the image you display by the pixel ratio.

var image = getImage({ width: 200 * PixelRatio.get(), height: 100 * PixelRatio.get(), }); diff --git a/docs/scrollview.html b/docs/scrollview.html index 4f3601af698..74b3c3a2358 100644 --- a/docs/scrollview.html +++ b/docs/scrollview.html @@ -21,8 +21,7 @@ wraps all of the child views. Example:

return ( decelerates after the user lifts their finger. Reasonable choices include - Normal: 0.998 (the default) - Fast: 0.9

horizontal bool #

When true, the scroll view's children are arranged horizontally in a row -instead of vertically in a column. The default value is false.

keyboardDismissMode enum(// default -'none', 'interactive', 'onDrag') #

Determines whether the keyboard gets dismissed in response to a drag. +instead of vertically in a column. The default value is false.

keyboardDismissMode enum("none", 'interactive', 'onDrag') #

Determines whether the keyboard gets dismissed in response to a drag. - 'none' (the default), drags do not dismiss the keyboard. - 'onDrag', the keyboard is dismissed when a drag begins. - 'interactive', the keyboard is dismissed interactively with the drag diff --git a/docs/timers.html b/docs/timers.html index d457d11db9a..0f6b1426393 100644 --- a/docs/timers.html +++ b/docs/timers.html @@ -1,4 +1,4 @@ -React Native | Build Native Apps Using React

React Native

Quick Start

Guides

components

apis

Timers

Timers are an important part of an application and React Native implements the browser timers.

Timers #

  • setTimeout, clearTimeout
  • setInterval, clearInterval
  • setImmediate, clearImmediate
  • requestAnimationFrame, cancelAnimationFrame

requestAnimationFrame(fn) is the exact equivalent of setTimeout(fn, 0), they are triggered right after the screen has been flushed.

setImmediate is executed at the end of the current JavaScript execution block, right before sending the batched response back to native. Note that if you call setImmediate within a setImmediate callback, it will be executed right away, it won't yield back to native in between.

The Promise implementation uses setImmediate its asynchronicity primitive.

InteractionManager #

One reason why native apps feel so good performance wise is that barely any work is being done during an interaction/animation. In React Native, you can use InteractionManager that allows long-running work to be scheduled after any interactions/animations have completed.

Applications can schedule tasks to run after interactions with the following:

InteractionManager.runAfterInteractions(() => { +React Native | Build Native Apps Using React
React Native

Quick Start

Guides

components

apis

Timers

Timers are an important part of an application and React Native implements the browser timers.

Timers #

  • setTimeout, clearTimeout
  • setInterval, clearInterval
  • setImmediate, clearImmediate
  • requestAnimationFrame, cancelAnimationFrame

requestAnimationFrame(fn) is the exact equivalent of setTimeout(fn, 0), they are triggered right after the screen has been flushed.

setImmediate is executed at the end of the current JavaScript execution block, right before sending the batched response back to native. Note that if you call setImmediate within a setImmediate callback, it will be executed right away, it won't yield back to native in between.

The Promise implementation uses setImmediate as its asynchronicity primitive.

InteractionManager #

One reason why well-built native apps feel so smooth is by avoiding expensive operations during interactions and animations. In React Native, we currently have a limitation that there is only a single JS execution thread, but you can use InteractionManager to make sure long-running work is scheduled to start after any interactions/animations have completed.

Applications can schedule tasks to run after interactions with the following:

InteractionManager.runAfterInteractions(() => { // ...long-running synchronous task... });

Compare this to other scheduling alternatives:

  • requestAnimationFrame(): for code that animates a view over time.
  • setImmediate/setTimeout/setInterval(): run code later, note this may delay animations.
  • runAfterInteractions(): run code later, without delaying active animations.

The touch handling system considers one or more active touches to be an 'interaction' and will delay runAfterInteractions() callbacks until all touches have ended or been cancelled.

InteractionManager also allows applications to register animations by creating an interaction 'handle' on animation start, and clearing it upon completion:

var handle = InteractionManager.createInteractionHandle(); // run animation... (`runAfterInteractions` tasks are queued)