status-im
/
react-native
mirror of https://github.com/status-im/react-native.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Cleanup doc text.

This commit is contained in:
Spencer Ahrens 2015-03-16 11:49:31 -07:00
parent 85a13b48eb
commit 9b95a896e9
4 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/Image.md
View File

@ -8,7 +8,7 @@ In React Native, this behavior is intentionally not implemented. It is more work
## Background Image via Nesting
A common feature request from developers familiar with the web is `background-image`. It turns out that iOS has a very elegant solution to this: you can add elements as a children to an `<Image>` component. This simplifies the API and solves the use case.
A common feature request from developers familiar with the web is `background-image`. To handle this use case, simply create a normal `<Image>` component and add whatever children to it you would like to layer on top of it.
```javascript
return (
@ -24,7 +24,7 @@ Image decoding can take more than a frame-worth of time. This is one of the majo
## Static Assets
In the course of a project you add and remove images and in many instances, you end up shipping images you are not using anymore in the app. In order to fight this, we need to find a way to know statically which images are being used in the app. To do that, we introduced a marker called `ix`. The only allowed way to refer to an image in the bundle is to literally write `ix('name-of-the-asset')` in the source.
In the course of a project, it is not uncommon to add and remove many images and accidentally end up shipping images you are no longer using in the app. In order to fight this, we need to find a way to know statically which images are being used in the app. To do that, we introduced a marker called `ix`. The only allowed way to refer to an image in the bundle is to literally write `ix('name-of-the-asset')` in the source.
```javascript
var { ix } = React;
@ -55,6 +55,6 @@ In React Native, one interesting decision is that the `src` attribute is named `
<Image source={{uri: 'something.jpg'}} />
```
On the infrastructure side, the reason is that it allows to attach metadata to this object. For example if you are using `ix`, then we add a `isStored` attribute to flag it as a local file (don't rely on this fact, it's likely to change in the future!). This is also future proofing, for example we may want to support sprites at some point, instead of outputting `{uri: ...}`, we can output `{uri: ..., crop: {left: 10, top: 50, width: 20, height: 40}}` and transparently support spriting on all the existing call sites.
On the infrastructure side, the reason is that it allows to attach metadata to this object. For example if you are using `ix`, then we add an `isStatic` attribute to flag it as a local file (don't rely on this fact, it's likely to change in the future!). This is also future proofing, for example we may want to support sprites at some point, instead of outputting `{uri: ...}`, we can output `{uri: ..., crop: {left: 10, top: 50, width: 20, height: 40}}` and transparently support spriting on all the existing call sites.
On the user side, this lets you annotate the object with useful attributes such as the dimension of the image in order to compute the size it's going to be displayed in. Feel free to use it as your data structure to store more information about your image.

10
docs/Network.md
View File

@ -7,11 +7,11 @@ permalink: docs/network.html
next: pixels
---
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.
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](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html). 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](http://en.wikipedia.org/wiki/Cross-origin_resource_sharing).
XMLHttpRequest API is implemented on-top of [iOS networking apis](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html). 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](http://en.wikipedia.org/wiki/Cross-origin_resource_sharing).
```javascript
var request = new XMLHttpRequest();
@ -31,13 +31,13 @@ request.open('GET', 'https://mywebsite.com/endpoint.php');
request.send();
```
Please follow the [MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) for a description of the API.
Please follow the [MDN Documentation](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) 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 one gives you the ability to use third-party libraries such as [Parse JS SDK](https://parse.com/docs/js_guide) or [super-agent](https://github.com/visionmedia/superagent) directly from npm.
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](https://parse.com/docs/js_guide) or [super-agent](https://github.com/visionmedia/superagent) directly from npm.
## Fetch
[fetch](https://fetch.spec.whatwg.org/) 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://fetch.spec.whatwg.org/) 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.
```javascript
fetch('https://mywebsite.com/endpoint.php')

4
docs/Physical vs Logical Pixels.md
View File

@ -10,7 +10,7 @@ next: style
## 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 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.
@ -20,7 +20,7 @@ In React Native, everything in JS and within the layout engine work with arbitra
## 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.
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.
```javascript
style={{ borderWidth: 1 / PixelRatio.get() }}

4
docs/Timers.md
View File

@ -20,12 +20,12 @@ Timers are an important part of an application and React Native implements the [
`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.
The `Promise` implementation uses `setImmediate` as 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.
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: