Reviewed By: fromcelticpark

Differential Revision: D5536063

fbshipit-source-id: b0f19bebea839c7da84890c338ad4d38293bc99c

Reviewed By: leebyron

Differential Revision: D5748304

fbshipit-source-id: c66df45f1f35333f994c41eb8ff4cfccc1bb04d4

Summary:
Apps targeting Android 8.0 (API level 26) cannot use `TYPE_SYSTEM_OVERLAY ` and `TYPE_SYSTEM_OVERLAY `. Targeting 26 will cause the app to crash when in `DEV_MODE`.

https://developer.android.com/about/versions/oreo/android-8.0-changes.html#cwt

This PR replaces uses of these overlay flags with the new `TYPE_APPLICATION_OVERLAY` when running on a device with Android 8.0 or later.

When using `TYPE_APPLICATION_OVERLAY` it still requires the `SYSTEM_ALERT_WINDOW` permission, just like previous android versions.
https://developer.android.com/reference/android/view/WindowManager.LayoutParams.html#TYPE_APPLICATION_OVERLAY

https://github.com/AndrewJack/react-native-android-oreo tested here
Closes #15601

Reviewed By: achen1

Differential Revision: D5801619

Pulled By: shergin

fbshipit-source-id: 27d1b9bb64018e7f12f9c3d3d222f1fda468b124

Reviewed By: raluca-elena, TheSavior

Differential Revision: D5638532

fbshipit-source-id: 8db8210d0d0d08b9423b0a77f6b8e4e290f2eef0

Summary:
ReactRawTextShadowNode represents "raw" text node (aka textContent), so it cannot have layout or styling, it is just a line of text, a pure string.
So, we must not interit it from HUGE ReactTextShadowNode (which represents <Text> node with ReactRawTextShadowNode instance inside).
We need this change to make future fancy (and valuable from product perspective) refactoring possible. Stay tuned!

Reviewed By: achen1

Differential Revision: D5712961

fbshipit-source-id: 009e48046bdf34ddfd40b93175934969af64b98b

Summary:
Abstract class `ReactBaseTextShadowNode` was decoupled from `ReactTextShadowNode` to separate two goals/roles:
 * `ReactBaseTextShadowNode` represents spanned `<Text>` nodes, which can bear text attributes (both `RCTText` and `RCTVirtualText`);
 * `ReactTextShadowNode` represents anchor `<Text>` view in Yoga terms, which can bear layout attributes (`RCTText` and `RCTTextInput`).

`ReactVirtualTextShadowNode` now inherits `ReactBaseTextShadowNode`.
The same architectural changes was applited to view managers.

Why?
 * This is just a better architecture which represents the nature of this objects.
 * Bunch of "negative" logic which turn off excessive features for some suclasses was removed.
 * Memory efficiency.
 * Now we can improve `<TextInput>` component using right inheritance. Yay!

Reviewed By: achen1

Differential Revision: D5715830

fbshipit-source-id: ecc0764a03b5b7586fe77ad31f149cd840f4da41

Reviewed By: achen1

Differential Revision: D5807055

fbshipit-source-id: f79579d4cffb9792f49f89a7fb8f7df8e082a3a9

Summary:
Hi guys,

A small typo found in the doc :)
Closes #15888

Differential Revision: D5809251

Pulled By: TheSavior

fbshipit-source-id: 7a2ca8f2cbca81aa2059ee619a8c6087256e39a6

Summary:
This line accidentally became a no-op when the Map was converted to an Object.
Closes #15891

Differential Revision: D5811069

Pulled By: TheSavior

fbshipit-source-id: 43ac1835d15e2bee67ee45646bc238f917013836

Summary:
This diff renames all the stragglers in comments and strings from variations of "packager" to "Metro Bundler". I did one of three:

* Rename "packager" to "Metro Bundler"
* Rename "react-native-packager" to "Metro Bundler"
* Remove "packager" when code inside of Metro implies that it's about Metro

I also removed `Glossary.md` because it is unmaintained and very old. mjesun is currently starting to write documentation for Metro which will supersede whatever was there before.

Reviewed By: mjesun

Differential Revision: D5802993

fbshipit-source-id: ba99cb5ed04d84b0f7b7a8a0bf28ed99280a940a

Summary:
Previously type Options had excludeActivityTypes property, but in RCTActionSheetManager.m and docs this property is named excludedActivityTypes.

<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.

Help us understand your motivation by explaining why you decided to make this change.

You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html

Happy contributing!

-->

Want to fix error in flow types

Actually, it seems there aren't any need for test plan for this PR. Just fix a mistyping error.
Closes #15881

Differential Revision: D5813539

Pulled By: ericnakagawa

fbshipit-source-id: 7d1269d4c177f920869bf6554f14af6db7a741ee

Summary:
Updates the flow typing to return Promise\<string\> instead of Promise\<Object\>. To validate that it actually does return a string, see https://github.com/facebook/react-native/blob/6493a857542c0985470311511c1be80982fcd474/Libraries/CameraRoll/RCTCameraRollManager.m#L98 and https://github.com/facebook/react-native/blob/6493a857542c0985470311511c1be80982fcd474/Libraries/CameraRoll/RCTCameraRollManager.m#L116
Closes #15631

Differential Revision: D5714842

Pulled By: shergin

fbshipit-source-id: fb141b014c262bc4fb44419515e56bbe0641d8bf

Summary:
Node 8 is stable and newer and also gives us test coverage for npm 5, which is probably better to use for the E2E tests.
Closes #15904

Differential Revision: D5814784

Pulled By: hramos

fbshipit-source-id: 5b57293e804e1626fd20c200ed54c7210a6ad915

Summary:
**PR changes**
The RCTText class originally overrode the accessibilityLabel and returned the raw text of the class ignoring if the accessibilityLabel was set explicitly in code.
Example:
  <Text accessibilityLabel="Example"> Hello World </Text> // returns "Hello World" instead of "Example" for the accessibility label

My update checks if the super's accessibilityLabel is not nil and returns the value else it returns the raw text itself as a default to mirror what a UIKit's UILabel does. The super's accessibilityLabel is nil if the accessibilityLabel is not ever set in code. I don't check the length of the label because if the value was set to an empty purposely then it will respect that and return whatever was set in code.
With the new changes:
  <Text accessibilityLabel="Example"> Hello World </Text> // returns "Example" for the accessibilityLabel

This change doesn't support nested <Text> components with both accessibilityLabel's value set respectively. The parent's value will return.
Example:

  // returns "Example" instead of "Example Test" for the accessibility label
  <Text accessibilityLabel="Example">
    Hello
    <Text accessibilityLabel="Test">
      World
    </Text>
  </Text>

The workaround is just to set the only the parent view's accessibilityLabel with the label desired for it and all its nested views or just not nest the views if possible.
I believe a bigger change would be needed to support accessibility for nested views, for now the changes I have made should satisfy the requirements.

Reviewed By: shergin

Differential Revision: D5806097

fbshipit-source-id: aef2d7cec4657317fcd7dd557448905e4b767f1a

Summary:
Minor documentation correction for the native components iOS API section.

Before: "Sometimes your native component will have some special properties that you don't want to them to be part of the API"

After: "Sometimes your native component will have some special properties that you don't want to be part of the API"

Confirm section renders correctly via markdown.
Closes #15914

Reviewed By: TheSavior

Differential Revision: D5817146

Pulled By: buymeasoda

fbshipit-source-id: 075441cf7f5f23a4ca512bae48ca8fc319762b1e

Summary:
Currently, having the property `pointerEvents={'box-only'}` marks a view as layoutOnly. For optimization reasons, layoutOnly nodes are [not added to the node hierarchy](https://github.com/facebook/react-native/blob/b103903ec869bc48dfcaf001dc926957d0b5200a/ReactAndroid/src/main/java/com/facebook/react/uimanager/NativeViewHierarchyOptimizer.java#L99) The problem is that should this box ever need to be [transitioned to not-layout-only](https://github.com/facebook/react-native/blob/b103903ec869bc48dfcaf001dc926957d0b5200a/ReactAndroid/src/main/java/com/facebook/react/uimanager/NativeViewHierarchyOptimizer.java#L394) (for example, because you add the a CSS transform property),  it must be added to the hierarchy. To add it to the hierarchy the [React Styles Diff Map](https://github.com/facebook/react-native/blob/b103903ec869bc48dfcaf001dc926957d0b5200a/ReactAndroid/src/main/java/com/facebook/react/uimanager/NativeViewHierarchyOptimizer.java#L396) is passed along with the backing shadowNode to create the node. The problem is that at no point were the original `pointerEvents` and so the new node will be created with `pointerEvents =  'auto'`.

A more correct fix to this problem might be to have shadowNodes carry around their pointerEvents, although this is likely a greater design decision which is why am I proposing the quick fix now.

Will also resolve: react-native-modal/react-native-modal#11
Closes #15529

Reviewed By: AaaChiuuu

Differential Revision: D5792012

Pulled By: tomasreimers

fbshipit-source-id: 625242c53e16cb293c64811a57f6c3905b3483e0

Summary:
Remove fallback logic.
It is hard to test whether a bundle is good or bad on device, since it does the fallback, remove the fallback logic now.

Reviewed By: javache

Differential Revision: D5773542

fbshipit-source-id: 8bb4fdad4c5761ccce915f9f1c2577464e8d37d8

…red.

Summary:
**Problem:**

It was observed that in [this code path](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactHorizontalScrollView.java#L292) (i.e. horizontal, paging-enabled scroll view) if you tried to programmatically call the scrollTo method within ~1s of the onMomentumScrollEnd event (which should only be called after all scrolling has ended), the scrollView would scroll to the new location, and then scroll BACK to the original location.

For example, assume you had released the scrollView at location B, and the nearest page boundary is A. Then, 1000ms later, you call scrollTo position C. The order of operations would be:

1. Begin scrolling to A from position B (as it is the nearest page boundary)
2. Reach position A
3. Fire onMomentumScrollEnd
4. 1000ms later call scrollTo C
5. scrollView scrolls to C
6. scrollView scrolls BACK to position A (for no apparent reason).

**Reason:**

I suspect this is because the [smoothlyScrollTo](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactHorizontalScrollView.java#L292) will continue to animate towards A, but the [scrollEvents will not fire](https://github.com/facebook/react-native/blob/f954f3d9b674b13977f722bc3b8dc6c1b99fe6c7/ReactAndroid/src/main/java/com/facebook/react/views/scroll/OnScrollDispatchHelper.java#L45) as they are too close to each other. So the true order of events is:

1. Begin scrolling to A from position B (as it is the nearest page boundary)

[begin smoothlyScrollTo]
[scroll towards position A]
[mActivelyScrolling is true]

2. Reach position A

[mActivelyScrolling is true]
[scroll towards position A]
[mActivelyScrolling is false, as there is another scrollEvent, but because it is close enough to the same location it is ignored]

3. Fire onMomentumScrollEnd
4. 1000ms later call scrollTo C

[scroll towards position C]

5. scrollView scrolls to C

[scroll towards position A as the original smoothlyScrollTo animation was never completed]

6. scrollView scrolls BACK to position A.

This is an untested hypothesis, but seems to explain the behavior, and the solution is more semantically correct anyway. If there is an easy way to rebuild the android binaries happy to test it myself! Just let me know!

**Solution:**

 Move the mActivelyAnimating outside the mOnScrollDispatchHelper.onScrollChanged helper, because the HorizontalScrollView event should be considered to be animating so long as onScrollChanged events are being fired.
Closes #15146

Reviewed By: AaaChiuuu

Differential Revision: D5792026

Pulled By: tomasreimers

fbshipit-source-id: 9654fda038d4a687cc32f4c32dc312baa34627ed

Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.

Help us understand your motivation by explaining why you decided to make this change.

You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html

Happy contributing!

-->

Adding example with [react-native-web-player](https://github.com/dabbott/react-native-web-player)

Screenshot on http://localhost:8079/react-native/docs/touchableopacity.html
![react-native-touchableopacity](https://user-images.githubusercontent.com/13135332/30335218-bd32fb0e-9807-11e7-976d-5235402fdba8.png)
Closes #15911

Differential Revision: D5817180

Pulled By: TheSavior

fbshipit-source-id: 6399a53dabf8e3f0cf680aeb41d8afbaa2ce11e8

Reviewed By: dinhviethoa

Differential Revision: D5802851

fbshipit-source-id: 78e4b375bd0a0ed48d30bfb7fc746de6a2bd999e

Reviewed By: yungsters, TheSavior

Differential Revision: D5813153

fbshipit-source-id: f086e1fc5ea3d6fd9e6aa5fbd150d1ae9787cced

Summary:
This fixes the regression recently introduced during refactoring of text-related classes.
So, added fragment of code was lost in D5715830.
See how it looked before:
https://github.com/facebook/react-native/blob/9f5bdd7b497427506dab753ed12017900cb5ffe7/ReactAndroid/src/main/java/com/facebook/react/views/text/ReactTextShadowNode.java#L424-L431

Reviewed By: TheSavior

Differential Revision: D5827424

fbshipit-source-id: 5df99620057ff6a27105dd05903c7f5def85c5d2

Summary:
Fixing #13578

<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.

Help us understand your motivation by explaining why you decided to make this change.

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.)

(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!)
Closes #15419

Reviewed By: sahrens

Differential Revision: D5795844

Pulled By: tomasreimers

fbshipit-source-id: 4cdf97a2f5e83e38f4e12af771b512e7dddd212a

Summary:
iOS 11 now requires this to be accessed on the main thread.
I think this is causing tests to fail, as the Main Thread Checker is turned on there.

Reviewed By: javache

Differential Revision: D5826570

fbshipit-source-id: 6acb7174c756a2ad657602f14c666f71b1ee8fe9

Reviewed By: rachit-siamwalla

Differential Revision: D5828898

fbshipit-source-id: 23fa587bcd1d1b6c612cc816f1aa7b03da0c187d

…ules

Summary:
This PR refactors the symlink finding logic in local-cli in order to support nested symlinked modules as well as symlinked scoped NPM modules.

Run tests, or try project with `npm link`'ed or `yarn link`'ed dependencies.
Closes #15776

Reviewed By: cpojer

Differential Revision: D5823008

Pulled By: jeanlauliac

fbshipit-source-id: f2daeceef37bed2f8a136a0a5918730f9832884c

Summary: babel-plugin-react-transform@3 includes support for HMR on `React.PureComponent`: gaearon/babel-plugin-react-transform#106

Reviewed By: davidaurelio

Differential Revision: D5814322

fbshipit-source-id: 36e83ffa00f9d4ff079665aec1e8341725811a8e

Reviewed By: achen1

Differential Revision: D5830633

fbshipit-source-id: 3d0880656f14cfafa0f15c4341021799f20f40ed

Summary:
This avoids a crash when we try to load a PHAsset with nil image url. Specifically, the following condition evaluates to true when `imageURL` is nil:

```objc
if ([imageURL.scheme caseInsensitiveCompare:@"assets-library"] == NSOrderedSame) {
    assetID = [imageURL absoluteString];
    results = [PHAsset fetchAssetsWithALAssetURLs:@[imageURL] options:nil];
}
```

The crash will be "attempt to insert nil object from objects[0]" when we build the `@[imageURL]` array literal.

We've seen this emerge as a very common crash among Expo users, so I wanted to at least provide a clear error message instead of terminating the app.

Load an image from the photo library with a nil request url.
Closes #15952

Differential Revision: D5835219

Pulled By: ericnakagawa

fbshipit-source-id: 7be00a15e674a0905cf5c27c526ce9085d1b308f

Reviewed By: achen1

Differential Revision: D5740438

fbshipit-source-id: eca6160e0ff9089e1f70ead0f2269ce152258c19

…izations

Reviewed By: sophiebits

Differential Revision: D5626312

fbshipit-source-id: f8158ccb14f991b681fba34fb23933042266939d

Differential Revision: D5814210

fbshipit-source-id: 41291f0d6b39af77f66173f6a699d88f9f4ccc74

Reviewed By: davidaurelio

Differential Revision: D5834180

fbshipit-source-id: 121efc7000bff7aff121d44e6b0b8eed1d4e81ae

Reviewed By: davidaurelio

Differential Revision: D5832633

fbshipit-source-id: 8e4e0e6a2907e485a5627c87161af2d0672b4f56

Reviewed By: cwdick

Differential Revision: D5842135

fbshipit-source-id: e9c44c4129d4d10da8781798df121f5c676766f8

Reviewed By: emilsjolander

Differential Revision: D5842351

fbshipit-source-id: d2c2b6f829588a200525b7ccbdb63003cb4dcc4e

Reviewed By: weicool

Differential Revision: D5843154

fbshipit-source-id: 0729cb19e3b3664a235320e908af51b2f56cc4ae

Reviewed By: calebmer

Differential Revision: D5844473

fbshipit-source-id: 2893e5a5ee58d147a2f7d351143a7ce0eb8eebe3

Reviewed By: sophiebits

Differential Revision: D5846806

fbshipit-source-id: 7b0a54bd5a4b877f0c5915f11392ee0d34718dbe

Summary: Use <ImageBackground> instead.

Reviewed By: yungsters

Differential Revision: D5190170

fbshipit-source-id: 29acf99db9a31351dbfe8eeefa61abd439f8618c

…e order of spans

Summary:
When we convert nested <Text> components to Spannable object we must enforce the order of spans somehow,
otherwise we will have Spannable object with unpredictable order of spans, which will produce unpredictalbe text layout.
We can do it only using `Spannable.SPAN_PRIORITY` feature because Spannable objects do not maintain the order of spans internally.

We also have to fix this to implement autoexpandable <TextInput>.

Reviewed By: achen1

Differential Revision: D5811172

fbshipit-source-id: 5bc68b869e58aba27d6986581af9fe3343d116a7

Summary:
I noticed `uniq` does not take a second parameter the way it's being used here. I think the function what was intended is [uniqBy](https://lodash.com/docs/4.17.4#uniqBy)
Closes #15615

Differential Revision: D5852155

Pulled By: hramos

fbshipit-source-id: 892d0bf7f24d30c24620350f698ffb416907ccc5

Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.

Help us understand your motivation by explaining why you decided to make this change.

You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html

Happy contributing!

-->

Headless tasks are required to run in the main thread, however due to the nature of the React context creation flow, the handler may be returned outside of the main thread, causing the HeadlessJsTaskContext to throw an exception.

Swipe out the app. send push notification from a server that starts a HeadlessJsTaskService
Closes #15940

Differential Revision: D5852448

Pulled By: foghina

fbshipit-source-id: 54c58a1eb7434dd5de5c39c28f6e068ed15ead9d

Reviewed By: dcaspi

Differential Revision: D5850957

fbshipit-source-id: d2cacfd99fd7ffca70b0dcf0bf252ea160268c05

Reviewed By: dcaspi

Differential Revision: D5824552

fbshipit-source-id: a435fc0ad5b43a8bd3c6a873a4147c4d92190f4e

Reviewed By: javache

Differential Revision: D5843832

fbshipit-source-id: f4051755a5de83431f8bed1b765b5d8118b5ab88

Reviewed By: mmmulani

Differential Revision: D5851596

fbshipit-source-id: 952dc8af4ee2af4522725873187b6281b62642cc

…anager

Summary:
This should be much more performant (and it better illustrates the intension of the code).
The fix was suggested by Adlai-Holler.

Reviewed By: mmmulani

Differential Revision: D5851595

fbshipit-source-id: 45d172a5fa796549c6dcea8f35c5cbb2a4c2d2e0

Reviewed By: sophiebits

Differential Revision: D5853012

fbshipit-source-id: d0ebf12d2c801dc3e232fe18f9cc25e477812350

Reviewed By: amnn

Differential Revision: D5761937

fbshipit-source-id: de88cf8b959fc855c3c0786f817bb6032491c819

Reviewed By: mhorowitz

Differential Revision: D5785204

fbshipit-source-id: 4c5240f24c6a69bb781896d3af32d4d16fc2387c

Reviewed By: mhorowitz

Differential Revision: D5857012

fbshipit-source-id: 8c9fc0095c512325968234f48d6728b63d61913d

Reviewed By: AaaChiuuu

Differential Revision: D5855139

fbshipit-source-id: 3837769a4da90d9752de75669c6395fabcd3b18b

Reviewed By: yungsters

Differential Revision: D5857305

fbshipit-source-id: 2fc20a848fa4dce5c1ac3fb7e986536618e25548

Reviewed By: shergin

Differential Revision: D5854859

fbshipit-source-id: 96d4ced9f5481ae1df8741f9d09da4bc939e8ed8

Reviewed By: achen1

Differential Revision: D5855613

fbshipit-source-id: 2eac7ba6a9d95f6cd3a58a1df4ec0b170f34d6ed

Reviewed By: achen1

Differential Revision: D5854430

fbshipit-source-id: 1276f3d7e94b757f9a9dd412a2ef8b72e8427ffb

Reviewed By: AaaChiuuu

Differential Revision: D5861523

fbshipit-source-id: 39eb79b91d4d5e2295d03369f1be585ae7836c75

Reviewed By: achen1

Differential Revision: D5740501

fbshipit-source-id: 3a88cd95d3a58aac24968e577f4eb3096d47d4ec

Summary:
Native communication is documented for iOS but not Android. Typically pages in Guides (IOS) and Guides (Android) share a common structure/content but provide language specific examples.

I followed this pattern with the Android native communication documentation. It is missing some content that the iOS documentation contains, such as the layout computation flow. But provides a solid base for future efforts.

Ran local instance of React Native website. Went to http://localhost:8079 and read through the new page (react-native/docs/communication-android.html). Also tested links two/from the page.

As a result of this link testing, I updated the Native Modules Android documentation to link to the Apple TV documentation, as it is now the previous page on the navigation sidebar.
Closes #14316

Differential Revision: D5865137

Pulled By: hramos

fbshipit-source-id: 10ec7d2b08667e70bc38576ecc56da457859e8b1

Summary:
Looks like `-[NSLayoutManager ensureLayoutForTextContainer:textContainer]` has a bug that cause infinite loop inside this method
during measuring some special characters AND when specified `width` equals NaN (which is useless anyways).

So, we cover this case in this diff.

Reviewed By: javache

Differential Revision: D5859767

fbshipit-source-id: 58a5910f21f282bf5b82494916b5b02ad72d357f

Summary:
A huge number of Issues are opened with some key information about node/npm versions missing. Adding this information as a required part of the ISSUE_TEMPLATE may help issues get closed faster.

Once merged in, check ISSUE_TEMPLATE by opening new issue, verify new line is there.
Closes #14422

Differential Revision: D5865411

Pulled By: hramos

fbshipit-source-id: 70e776c8635de38fb149471656e6d260f9eb2537

Summary:
Related to commit/diff:
6e99e31#diff-692279cda23c48738b9688454811448a

The above change breaks "HelloWorld" demo in docs, as you can see at the bottom of the below screenshot:
![image](https://user-images.githubusercontent.com/5363847/30427914-9477d4ee-9949-11e7-8be6-3d6990d6e267.png)

This pull request reverts things just enough to get the demo working correctly again.

I'm new to react-native so I'm not sure if there is another (read: better) solution but by accepting this pull request it would prevent noobs like myself from falling at the first hurdle!
Closes #15947

Differential Revision: D5866110

Pulled By: hramos

fbshipit-source-id: a453e4373b8af528e3ef2fa6a5a029ff398b0398

Reviewed By: sophiebits

Differential Revision: D5860751

fbshipit-source-id: 634ccf22d40bf80eabed467cb1c874f5b02c4f8d

Summary:
Opening a new PR for #10946 (see discussion there).

This PR builds upon #14775 (iOS ViewManager inheritance) and #14261 (more extensible Android WebView).

**Motivation**
When `WebView.android.js` and `WebView.ios.js` use `requireNativeComponent`, they are hard-coded to require `RCTWebView`. This means if you want to re-use the same JS-logic, but require a custom native WebView-implementation, you have to duplicate the entire JS-code files.

The same is true if you want to pass through any custom events or props, which you want to set on the custom native `WebView`.

What I'm trying to solve with this PR is to able to extend native WebView logic, and being able to re-use and extend existing WebView JS-logic.

This is done by adding a new `nativeConfig` prop on WebView. I've also moved the  extra `requireNativeComponent` config to `WebView.extraNativeComponentConfig` for easier re-use.

**Test plan**
jacobp100 has been kind enough to help me with docs for this new feature. So that is part of the PR and can be read for some information.

I've also created an example app which demonstrates how to use this functionality: https://github.com/cbrevik/webview-native-config-example

If you've implemented the native side as in the example repo above, it should be fairly easy to use from JavaScript like this:
```javascript
import React, { Component, PropTypes } from 'react';
import { WebView, requireNativeComponent, NativeModules } from 'react-native';
const { CustomWebViewManager } = NativeModules;

export default class CustomWebView extends Component {
  static propTypes = {
    ...WebView.propTypes,
    finalUrl: PropTypes.string,
    onNavigationCompleted: PropTypes.func,
  };

  _onNavigationCompleted = (event) => {
    const { onNavigationCompleted } = this.props;
    onNavigationCompleted && onNavigationCompleted(event);
  }

  render() {
    return (
      <WebView
        {...this.props}
        nativeConfig={{
          component: RCTCustomWebView,
          props: {
            finalUrl: this.props.finalUrl,
            onNavigationCompleted: this._onNavigationCompleted,
          },
          viewManager: CustomWebViewManager
        }}
      />
    );
  }
}

const RCTCustomWebView = requireNativeComponent(
  'RCTCustomWebView',
  CustomWebView,
  WebView.extraNativeComponentConfig
);
```

As you see, you require the custom native implementation at the bottom, and send in that along with any custom props with the `nativeConfig` prop on the `WebView`. You also send in the `viewManager` since iOS requires that for `startLoadWithResult`.

**Discussion**
As noted in the original PR, this could in principle be done with more React Native components, to make it easier for the community to re-use and extend native components.
Closes #15016

Differential Revision: D5701280

Pulled By: hramos

fbshipit-source-id: 6c3702654339b037ee81d190c623b8857550e972

Differential Revision: D5839414

fbshipit-source-id: 7a0c7b3d27be728c74e08d3a8209deb3ca68dd63

Summary:
To fix this issue: #15791
Closes #15792

Differential Revision: D5813101

Pulled By: shergin

fbshipit-source-id: fd3eb6f1d9ccdeb5373d1ba2b2df173ff7a8e986

Reviewed By: mjmahone

Differential Revision: D5842774

fbshipit-source-id: 40c57619901e15b0baa62c59837fc887c100652b

Differential Revision: D5823786

fbshipit-source-id: d6a6e29b856361a6b1d5ab48397607a844b5ab53

Reviewed By: AaaChiuuu

Differential Revision: D5871546

fbshipit-source-id: 7c338fe3b747a79377a54867c789028d221b3dd5

Reviewed By: achen1

Differential Revision: D5740540

fbshipit-source-id: 9989424812fdcfd0a54c2ccf1e973aa7cc2a1f67

Summary:
This fixes shrinking of elements which are in a non stretch alignment

Fixes #633
Closes facebook/yoga#634

Differential Revision: D5874862

Pulled By: emilsjolander

fbshipit-source-id: 1426aa6b60f6ba42c2be702e6f24cea935ab7acb

…binations.

Summary:
Fixes #15863 on master. Behavior of `onSubmitEditing` is now consistent between iOS and Android. Tapping the submit button in a TextInput dispatches the event precisely when doing so does not make a newline (when blurOnSubmit is true or multiline is false).

1. Run this app on iOS and Android:
```
// flow

import React, { Component } from 'react';
import {
  StyleSheet,
  TextInput,
  View
} from 'react-native';

type State = {
  toggled: boolean
};

type Props = {
  blurOnSubmit: boolean,
  multiline: boolean
};

class ToggleColorInput extends Component<Props, State> {
  state: State = {
    toggled: false
  };

  props: Props;

  toggle = () => {
    this.setState({
      toggled: !this.state.toggled
    });
  }

  render() {
    return (
      <TextInput
        blurOnSubmit={this.props.blurOnSubmit}
        multiline={this.props.multiline}
        onSubmitEditing={this.toggle}
        style={[styles.textInput, {backgroundColor: this.state.toggled ? 'blue' : 'azure'}]}
        underlineColorAndroid='transparent'
      />
    )
  }
}

export default class App extends Component<{}> {
  render() {
    return (
      <View>
        <ToggleColorInput blurOnSubmit={true} multiline={true} />
        <ToggleColorInput blurOnSubmit={true} multiline={false} />
        <ToggleColorInput blurOnSubmit={false} multiline={true} />
        <ToggleColorInput blurOnSubmit={false} multiline={false} />
      </View>
    );
  }
}

const styles = StyleSheet.create({
  textInput: {
    height: 75,
    borderWidth: 1,
    borderColor: 'black'
  }
});
```
2. You see four TextInputs, with each combination of the `blurOnSubmit` and `multiline` properties. For each TextInput, type some text and tap the submit button.
3. The TextInputs in this test will toggle background color when they emit an `onSubmitEditing` event. Verify the following behavior on each platform:
 * blurOnSubmit && isMultiline => Submit event emitted, blurred, no newline inserted
 * blurOnSubmit && !isMultiline => Submit event emitted, blurred
 * !blurOnSubmit && isMultiline => Submit event emitted, newline inserted
 * !blurOnSubmit && !isMultiline => Submit event emitted
Closes #16040

Differential Revision: D5877401

Pulled By: shergin

fbshipit-source-id: 741bcc06d8b69d7025f2cb42dd0bee4fa01cd88e

Summary:
As I was working on mimicking iOS animations for my ongoing work with `react-navigation`, one task I had was to match the "push from right" animation that is common in UINavigationController.

I was able to grab the exact animation values for this animation with some LLDB magic, and found that the screen is animated using a `CASpringAnimation` with the parameters:

- stiffness: 1000
- damping: 500
- mass: 3

After spending a considerable amount of time attempting to replicate the spring created with these values by CASpringAnimation by specifying values for tension and friction in the current `Animated.spring` implementation, I was unable to come up with mathematically equivalent values that could replicate the spring _exactly_.

After doing some research, I ended up disassembling the QuartzCore framework, reading the assembly, and determined that Apple's implementation of `CASpringAnimation` does not use an integrated, numerical animation model as we do in Animated.spring, but instead solved for the closed form of the equations that govern damped harmonic oscillation (the differential equations themselves are [here](https://en.wikipedia.org/wiki/Harmonic_oscillator#Damped_harmonic_oscillator), and a paper describing the math to arrive at the closed-form solution to the second-order ODE that describes the DHO is [here](http://planetmath.org/sites/default/files/texpdf/39745.pdf)).

Though we can get the currently implemented RK4 integration close by tweaking some values, it is, the current model is at it's core, an approximation. It seemed that if I wanted to implement the `CASpringAnimation` behavior _exactly_, I needed to implement the analytical model (as is implemented in `CASpringAnimation`) in `Animated`.

We add three new optional parameters to `Animated.spring` (to both the JS and native implementations):

- `stiffness`, a value describing the spring's stiffness coefficient
- `damping`, a value defining how the spring's motion should be damped due to the forces of friction (technically called the _viscous damping coefficient_).
- `mass`, a value describing the mass of the object attached to the end of the simulated spring

Just like if a developer were to specify `bounciness`/`speed` and `tension`/`friction` in the same config, specifying any of these new parameters while also specifying the aforementioned config values will cause an error to be thrown.

~Defaults for `Animated.spring` across all three implementations (JS/iOS/Android) stay the same, so this is intended to be *a non-breaking change*.~

~If `stiffness`, `damping`, or `mass` are provided in the config, we switch to animating the spring with the new damped harmonic oscillator model (`DHO` as described in the code).~

We replace the old RK4 integration implementation with our new analytic implementation. Tension/friction nicely correspond directly to stiffness/damping with the mass of the spring locked at 1. This is intended to be *a non-breaking change*, but there may be very slight differences in people's springs (maybe not even noticeable to the naked eye), given the fact that this implementation is more accurate.

The DHO animation algorithm will calculate the _position_ of the spring at time _t_ explicitly and in an analytical fashion, and use this calculation to update the animation's value. It will also analytically calculate the velocity at time _t_, so as to allow animated value tracking to continue to work as expected.

Also, docs have been updated to cover the new configuration options (and also I added docs for Animated configuration options that were missing, such as `restDisplacementThreshold`, etc).

Run tests. Run "Animated Gratuitous App" and "NativeAnimation" example in RNTester.
Closes #15322

Differential Revision: D5794791

Pulled By: hramos

fbshipit-source-id: 58ed9e134a097e321c85c417a142576f6a8952f8

Differential Revision: D5874862

fbshipit-source-id: 24517d26b18c11fb9f75c6d3b5faae360711ea9e

Reviewed By: emilsjolander

Differential Revision: D5842889

fbshipit-source-id: 8ecc829dc43614934c47fd3a68317259e403325a

Reviewed By: cwdick

Differential Revision: D5874529

fbshipit-source-id: 0ee9d740b4445419e3143942514475751763520d

Differential Revision: D5850960

fbshipit-source-id: 4d7aa0ed7542181861649a2089d90c3cf98723e9

Differential Revision: D5850963

fbshipit-source-id: e1bd6d74953872d38e73a20f6d054905a7e4c80c

Differential Revision: D5850968

fbshipit-source-id: e5e7ad92c2347c2641551fcf820f061ffde5fed6

Differential Revision: D5850970

fbshipit-source-id: 88ab6fe3822f1bc4195007f8ec83177a84c27569

Summary:
HeadlessJsTaskConfig parameters can be unclear, so I added one more parameter that was left set by default and the respective comments.
Closes #16054

Differential Revision: D5881373

Pulled By: hramos

fbshipit-source-id: 3d271f73921417d82e3a2c7a1aaabe92aef7ec69

Summary:
This change improves the documentation for `ActionSheetIOS.js`. It's a bit skimpy as is.
Closes #16030

Differential Revision: D5882446

Pulled By: hramos

fbshipit-source-id: b59ce299a9142ebf015ed674c59e1e435deb759a

Summary:
As a new user it took me a while to figure out you can import these examples directly. The import statement completes the example for new users like me who have no idea these components can be imported. It is a very important piece of information and it is hard to find otherwise.

I think this should be added to all the other component examples as well.

Documentation only.
Closes #15501

Differential Revision: D5882436

Pulled By: hramos

fbshipit-source-id: 2da0fe4c7c41e2fdb6b13a945460e17e16442d62

Reviewed By: fkgozali

Differential Revision: D5881825

fbshipit-source-id: 38debe598830c4cc969b5251cfdfd8941ac36e9d

Summary: Apple changed what messages get logged when a web socket connection fails. Lets hide them to make life better for engineers.

Reviewed By: javache

Differential Revision: D5879306

fbshipit-source-id: cde06405b4af251159269218bf922916a79ac840

Summary:
Following the migration guide. Let's see what happens here.
Closes #14955

Differential Revision: D5877682

Pulled By: hramos

fbshipit-source-id: 2a40560120b5d8d28bc6c52cc5e5916fd1bba336

Summary:
I've helped contribute around [70 pull requests](https://github.com/facebook/react-native/pulls/rigdern) to React Native and would like to help triage issues.

Adam Comella
Microsoft Corp.
Closes #16059

Differential Revision: D5884339

Pulled By: hramos

fbshipit-source-id: ba7468fd8e2a5e8f3f054bcafa652a7988f10a78

Summary: Adds an onDismiss so that navigation events can be chained to the dismissing of a modal.

Reviewed By: sahrens

Differential Revision: D5852953

fbshipit-source-id: a86e36fdd5b0b206c2dd9fa248e2a88da22efa31

Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.

Help us understand your motivation by explaining why you decided to make this change.

You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html

Happy contributing!

-->

Adding example on components section with [react-native-web-player](https://github.com/dabbott/react-native-web-player)

- ActivityIndicator
- TouchableOpacity
- TouchableHighlight

Screenshot on http://localhost:8079/react-native/docs/activityindicator.html
![react-native-activityindicator](https://user-images.githubusercontent.com/13135332/30432801-adca0982-9988-11e7-8e70-94ad9e42ea43.png)

Screenshot on http://localhost:8079/react-native/docs/touchableopacity.html
![react-native-touchableopacity](https://user-images.githubusercontent.com/13135332/30432718-80570554-9988-11e7-9c81-15ab98327fed.png)

Screenshot on http://localhost:8079/react-native/docs/touchablehighlight.html
![react-native-touchablehighlight](https://user-images.githubusercontent.com/13135332/30432733-8290fbb8-9988-11e7-94a1-86c3166e544d.png)
Closes #15950

Differential Revision: D5881366

Pulled By: hramos

fbshipit-source-id: 2926071723defedf9ed5cb1b1128204256c71dd9

Summary:
- Enable logging so `console.log` shows up in Xcode console (and CI?)
- Allow loading from bundler for rapid JS iteration.
- Add option to enable JS debugging, although it's a little ghetto.

Reviewed By: mmmulani

Differential Revision: D5869085

fbshipit-source-id: 9c4831859f1491f7f75786f730d8549d69623888

Differential Revision: D5850970

fbshipit-source-id: 8b0f9bc296ac2944b8b7657a4119b6787d810a2c

…SModulesUnbundle.

Differential Revision: D5850968

fbshipit-source-id: f4c9dc8d5f14cdd32195463e8786242e708770e9

Summary:
1. Fix bug: Android project do not delete font files when run `react-native unlink`.
2. Add feature, link images to iOS project when run `react-native link`.
Closes #14801

Differential Revision: D5890051

Pulled By: hramos

fbshipit-source-id: 28223d181ac5ed51d70df29a56eb56b2cce9aecb

Reviewed By: kathryngray

Differential Revision: D5861693

fbshipit-source-id: 226ff15622d5e1a8ae3ad4c63f1434bd95c1fa21

Differential Revision: D5890458

fbshipit-source-id: 968be95786ffbf53aa98928d4d3e3bd52a84b3dc