Cleanup stray markdown files, update contributing guidelines

Summary:
Several changes here. The `Text.md` and `PixelRatio.md` files were appended to the autodocs during site generation. This seemed excessive for just two files, so I've just merged the content into the autodocs themselves. It should help us simplify the website generation process in the future.

I've also merged IssueGuidelines.md and PullRequestGuidelines.md into the Contribution/Maintainers guidelines to improve their visibility.

Finally, I renamed Help to Community in the nav bar.

Ran the website locally, and verified every page rendered as expected: the Community page, Contributing page, Maintainers page.
Closes https://github.com/facebook/react-native/pull/15374

Differential Revision: D5567400

Pulled By: hramos

fbshipit-source-id: e06056edb12c9a17319fe1af46b2ef3a2e1b5854
This commit is contained in:
Hector Ramos 2017-08-04 16:14:25 -07:00 committed by Facebook Github Bot
parent 259eac8c30
commit 5be8c4af26
15 changed files with 350 additions and 305 deletions

View File

@ -16,22 +16,16 @@
If you answered "No":
We use GitHub Issues exclusively for tracking bugs in React Native. If you're looking for help,
check out the How to Get In Touch section of the following guide:
https://facebook.github.io/react-native/docs/contributing.html#how-to-get-in-touch
the Community page at http://facebook.github.io/react-native/support.html list various resources
that should help you get started.
Now scroll below!
-->
### Have you read the Bugs section of the How to Contribute guide?
### Have you read the [Contributing Guidelines](https://facebook.github.io/react-native/docs/contributing.html)?
(Write your answer here.)
<!--
Please read through the bug reporting guidelines thoroughly:
https://facebook.github.io/react-native/docs/contributing.html#bugs
-->
### Environment
<!--

View File

@ -1,9 +1,16 @@
<!--
Thank you for sending the PR!
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Help us understand your motivation by explaining why you decided to make this change.
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
(Write your motivation here.)
## Test Plan
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)

View File

@ -3,25 +3,25 @@
<!-- generated_contributing_start -->
React Native is one of Facebook's first open source projects that is both under very active development and is also being used to ship code to everybody using Facebook's mobile apps. If you're interested in contributing to React Native, hopefully this document makes the process for contributing clear.
Core contributors to React Native meet monthly and post their meeting notes on the [React Native blog](https://facebook.github.io/react-native/blog). You can also find ad hoc discussions in the [React Native Core Contributors](https://www.facebook.com/groups/reactnativeoss/) Facebook group.
## [Code of Conduct](https://code.facebook.com/codeofconduct)
Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read [the full text](https://code.facebook.com/codeofconduct) so that you can understand what actions will and will not be tolerated.
## How to contribute
## Get involved
There are many ways to contribute to React Native, and many of them do not involve writing any code. Here's a few ideas to get started:
* Simply start using React Native. Go through the [Getting Started](http://facebook.github.io/react-native/docs/getting-started.html) guide. Does everything work as expected? If not, we're always looking for improvements. Let us know by [opening an issue](http://facebook.github.io/react-native/docs/contributing.html#reporting-new-issues).
* Look through the [open issues](https://github.com/facebook/react-native/issues). Provide workarounds, ask for clarification, or suggest labels. Help [triage issues](http://facebook.github.io/react-native/docs/contributing.html#triaging-issues-and-pull-requests).
* If you find an issue you would like to fix, [open a pull request](http://facebook.github.io/react-native/docs/contributing.html#your-first-pull-request). Issues tagged as [`Good First Task`](https://github.com/facebook/react-native/labels/Good%20First%20Task) are a good place to get started.
* If you find an issue you would like to fix, [open a pull request](http://facebook.github.io/react-native/docs/contributing.html#your-first-pull-request). Issues tagged as [_Good First Task_](https://github.com/facebook/react-native/labels/Good%20First%20Task) are a good place to get started.
* Read through the [React Native docs](http://facebook.github.io/react-native/docs). If you find anything that is confusing or can be improved, you can make edits by clicking "Improve this page" at the bottom of most docs.
* Browse [Stack Overflow](https://stackoverflow.com/questions/tagged/react-native) and answer questions. This will help you get familiarized with common pitfalls or misunderstandings, which can be useful when contributing updates to the documentation.
* Take a look at the [features requested](https://react-native.canny.io/feature-requests) by others in the community and consider opening a pull request if you see something you want to work on.
Contributions are very welcome. If you think you need help planning your contribution, please hop into [#react-native](https://discord.gg/0ZcbPKXt5bZjGY5n) and let people know you're looking for a mentor.
Core contributors to React Native meet monthly and post their meeting notes on the [React Native blog](https://facebook.github.io/react-native/blog). You can also find ad hoc discussions in the [React Native Core Contributors](https://www.facebook.com/groups/reactnativeoss/) Facebook group.
### Triaging issues and pull requests
One great way you can contribute to the project without writing any code is to help triage issues and pull requests as they come in.
@ -31,10 +31,7 @@ One great way you can contribute to the project without writing any code is to h
* Flag issues that are stale or that should be closed.
* Ask for test plans and review code.
Adding labels, closing and reopening issues, and merging pull requests is, as you may expect, limited to a subset of contributors. Simply commenting on the issue or pull request can still go a long way towards helping us keep the number of outstanding issues under control.
Once you have become an active contributor in the community, you may gain access to the Facebook GitHub Bot, allowing you to perform some of these operations yourself. You can learn more about the bot in the [maintainer's guide](docs/maintainers.html#facebook-github-bot).
You can learn more about handling issues in the [maintainer's guide](docs/maintainers.html#handling-issues).
## Our development process
@ -52,7 +49,7 @@ To see what changes are coming and provide better feedback to React Native contr
We use [GitHub Issues](https://github.com/facebook/react-native/issues) for our public bugs. If you would like to report a problem, take a look around and see if someone already opened an issue about it. If you a are certain this is a new, unreported bug, you can submit a [bug report](http://facebook.github.io/react-native/docs/contributing.html#reporting-new-issues).
If you have questions about using React Native, the [help page](http://facebook.github.io/react-native/support.html) list various resources that should help you get started.
If you have questions about using React Native, the [Community page](http://facebook.github.io/react-native/support.html) list various resources that should help you get started.
We also have a [place where you can request features or enhancements](https://react-native.canny.io/feature-requests). If you see anything you'd like to be implemented, vote it up and explain your use case.
@ -87,7 +84,7 @@ We have a list of [beginner friendly issues](https://github.com/facebook/react-n
If you would like to request a new feature or enhancement but are not yet thinking about opening a pull request, we have a [place to track feature requests](https://react-native.canny.io/feature-requests).
If you intend to change the public API, or make any non-trivial changes to the implementation, we recommend [filing an issue](https://github.com/facebook/react-native/issues/new). This lets us reach an agreement on your proposal before you put significant effort into it.
If you intend to change the public API, or make any non-trivial changes to the implementation, we recommend [filing an issue](https://github.com/facebook/react-native/issues/new?title=%5BProposal%5D) that includes `[Proposal]` in the title. This lets us reach an agreement on your proposal before you put significant effort into it. These types of issues should be rare. If you have been contributing to the project long enough, you will probably already have access to the [React Native Core Contributors](https://www.facebook.com/groups/reactnativeoss/) Facebook Group, where this sort of discussion is usually held.
If you're only fixing a bug, it's fine to submit a pull request right away but we still recommend to file an issue detailing what you're fixing. This is helpful in case we don't accept that specific fix but want to keep track of the issue.
@ -100,7 +97,7 @@ Small pull requests are much easier to review and more likely to get merged. Mak
1. Fork [the repository](https://github.com/facebook/react-native) and create your branch from `master`.
2. Add the copyright notice to the top of any new files you've added.
3. Describe your [**test plan**](https://facebook.github.io/react-native/docs/contributing.html#test-plan) in your commit.
4. Ensure [**tests pass**](https://facebook.github.io/react-native/docs/contributing.html#continuous-integration-tests) on both Travis and Circle CI.
4. Ensure [**tests pass**](https://facebook.github.io/react-native/docs/contributing.html#contrinuous-integration-tests) on both Travis and Circle CI.
5. Make sure your code lints (`npm run lint`).
6. If you haven't already, [sign the CLA](https://code.facebook.com/cla).

View File

@ -50,9 +50,10 @@ const viewConfig = {
*
* `Text` supports nesting, styling, and touch handling.
*
* In the following example, the nested title and body text will inherit the `fontFamily` from
*`styles.baseText`, but the title provides its own additional styles. The title and body will
* stack on top of each other on account of the literal newlines:
* In the following example, the nested title and body text will inherit the
* `fontFamily` from `styles.baseText`, but the title provides its own
* additional styles. The title and body willstack on top of each other on
* account of the literal newlines:
*
* ```ReactNativeWebPlayer
* import React, { Component } from 'react';
@ -94,6 +95,194 @@ const viewConfig = {
* // skip this line if using Create React Native App
* AppRegistry.registerComponent('TextInANest', () => TextInANest);
* ```
*
* ## Nested text
*
* Both iOS and Android allow you to display formatted text by annotating
* ranges of a string with specific formatting like bold or colored text
* (`NSAttributedString` on iOS, `SpannableString` on Android). In practice,
* this is very tedious. For React Native, we decided to use web paradigm for
* this where you can nest text to achieve the same effect.
*
*
* ```ReactNativeWebPlayer
* import React, { Component } from 'react';
* import { AppRegistry, Text } from 'react-native';
*
* export default class BoldAndBeautiful extends Component {
* render() {
* return (
* <Text style={{fontWeight: 'bold'}}>
* I am bold
* <Text style={{color: 'red'}}>
* and red
* </Text>
* </Text>
* );
* }
* }
*
* // skip this line if using Create React Native App
* AppRegistry.registerComponent('AwesomeProject', () => BoldAndBeautiful);
* ```
*
* Behind the scenes, React Native converts this to a flat `NSAttributedString`
* or `SpannableString` that contains the following information:
*
* ```javascript
* "I am bold and red"
* 0-9: bold
* 9-17: bold, red
* ```
*
* ## Nested views (iOS only)
*
* On iOS, you can nest views within your Text component. Here's an example:
*
* ```ReactNativeWebPlayer
* import React, { Component } from 'react';
* import { AppRegistry, Text, View } from 'react-native';
*
* export default class BlueIsCool extends Component {
* render() {
* return (
* <Text>
* There is a blue square
* <View style={{width: 50, height: 50, backgroundColor: 'steelblue'}} />
* in between my text.
* </Text>
* );
* }
* }
*
* // skip this line if using Create React Native App
* AppRegistry.registerComponent('AwesomeProject', () => BlueIsCool);
* ```
*
* > In order to use this feature, you must give the view a `width` and a `height`.
*
* ## Containers
*
* The `<Text>` element is special relative to layout: everything inside is no
* longer using the flexbox layout but using text layout. This means that
* elements inside of a `<Text>` are no longer rectangles, but wrap when they
* see the end of the line.
*
* ```javascript
* <Text>
* <Text>First part and </Text>
* <Text>second part</Text>
* </Text>
* // Text container: all the text flows as if it was one
* // |First part |
* // |and second |
* // |part |
*
* <View>
* <Text>First part and </Text>
* <Text>second part</Text>
* </View>
* // View container: each text is its own block
* // |First part |
* // |and |
* // |second part|
* ```
*
* ## Limited Style Inheritance
*
* On the web, the usual way to set a font family and size for the entire
* document is to take advantage of inherited CSS properties like so:
*
* ```css
* html {
* font-family: 'lucida grande', tahoma, verdana, arial, sans-serif;
* font-size: 11px;
* color: #141823;
* }
* ```
*
* All elements in the document will inherit this font unless they or one of
* their parents specifies a new rule.
*
* In React Native, we are more strict about it: **you must wrap all the text
* nodes inside of a `<Text>` component**. You cannot have a text node directly
* under a `<View>`.
*
*
* ```javascript
* // BAD: will raise exception, can't have a text node as child of a <View>
* <View>
* Some text
* </View>
*
* // GOOD
* <View>
* <Text>
* Some text
* </Text>
* </View>
* ```
*
* You also lose the ability to set up a default font for an entire subtree.
* The recommended way to use consistent fonts and sizes across your
* application is to create a component `MyAppText` that includes them and use
* this component across your app. You can also use this component to make more
* specific components like `MyAppHeaderText` for other kinds of text.
*
* ```javascript
* <View>
* <MyAppText>Text styled with the default font for the entire application</MyAppText>
* <MyAppHeaderText>Text styled as a header</MyAppHeaderText>
* </View>
* ```
*
* Assuming that `MyAppText` is a component that simply renders out its
* children into a `Text` component with styling, then `MyAppHeaderText` can be
* defined as follows:
*
* ```javascript
* class MyAppHeaderText extends Component {
* render() {
* <MyAppText>
* <Text style={{fontSize: 20}}>
* {this.props.children}
* </Text>
* </MyAppText>
* }
* }
* ```
*
* Composing `MyAppText` in this way ensures that we get the styles from a
* top-level component, but leaves us the ability to add / override them in
* specific use cases.
*
* React Native still has the concept of style inheritance, but limited to text
* subtrees. In this case, the second part will be both bold and red.
*
* ```javascript
* <Text style={{fontWeight: 'bold'}}>
* I am bold
* <Text style={{color: 'red'}}>
* and red
* </Text>
* </Text>
* ```
*
* We believe that this more constrained way to style text will yield better
* apps:
*
* - (Developer) React components are designed with strong isolation in mind:
* You should be able to drop a component anywhere in your application,
* trusting that as long as the props are the same, it will look and behave the
* same way. Text properties that could inherit from outside of the props would
* break this isolation.
*
* - (Implementor) The implementation of React Native is also simplified. We do
* not need to have a `fontFamily` field on every single element, and we do not
* need to potentially traverse the tree up to the root every time we display a
* text node. The style inheritance is only encoded inside of the native Text
* component and doesn't leak to other components or the system itself.
*
*/
// $FlowFixMe(>=0.41.0)

View File

@ -16,7 +16,7 @@ var Dimensions = require('Dimensions');
/**
* PixelRatio class gives access to the device pixel density.
*
* ### Fetching a correctly sized image
* ## 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
@ -29,6 +29,33 @@ var Dimensions = require('Dimensions');
* });
* <Image source={image} style={{width: 200, height: 100}} />
* ```
*
* ## 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 JavaScript and within the layout engine works
* 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.
*
*/
class PixelRatio {
/**

View File

@ -4,31 +4,31 @@ title: How to Contribute
layout: docs
category: Contributing
permalink: docs/contributing.html
next: testing
next: maintainers
previous: upgrading
---
React Native is one of Facebook's first open source projects that is both under very active development and is also being used to ship code to everybody using Facebook's mobile apps. If you're interested in contributing to React Native, hopefully this document makes the process for contributing clear.
Core contributors to React Native meet monthly and post their meeting notes on the [React Native blog](https://facebook.github.io/react-native/blog). You can also find ad hoc discussions in the [React Native Core Contributors](https://www.facebook.com/groups/reactnativeoss/) Facebook group.
## [Code of Conduct](https://code.facebook.com/codeofconduct)
Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read [the full text](https://code.facebook.com/codeofconduct) so that you can understand what actions will and will not be tolerated.
## How to contribute
## Get involved
There are many ways to contribute to React Native, and many of them do not involve writing any code. Here's a few ideas to get started:
* Simply start using React Native. Go through the [Getting Started](http://facebook.github.io/react-native/docs/getting-started.html) guide. Does everything work as expected? If not, we're always looking for improvements. Let us know by [opening an issue](http://facebook.github.io/react-native/docs/contributing.html#reporting-new-issues).
* Look through the [open issues](https://github.com/facebook/react-native/issues). Provide workarounds, ask for clarification, or suggest labels. Help [triage issues](http://facebook.github.io/react-native/docs/contributing.html#triaging-issues-and-pull-requests).
* If you find an issue you would like to fix, [open a pull request](http://facebook.github.io/react-native/docs/contributing.html#your-first-pull-request). Issues tagged as [`Good First Task`](https://github.com/facebook/react-native/labels/Good%20First%20Task) are a good place to get started.
* If you find an issue you would like to fix, [open a pull request](http://facebook.github.io/react-native/docs/contributing.html#your-first-pull-request). Issues tagged as [_Good First Task_](https://github.com/facebook/react-native/labels/Good%20First%20Task) are a good place to get started.
* Read through the [React Native docs](http://facebook.github.io/react-native/docs). If you find anything that is confusing or can be improved, you can make edits by clicking "Improve this page" at the bottom of most docs.
* Browse [Stack Overflow](https://stackoverflow.com/questions/tagged/react-native) and answer questions. This will help you get familiarized with common pitfalls or misunderstandings, which can be useful when contributing updates to the documentation.
* Take a look at the [features requested](https://react-native.canny.io/feature-requests) by others in the community and consider opening a pull request if you see something you want to work on.
Contributions are very welcome. If you think you need help planning your contribution, please hop into [#react-native](https://discord.gg/0ZcbPKXt5bZjGY5n) and let people know you're looking for a mentor.
Core contributors to React Native meet monthly and post their meeting notes on the [React Native blog](https://facebook.github.io/react-native/blog). You can also find ad hoc discussions in the [React Native Core Contributors](https://www.facebook.com/groups/reactnativeoss/) Facebook group.
### Triaging issues and pull requests
One great way you can contribute to the project without writing any code is to help triage issues and pull requests as they come in.
@ -38,10 +38,7 @@ One great way you can contribute to the project without writing any code is to h
* Flag issues that are stale or that should be closed.
* Ask for test plans and review code.
Adding labels, closing and reopening issues, and merging pull requests is, as you may expect, limited to a subset of contributors. Simply commenting on the issue or pull request can still go a long way towards helping us keep the number of outstanding issues under control.
Once you have become an active contributor in the community, you may gain access to the Facebook GitHub Bot, allowing you to perform some of these operations yourself. You can learn more about the bot in the [maintainer's guide](docs/maintainers.html#facebook-github-bot).
You can learn more about handling issues in the [maintainer's guide](docs/maintainers.html#handling-issues).
## Our development process
@ -59,7 +56,7 @@ To see what changes are coming and provide better feedback to React Native contr
We use [GitHub Issues](https://github.com/facebook/react-native/issues) for our public bugs. If you would like to report a problem, take a look around and see if someone already opened an issue about it. If you a are certain this is a new, unreported bug, you can submit a [bug report](http://facebook.github.io/react-native/docs/contributing.html#reporting-new-issues).
If you have questions about using React Native, the [help page](http://facebook.github.io/react-native/support.html) list various resources that should help you get started.
If you have questions about using React Native, the [Community page](http://facebook.github.io/react-native/support.html) list various resources that should help you get started.
We also have a [place where you can request features or enhancements](https://react-native.canny.io/feature-requests). If you see anything you'd like to be implemented, vote it up and explain your use case.
@ -94,7 +91,7 @@ We have a list of [beginner friendly issues](https://github.com/facebook/react-n
If you would like to request a new feature or enhancement but are not yet thinking about opening a pull request, we have a [place to track feature requests](https://react-native.canny.io/feature-requests).
If you intend to change the public API, or make any non-trivial changes to the implementation, we recommend [filing an issue](https://github.com/facebook/react-native/issues/new). This lets us reach an agreement on your proposal before you put significant effort into it.
If you intend to change the public API, or make any non-trivial changes to the implementation, we recommend [filing an issue](https://github.com/facebook/react-native/issues/new?title=%5BProposal%5D) that includes `[Proposal]` in the title. This lets us reach an agreement on your proposal before you put significant effort into it. These types of issues should be rare. If you have been contributing to the project long enough, you will probably already have access to the [React Native Core Contributors](https://www.facebook.com/groups/reactnativeoss/) Facebook Group, where this sort of discussion is usually held.
If you're only fixing a bug, it's fine to submit a pull request right away but we still recommend to file an issue detailing what you're fixing. This is helpful in case we don't accept that specific fix but want to keep track of the issue.

View File

@ -1,6 +1,6 @@
---
id: integration-with-existing-apps
title: Integration With Existing Apps
title: Integration with Existing Apps
layout: docs
category: Guides
permalink: docs/integration-with-existing-apps.html

View File

@ -1,51 +0,0 @@
## Tips on managing GitHub issues efficiently
### An issue is a duplicate of another issue
Comment e.g. `@facebook-github-bot duplicate #123`. This will add a comment and close the issue.
Example: [#5977](https://github.com/facebook/react-native/issues/5977)
### An issue is a question
Questions should absolutely be asked on StackOverflow rather than GitHub.
Comment `@facebook-github-bot stack-overflow` to close the issue.
Examples: [#6378](https://github.com/facebook/react-native/issues/6378), [#6015](https://github.com/facebook/react-native/issues/6015), [#6059](https://github.com/facebook/react-native/issues/6059), [#6062](https://github.com/facebook/react-native/issues/6062).
Feel free to also answer some [SO questions](stackoverflow.com/questions/tagged/react-native), you'll get rep :)
### An issue is a question that's been answered
Sometimes and issue has been resolved in the comments.
Comment `@facebook-github-bot answered` to close it.
Example: [#6045](https://github.com/facebook/react-native/issues/6045)
### An issue needs more information
It is impossible to understand and reproduce the issue without more information, e.g. a short code sample, screenshot.
Do the following:
- Explain what additional info you need to understand the issue
- Comment `@facebook-github-bot label Needs more information`
Examples: [#6056](https://github.com/facebook/react-native/issues/6056), [#6008](https://github.com/facebook/react-native/issues/6008), [#5491](https://github.com/facebook/react-native/issues/5491)
### An issue with label 'Needs more information' has been open for more than a week
Comment mentioning the author asking if they plan to provide the additional information. If they don't come back close the issue using `@facebook-github-bot no-reply`.
Example: [#6056](https://github.com/facebook/react-native/issues/6056)
### An issue is a valid bug report
Valid bug reports with good repro steps are some of the best issues! Thank the author for finding it, explain that React Native is a community project and **ask them if they would be up for sending a fix**.
### An issue is a feature request. The feature shouldn't be in the code and don't want to maintain it.
This especially includes **new modules** Facebook doesn't use in production. Explain that those modules should be released to npm separately and that everyone will still be able to use the module super easily that way.
### An issue is a feature request, you're pretty sure we should maintain this feature as part of RN
This should be rare - adding a new feature means maintaining it.
Tell the author something like: "Pull requests are welcome. In case you're not up for sending a PR, you should post to [Canny](https://react-native.canny.io/feature-requests). It has a voting system and if the feature gets upvoted enough it might get implemented."
### How to add a label
Add any relevant labels, for example 'Android', 'iOS'.
Comment e.g. `@facebook-github-bot label Android`
### How to reopen a closed issue
For example an issue was closed waiting for the author, the author replied and it turns out this is indeed a bug.
Comment `@facebook-github-bot reopen`
### What are all the available commands for the bot?
When you mention the bot, it follows the commands defined in [IssueCommands.txt](https://github.com/facebook/react-native/blob/master/bots/IssueCommands.txt).
### How can I help manage issues?
Thank you for wanting to take the time to help us with managing GitHub issues. To have access to the bot please add your GitHub username to the first line of [IssueCommands.txt](https://github.com/facebook/react-native/blob/master/bots/IssueCommands.txt), in alphabetical order, by submitting a Pull Request.

View File

@ -4,8 +4,8 @@ title: What to Expect from Maintainers
layout: docs
category: Contributing
permalink: docs/maintainers.html
next: understanding-cli
previous: testing
next: testing
previous: contributing
---
So you have read through the [contributor's guide](docs/contributing.html) and you're getting ready to send your first pull request. Perhaps you've found an issue in React Native and want to work with the maintainers to land a fix. Here's what you can expect to happen when you open an issue or send a pull request.
@ -19,42 +19,80 @@ We see dozens of new issues being created every day. In order to help maintainer
* New issues should follow the [Issue Template](https://github.com/facebook/react-native/blob/master/.github/ISSUE_TEMPLATE.md).
* Issues should provide clear, easy to follow steps alongside sample code to reproduce the issue. Ideally, provide a [Snack](http://snack.expo.io/).
Issues that do not meet the above criteria can be closed immediately, with a link to the [contributor's guide](docs/contributing.html).
### Issues should be reproducible
Issues should be relatively easy to reproduce. Sometimes the issue affects a particular app but a minimal repro is not provided, perhaps a crash is seen in the logs and the author is not sure where its coming from, maybe the issue is sporadic.
As it happens, if a maintainer cannot easily reproduce the issue, one cannot reasonably expect them to be able to work on a fix. These issues can be closed with a short explanation why.
Exceptions can be made if multiple people appear to be affected by the issue, especially right after a new React Native release is cut.
Issues that do not meet the above criteria can be closed immediately, with a link to the [contributor's guide](docs/contributing.html).
### New issue runbook
You have gathered all the information required to open a new issue, and you are confident it meets the [contributor guidelines](docs/contributing.html). Once you post an issue, this is what our maintainers will consider when deciding how to move forward:
1. Is this issue a feature request? If so, they will ask you to use Canny for feature requests by issuing the `@facebook-github-bot feature` command, closing the issue.
2. Is this issue a request for help? If so, the maintainer will encourage you to ask on Stack Overflow by issuing the `@facebook-github-bot stack-overflow` command, closing the issue.
3. Was the [Issue Template](https://github.com/facebook/react-native/blob/master/.github/ISSUE_TEMPLATE.md) used to fill out the issue? Did the author answer Yes to both questions at the top? If not, the maintainer will ask you to provide more information by issuing the `@facebook-github-bot no-template` command, closing the issue.
4. Does the issue include a Snack or list of steps to reproduce the issue? If not, a maintainer will ask for a repro by issuing the `@facebook-github-bot needs-repro` command.
5. Can the issue be reliably reproduced? If not, a maintainer may issue the `@facebook-github-bot cannot-repro` command, closing the issue.
6. Is the issue for an old release of React Native? If so, expect to be asked if the issue can be reproduced in the latest release candidate.
* **Is this issue a feature request?**
You can learn more about how GitHub Bot commands are used [here](docs/maintainers.html#facebook-github-bot).
Some features may not be a good fit for the core React Native library. This is usually the case for **new modules* that Facebook does not use in production. In this case, a maintainer will explain that this should be released to npm as a separate module, allowing users to easily pull in the module in their projects.
Even if the feature does belong in the core library, adding it means maintaining it. A maintainer will encourage you to submit a pull request or otherwise post your request to [Canny](https://react-native.canny.io/feature-requests) by issuing the `@facebook-github-bot feature` command, closing the issue.
An exception can be made for proposals and long-running discussions, though these should be rare. If you have been contributing to the project long enough, you will probably already have access to the [React Native Core Contributors](https://www.facebook.com/groups/reactnativeoss/) Facebook Group, where this sort of discussion is usually held.
* **Is this issue a request for help?**
Questions should absolutely be asked on Stack Overflow rather than GitHub. Maintainers may encourage you to ask on Stack Overflow by issuing the `@facebook-github-bot stack-overflow` command, closing the issue.
Feel free to also answer some [questions on Stack Overflow](stackoverflow.com/questions/tagged/react-native), you'll get rep!
* **Was the [Issue Template](https://github.com/facebook/react-native/blob/master/.github/ISSUE_TEMPLATE.md) used to fill out the issue? Did the author answer Yes to both questions at the top?**
If not, the maintainer will ask you to provide more information by issuing the `@facebook-github-bot no-template` command, closing the issue.
* **Is the issue a duplicate of an existing, open issue?**
A maintainer will use the `@facebook-github-bot duplicate #123` command to mark the issue as a duplicate of issue #123, closing it.
* **Does the issue include a Snack or list of steps to reproduce the issue?**
Issues should be relatively easy to reproduce. Sometimes the issue affects a particular app but a minimal repro is not provided, perhaps a crash is seen in the logs and the author is not sure where its coming from, maybe the issue is sporadic.
As it happens, if a maintainer cannot easily reproduce the issue, one cannot reasonably expect them to be able to work on a fix. These issues can be closed by issuing the `@facebook-github-bot needs-repro` command.
Exceptions can be made if multiple people appear to be affected by the issue, especially right after a new React Native release is cut.
* **Is the issue for an old release of React Native?**
If so, expect to be asked if the issue can be reproduced in the latest release candidate.
* **Can the issue be reliably reproduced?**
If not, a maintainer may issue the `@facebook-github-bot cannot-repro` command, closing the issue.
* **Does the issue need more information?**
Some issues need additional information in order to reproduce them. Maintainers should explain what additional information is needed, using the `@facebook-github-bot label Needs more information` command to label the issue as such.
Issues with the 'Needs more information' label that have been open for more than a week without a response from the author can be closed using `@facebook-github-bot no-reply`.
* **Has the issue been resolved already in the comments?**
Sometimes another contributor has already provided a solution in the comments. Maintainers may issue the `@facebook-github-bot answered` command to close the issue.
> **Reopening a closed issue:** Sometimes it's necessary to reopen an issue. For example, if an issue was closed waiting for the author, then the author replied and it turns out this is indeed a bug, you can comment `@facebook-github-bot reopen` to reopen it.
Valid bug reports with good repro steps are some of the best issues! Maintainers should thank the author for finding the issue, then explain that React Native is a community project and **ask them if they would be up for sending a fix**.
### Triaging issues
If a issue is still open after going through all of the checks above, it will move on to the triage stage. A maintainer will then do the following:
1. Add relevant labels: iOS, Android, Tooling, Documentation. They will do so by issuing the `@facebook-github-bot label` command.
1. Add relevant labels. For example, if this is an issue that affects Android, use the `@facebook-github-bot label Android` command.
2. Leave a comment saying the issue has been triaged.
3. Tag the relevant people.
For example, if a issue describes something that needs to be addressed before the next release is cut, a maintainer may tag @grabbou. If the issue concerns Animated, they may tag @janicduplessis. If this is a docs issue, they may tag @hramos. You can generally figure out who is interested in what sort of issue by looking at the [CODEOWNERS](https://github.com/facebook/react-native/blob/master/.github/CODEOWNERS) file.
You can generally figure out who may be relevant for a given issue by looking at the [CODEOWNERS](https://github.com/facebook/react-native/blob/master/.github/CODEOWNERS) file.
#### What are all the available commands for the bot?
You can find the full command reference in the [Facebook GitHub Bot](/docs/maintainers.html#facebook-github-bot) section below.
### Stale issues
Issues that have been open for over six months and have had no activity in the last two months may be closed periodically. If your issue gets closed in this manner, it's nothing personal. If you strongly believe that the issue should remain open, just let us know why.
Issues in the "Needs more information" state may be closed after a week with no followup from the author. Issues that have have had no activity in the last two months may be closed periodically. If your issue gets closed in this manner, it's nothing personal. If you strongly believe that the issue should remain open, just let us know why.
Simply commenting that the issue still exists is not very compelling (it's rare for critical, release blocking issues to have no activity for two months!). In order to make a good case for reopening the issue, you may need to do a bit of work:
@ -64,7 +102,6 @@ Simply commenting that the issue still exists is not very compelling (it's rare
A couple of contributors making a good case may be all that is needed to reopen the issue.
## Handling pull requests
The core team will be monitoring for pull requests. When we get one, we'll run some Facebook-specific integration tests on it first. From here, we'll need to get another person to sign off on the changes and then merge the pull request. For API changes we may need to fix internal uses, which could cause some delay. We'll do our best to provide updates and feedback throughout the process.
@ -77,7 +114,40 @@ We use the [Contributors Chrome extension](https://github.com/hzoo/contributors-
Reviewing a PR can sometimes require more time from a maintainer than it took you to write the code. Maintainers need to consider all the ramifications of importing your patch into the codebase. Does it potentially introduce breaking changes? What are the performance considerations of adding a new dependency? Will the docs need to be updated as well? Does this belong in core, or would it be a better fit as a third party package?
Finding the right person to review a pull request can sometimes be tricky. A pull request may simultaneously touch iOS, Java, and JavaScript code. If a pull request has been waiting for review for a while, you can help out by looking at the blame history for the files you're touching. Is there anyone that appears to be knowledgeable in the part of the codebase the PR is touching?
Once you open a pull request, this is how you can expect maintainers to review it:
* **Is the pull request missing information?**
A test plan is required! Add the labels 'Needs revision' and 'Needs response from author'. You can then follow up with a response like:
> Hey @author, thanks for sending the pull request.
> Can you please add all the info specified in the [template](https://github.com/facebook/react-native/blob/master/.github/PULL_REQUEST_TEMPLATE.md)? This is necessary for people to be able to understand and review your pull request.
* **Does the code style match the [Style guide](docs/contributing.html#style-guide)?**
If not, link to the style guide and add the label 'Needs revision'.
* **Does the pull request add a completely new feature we don't want to add to the core and maintain?**
Ask the author to release it a separate npm module and close the pull request.
* **Does the pull request do several unrelated things at the same time?**
Ask the author to split it.
* **Is the pull request old and need rebasing?**
Ask the author "Can you rebase please?" and add the label 'Needs response from author'.
* **Is a pull request waiting for a response from author?**
Pull requests like these usually have the label 'Needs response from author'. If there has been no reply in the last 30 days, close it with a response like the following:
> Thanks for making the pull request, but we are closing it due to inactivity. If you want to get your proposed changes merged, please rebase your branch with master and send a new pull request.
* **Is the pull request old and waiting for review?**
Review it or cc someone who might be able to review. Finding the right person to review a pull request can sometimes be tricky. A pull request may simultaneously touch iOS, Java, and JavaScript code. If a pull request has been waiting for review for a while, you can help out by looking at the blame history for the files you're touching. Is there anyone that appears to be knowledgeable in the part of the codebase the PR is touching?
### Closing pull requests
@ -96,9 +166,8 @@ If a contributor becomes hostile or disrespectful, they will be referred to the
## Facebook GitHub Bot
The Facebook GitHub Bot allows certain active members of the community to perform administrative actions such as labeling and closing issues. The list of community members with this kind of access can be found at the top of the [IssueCommands.txt](https://github.com/facebook/react-native/blob/master/bots/IssueCommands.txt) file in the repository.
Once you have become an active contributor in the community, you may open a pull request to add yourself to the list, making sure to list your prior contributions to the community when doing so.
The Facebook GitHub Bot allows members of the community to perform administrative actions such as labeling and closing issues.
To have access to the bot, please add your GitHub username to the first line of [IssueCommands.txt](https://github.com/facebook/react-native/blob/master/bots/IssueCommands.txt), in alphabetical order, by submitting a Pull Request.
### Using the Facebook GitHub Bot

View File

@ -1,9 +0,0 @@
## 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.

View File

@ -1,18 +0,0 @@
## Tips on reviewing pull requests
Does the PR miss info required in the [Pull request template](https://github.com/facebook/react-native/blob/master/.github/PULL_REQUEST_TEMPLATE.md)? Example: [#6395](https://github.com/facebook/react-native/pull/6395). Add labels 'Needs revision' and 'Needs response from author'. Add a response like:
> Hey @author, thanks for sending the pull request.
> Can you please add all the info specified in the [template](https://github.com/facebook/react-native/blob/master/.github/PULL_REQUEST_TEMPLATE.md)? This is necessary for people to be able to understand and review your pull request.
Does the code style match the [Style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide), especially consistency (formatting, naming) with the rest of the codebase? If not, link to the style guide and add the label 'Needs revision'.
Does the pull request add a completely new feature we don't want to add to the core and maintain? Ask the author to release it a separate npm module and close the PR. Example: [#2648](https://github.com/facebook/react-native/pull/2648).
Does the pull request do several unrelated things at the same time? Ask the author to split it.
Is the PR old and need rebasing? Ask the author "Can you rebase please?" and add the label "Needs response from author".
Is a PR waiting for a response from author (usually has label "Needs response from author") and there's no reply in last 30 days? Close it with the [bookmarklet](https://github.com/facebook/react-native/blob/master/bots/pr-inactivity-bookmarklet.js). Examples: [#3066](https://github.com/facebook/react-native/pull/3066), [#1099](https://github.com/facebook/react-native/pull/1099).
Is the PR old and waiting for review? Review it or cc someone who might be able to review.

View File

@ -4,8 +4,8 @@ title: Testing your Changes
layout: docs
category: Contributing
permalink: docs/testing.html
next: maintainers
previous: contributing
next: understanding-cli
previous: maintainers
---
This document is about testing your changes to React Native as a [contributor](docs/contributing.html). If you're interested in testing a React Native app, check out the [React Native Tutorial](http://facebook.github.io/jest/docs/tutorial-react-native.html) on the Jest website.

View File

@ -1,157 +0,0 @@
## Nested Text
Both iOS and Android allow you to display formatted text by annotating ranges of a string with specific formatting like bold or colored text (`NSAttributedString` on iOS, `SpannableString` on Android). In practice, this is very tedious. For React Native, we decided to use web paradigm for this where you can nest text to achieve the same effect.
```ReactNativeWebPlayer
import React, { Component } from 'react';
import { AppRegistry, Text } from 'react-native';
export default class BoldAndBeautiful extends Component {
render() {
return (
<Text style={{fontWeight: 'bold'}}>
I am bold
<Text style={{color: 'red'}}>
and red
</Text>
</Text>
);
}
}
// skip this line if using Create React Native App
AppRegistry.registerComponent('AwesomeProject', () => BoldAndBeautiful);
```
Behind the scenes, React Native converts this to a flat `NSAttributedString` or `SpannableString` that contains the following information:
```javascript
"I am bold and red"
0-9: bold
9-17: bold, red
```
## Nested Views (iOS Only)
On iOS, you can nest views within your Text component. Here's an example:
```ReactNativeWebPlayer
import React, { Component } from 'react';
import { AppRegistry, Text, View } from 'react-native';
export default class BlueIsCool extends Component {
render() {
return (
<Text>
There is a blue square
<View style={{width: 50, height: 50, backgroundColor: 'steelblue'}} />
in between my text.
</Text>
);
}
}
// skip this line if using Create React Native App
AppRegistry.registerComponent('AwesomeProject', () => BlueIsCool);
```
> In order to use this feature, you must give the view a `width` and a `height`.
## Containers
The `<Text>` element is special relative to layout: everything inside is no longer using the flexbox layout but using text layout. This means that elements inside of a `<Text>` are no longer rectangles, but wrap when they see the end of the line.
```javascript
<Text>
<Text>First part and </Text>
<Text>second part</Text>
</Text>
// Text container: all the text flows as if it was one
// |First part |
// |and second |
// |part |
<View>
<Text>First part and </Text>
<Text>second part</Text>
</View>
// View container: each text is its own block
// |First part |
// |and |
// |second part|
```
## Limited Style Inheritance
On the web, the usual way to set a font family and size for the entire document is to take advantage of inherited CSS properties like so:
```css
/* CSS, *not* React Native */
html {
font-family: 'lucida grande', tahoma, verdana, arial, sans-serif;
font-size: 11px;
color: #141823;
}
```
All elements in the document will inherit this font unless they or one of their parents specifies a new rule.
In React Native, we are more strict about it: **you must wrap all the text nodes inside of a `<Text>` component**; you cannot have a text node directly under a `<View>`.
```javascript
// BAD: will raise exception, can't have a text node as child of a <View>
<View>
Some text
</View>
// GOOD
<View>
<Text>
Some text
</Text>
</View>
```
You also lose the ability to set up a default font for an entire subtree. The recommended way to use consistent fonts and sizes across your application is to create a component `MyAppText` that includes them and use this component across your app. You can also use this component to make more specific components like `MyAppHeaderText` for other kinds of text.
```javascript
<View>
<MyAppText>Text styled with the default font for the entire application</MyAppText>
<MyAppHeaderText>Text styled as a header</MyAppHeaderText>
</View>
```
Assuming that `MyAppText` is a component that simply renders out its children into a `Text` component with styling, then `MyAppHeaderText` can be defined as follows:
```javascript
class MyAppHeaderText extends Component {
render() {
<MyAppText>
<Text style={{fontSize: 20}}>
{this.props.children}
</Text>
</MyAppText>
}
}
```
Composing `MyAppText` in this way ensures that we get the styles from a top-level component, but leaves us the ability to add / override them in specific use cases.
React Native still has the concept of style inheritance, but limited to text subtrees. In this case, the second part will be both bold and red.
```javascript
<Text style={{fontWeight: 'bold'}}>
I am bold
<Text style={{color: 'red'}}>
and red
</Text>
</Text>
```
We believe that this more constrained way to style text will yield better apps:
- (Developer) React components are designed with strong isolation in mind: You should be able to drop a component anywhere in your application, trusting that as long as the props are the same, it will look and behave the same way. Text properties that could inherit from outside of the props would break this isolation.
- (Implementor) The implementation of React Native is also simplified. We do not need to have a `fontFamily` field on every single element, and we do not need to potentially traverse the tree up to the root every time we display a text node. The style inheritance is only encoded inside of the native Text component and doesn't leak to other components or the system itself.

View File

@ -15,7 +15,7 @@ var React = require('React');
var linksInternal = [
{section: 'docs', href: 'docs/getting-started.html', text: 'Docs', target: '.nav-docs'},
{section: 'support', href: '/react-native/support.html', text: 'Help'},
{section: 'support', href: '/react-native/support.html', text: 'Community'},
{section: 'blog', href: '/react-native/blog/', text: 'Blog'},
];

View File

@ -19,7 +19,7 @@ class support extends React.Component {
render() {
return (
<Site section="support" title="Help">
<Site section="support" title="Community">
<section
className="content wrap documentationContent helpSection nosidebar"
@ -64,7 +64,7 @@ class support extends React.Component {
<a
href="/react-native/docs/integration-with-existing-apps.html"
>
Integration With Existing Apps
Integrating with Existing Apps
</a>
</li>
</ul>