Summary:
Suppose that the user is scrolled to the bottom of a ScrollView. Next, the ScrollView's content is edited such that the height of the content changes and the current scroll position is larger than the new height of the content. Consequently, the user sees a blank ScrollView. As soon as the user interacts with the ScrollView, the ScrollView will jump to its max scroll position.
This change improves this scenario by ensuring that the user is never staring at a blank ScrollView when the ScrollView has content in it. It does this by moving the ScrollView to its max scroll position when the scroll position after an edit is larger than the max scroll position of the ScrollView.
Here are some pictures to illustrate how this PR improves the scenario described above:
**Test plan (require
Closes https://github.com/facebook/react-native/pull/11000
Differential Revision: D4250792
Pulled By: astreet
fbshipit-source-id: 940fff6282ad29c796726f68b4519cbdabbfe554
Summary: Adds utilities needed for bundle creation: `completeModuleWrapper` appends numeric IDs for the module itself and its dependencies to a module wrapped. `createGetModuleId` returns a function that returns sequential numeric IDs for strings, and is idempotent.
Reviewed By: cpojer
Differential Revision: D4240334
fbshipit-source-id: c165482ebcf0e81ebb83ba6ff634de095ffb6bf0
Summary: When building, we will process modules in a special way, *not* polyfillys. We will also add more types of (virtual) files that are not modules. That’s why a “type” property makes more sense.
Reviewed By: cpojer
Differential Revision: D4244583
fbshipit-source-id: 92a0b4a0a2026d0b97ba88034483a6ce4e0c1ebb
Summary:
The logic in `ModuleGraph/Graph` allowed the callback to be invoked twice, if two invocations of `resolve` call back with errors asynchronously.
This fixes that problem by always calling `queue.kill()` on the asynchronous queue, and only invoke the main callback from the `drain` and `error` queue callbacks.
Reviewed By: jeanlauliac
Differential Revision: D4236797
fbshipit-source-id: c30da7bf7707e13b11270bb2c6117997fd35b029
Summary:
Fix an issue when running Jest unit tests due to a missing mock for StatusBarManger.
**More info:**
In one of my files I have:
```
export const STATUS_BAR_HEIGHT = (StatusBar.currentHeight || 0);
```
When I run the tests it gives this error, which seems to be because StatusBarManager is undefined (https://github.com/facebook/react-native/blob/master/Libraries/Components/StatusBar/StatusBar.js#L20)
```
TypeError: Cannot read property 'HEIGHT' of undefined
at Object.<anonymous> (node_modules/react-native/Libraries/Components/StatusBar/StatusBar.js:395:1823)
at Object.StatusBar (node_modules/react-native/Libraries/react-native/react-native.js:55:24)
```
**Test plan (required)**
Verify that with this change tests that use StatusBar pass.
Closes https://github.com/facebook/react-native/pull/11198
Differential Revision: D4246367
Pulled By: cpojer
fbshipit-source-id: ee9406d2566688d235a11cab8f24b0583698e93a
Summary:
**Motivation**
On Exponent we load fonts dynamically and assign their native names by appending a session id, so that fonts from one Exponent "experience" do not clash with each other. So, before sending the `fontFamily` to native, we want to change it to the Exponent-scoped `fontFamily`.
Example:
```js
// Before rendering your app
StyleSheet.setStyleAttributePreprocessor('fontFamily', _processFontFamily);
function _processFontFamily(name) {
// Pass system fonts through
if (!name || Constants.systemFonts.indexOf(name) >= 0) {
return name;
}
if (!Font.isLoaded(name)) {
if (__DEV__) {
console.error(`${name} is not a system font and has not been loaded through Exponent.Font.loadAsync. If you intended to use a system font, make sure you typed the name correctly and that it is supported by the current operating system. If this is a custom font, be sure to load it with Exponent.Font.loadAsync`);
} else {
return 'system';
}
}
return `ExponentFont-
Closes https://github.com/facebook/react-native/pull/11138
Differential Revision: D4245518
Pulled By: mkonicek
fbshipit-source-id: bd2452b1129d6675aa7b88e41351f8bb61fa20a3
Summary:
**Description**
In the same vein as https://github.com/facebook/react-native/pull/11198, this adds a mock for the native module `AppState`.
**Test plan**
Create a component that uses `AppState`, e.g.
```jsx
import React, { Component } from 'react';
import { AppState } from 'react-native';
class TestComponent extends Component {
componentDidMount() {
AppState.addEventListener('change', this.stateChangeListener);
}
}
```
Closes https://github.com/facebook/react-native/pull/11199
Differential Revision: D4246668
Pulled By: cpojer
fbshipit-source-id: e3a73a98963a0e152a70aba78ef3461b86da0f6c
Summary:
This fixes a cryptic bug to appear when you try to use scrollResponderZoomTo in Android.
before this PR it would break with a `Error: TaskQueue: Error with task : invariant requires an error message argument` because the invariant() was not properly used..
Also, instead of detecting the platform, I think it's better practice to duck type.
Closes https://github.com/facebook/react-native/pull/11186
Differential Revision: D4246674
fbshipit-source-id: 47002a85d8252e5abbd1cd9ecef3d7676fa8615a
Summary:
ReactAndroid/build.gradle downloads a number of ad-hoc dependencies from the internet such as boost, JSC headers, and folly. Having the build depend on the internet is problematic. For example, if the site hosting the JSC headers was to go down, then CI builds would start failing.
This change introduces the environment variable REACT_NATIVE_DEPENDENCIES which refers to a path. Developers can pre-download all of the ad-hoc dependencies into that path and then the build process will grab the dependencies from that local path rather than trying to download them from the internet. This solution is in the spirit of the existing REACT_NATIVE_BOOST_PATH hook.
**Test plan (required)**
This change is used by my team's app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11195
Differential Revision: D4247080
Pulled By: mkonicek
fbshipit-source-id: 7c4350339c8d509a829e258d8f1bf320ff8eef64
Summary: For having a global cache, we need cache keys that are the same from different machines, so we cannot include user/machine-specific information. In that regard, I suggest we consider the paths relatively to the install directory of the React Native instead of being absolute, so that they are more chances they stay stables between different installations, users, machines.
Reviewed By: davidaurelio
Differential Revision: D4237840
fbshipit-source-id: d864b9739550ac2c95d5693db12bd1592411f80a
Summary: mtime is a problem for the global cache, because everyone has different times at which they rebased/cloned the repo. Use the actual content instead. Of course, the file could depend on other files we don't take into account... but the mtime solution was already problematic in that regard, so I assume this is a safe change.
Reviewed By: davidaurelio
Differential Revision: D4237826
fbshipit-source-id: 9dc18eb422cddd4d5ed097d1ebeef4b8c361ff39
Summary:
When testing `react-native-git-upgrade` locally I noticed a warning:
A more recent version of "react-native-git-upgrade" has been found:
Current: 0.1.0
Latest: 0.0.1
See https://www.npmjs.com/package/react-native-git-upgrade
This won't happen to a lot of people but better fix the warning. Also, if the check for updates fails, don't crash - the check for updates is not critical to the tool working.
Also, slightly updated one error message.
**Test plan (required)**
Installed `react-native-git-upgrade` locally, ran it inside an app folder (RN 0.29).
Didn't see the wrong "more recent version" warning anymore.
Tried making `checkForUpdates` fail by adding some dummy code: `semver.foo()`. Saw a warning but the process continued:
git-upgrade WARN Check for latest version failed semver.foo is not a function
Saw a more descriptive error message:
git-upgrade ERR! Error: react-native version in "package.json" (0.29.0) doesn't match the installed version in "node_mod
Closes https://github.com/facebook/react-native/pull/11188
Differential Revision: D4244002
Pulled By: bestander
fbshipit-source-id: 772044750a933663cb516201d09e2873462cca4a
Summary:
Made modification to react-native code that reduces the communication channel overhead to ~50% of prior, in some cases, by caching the class-name of the java-script module/interface.
For me it reduced the run-time of the RCTDeviceEventEmitter.emit function from 1438ms to 715ms, over a period of 8 seconds in my Android app. My project requires many emit calls, as I'm transferring real-time EEG data from a Muse headband to my react-native UI to be graphed, so this optimization was very helpful in my case.
Closes https://github.com/facebook/react-native/pull/11118
Reviewed By: astreet
Differential Revision: D4232794
Pulled By: javache
fbshipit-source-id: 25ca1cfc170a343e71ff8915c3fa7e38884a402b
Summary:
See https://github.com/facebook/jest/pull/2170. Per cpojer's request, bringing this PR to react-native as well.
**Summary**
When using jest with React Native and Relay and recommended default settings, jest throws :
```
Cannot find module 'react-dom' from 'relayUnstableBatchedUpdates.js'
at Resolver.resolveModule (node_modules/jest-resolve/build/index.js:151:17)
at Object.<anonymous> (node_modules/react-relay/lib/relayUnstableBatchedUpdates.js:15:18)
at new RelayEnvironment (node_modules/react-relay/lib/RelayEnvironment.js:39:63)
```
Investigating this, I found out that https://github.com/facebook/jest/blob/master/packages/jest-react-native/jest-preset.json didn't have "native" in the list of platforms, hence jest can't pick up `relayUnstableBatchedUpdates.native.js` in react-relay.
**Test plan**
I copied and paste the content of https://github.com/facebook/jest/blob/master/packages/jest-react-native/jest-preset.json in my `package.json` `jest` section, as well a
Closes https://github.com/facebook/react-native/pull/11179
Differential Revision: D4243073
Pulled By: cpojer
fbshipit-source-id: bcfeb2235df4d466ba19d0a3fe94fc98835a20ea
Summary:
Looks like the native Image implementation used to treat old `image!` images slightly differently. This diff restores that behavior for `nativeImageSource`.
{F65080365}
Reviewed By: mmmulani
Differential Revision: D4240506
fbshipit-source-id: d8d39216f86df32e0614d7cdc95df2148c85077a
Summary: Flow was updated in bf901d926e, need to update the config file for the template too.
Reviewed By: mkonicek
Differential Revision:
D4240152
Ninja: OSS tests only
fbshipit-source-id: c20704c43a5d603105125a0316b7926cdc7cd7fd
Summary: Sets some options on `toLocaleString()` so that the server debug output's timestamps are shorter and have a consistent width (zero-padded).
Reviewed By: cpojer
Differential Revision: D4235074
fbshipit-source-id: 72dcf35ffd182eb70afc20d2b266314787433c4a
Summary:
When printing fields in the packager server debug output, this revision breaks the fields up onto multiple lines.
As it currently exists, the fields are printed immediately after the log entry label which can seem unnecessarily repetitive and unintuitive.
Reviewed By: davidaurelio
Differential Revision: D4235038
fbshipit-source-id: 2d59afa70c74f19afab221dfa58f437913c6dc2c
Summary:
This diff attempts to fix a number of iOS native animation bugs related to improper node invalidation and a race with view creation. The major issues were presented in #9120 as problems 3 and 3b, but I'll recap here:
The invalidation model we use is overly complicated and incomplete. The proper combination of `_needsUpdate` and `_hasUpdated` will result in nodes values being recomputed. However, we do not invalidate nodes in all the places we should, e.g. if we create a new view and attach it to an existing value node (see example in #9120). This diff chooses to remove the `_hasUpdated` flag, and simply relies on the `_needsUpdate` flag to mark a node as dirty.
We mark nodes as dirty when they are:
- created
- updated
- attached to new parents
- detached from old parents
- attached to a view
Calling `updateNodeIfNecessary` will, if necessary, compute all invalidated parent values before recomputing the node value. It will then apply the update, and mark the no
Closes https://github.com/facebook/react-native/pull/10663
Differential Revision: D4120301
Pulled By: mkonicek
fbshipit-source-id: e247afcb5d8c15999b8328c664b9f7e764d76a75
Summary:
The upgrading process based on Yeoman is a pain. For each file, Yeoman (or the brand new copyAndReplace solution a477aec) compares the newly generated content with the existing one and prompts the user if it differs, with very basic options: overwrite or skip.
I have digged into this problem and came with [rn-diff](https://github.com/ncuillery/rn-diff) (you may have read [this article](https://medium.com/ncuillery/easier-react-native-upgrades-with-rn-diff-5020b5c3de2d#.llvy2dym5)). This repository helps people to upgrade RN on their projects. An alternative upgrading process using `git apply` instead of Yeoman is described [here](https://github.com/ncuillery/rn-diff/blob/master/USAGE.md).
This PR is the integration of this process into the core. I got rid of the drawbacks mentioned in the link below in order to make it a clean, elegant, one-step operation.
This process is based on some Shell operations that:
- Generate the blank sources of both old and new versions
Closes https://github.com/facebook/react-native/pull/11110
Differential Revision: D4237107
Pulled By: mkonicek
fbshipit-source-id: 15e82e030b762415c925ccb2a62ddb354a6e18b9
Summary:
Instead of exposing a `getTransformOptionsModulePath` function in configurations, we can simply expose a `getTransformOptions` *function*. The necessity of exposing a path comes from the olden days, where we had a server listening on a socket, and a client, talking to that server.
Since that architectural gem no longer exists, we can use functions directly, rather than passing paths to modules around.
Reviewed By: cpojer
Differential Revision: D4233551
fbshipit-source-id: ec1acef8e6495a2f1fd0911a5613c144e8ffd7c3
Summary:
instead of passing the `Bundler` instance, the transform options module now receives a `getDependencies()` function.
The idea is to make the contract stricter, to integrate more easily with the new `ModuleGraph` system.
Reviewed By: cpojer
Differential Revision: D4233529
fbshipit-source-id: 1c6d462c7dae1c61cbf45fd13989ce77f76e7384
Summary:
The `FrescoModule` supports providing a custom image pipeline configuration. This module is created by `MainReactPackage` but `MainReactPackage` doesn't expose any way to customize the Fresco configuration. This change adds a parameter to `MainReactPackage`'s constructor so that the `FrescoModule`'s configuration can be customized by the app. A couple of design choices were made in this change:
- `MainReactPackage`'s new constructor parameter is a `MainPackageConfig`. Introducing `MainPackageConfig` enables `MainReactPackage` to nicely support new optional configuration options in the future. Imagine the alternative of each optional configuration being a separate parameter to the `MainReactPackage` constructor.
- `FrescoModule` exposes its default configuration as a builder object through the `getDefaultConfigBuilder` method. This enables app's to start with `FrescoModule`'s default configuration and then modify it.
**Test plan (required)**
Verified that passing a custom config based on React Nati
Closes https://github.com/facebook/react-native/pull/10906
Differential Revision: D4237054
Pulled By: mkonicek
fbshipit-source-id: 8a62a6f0e77ca5f6d35238950094686756262196
Summary:
> Explain the **motivation** for making this change. What existing problem does the pull request solve?
Just fixed a typo.
Feel free to make the change directly in the repo without my credit if the process is easier than accepting this PR.
Closes https://github.com/facebook/react-native/pull/11164
Differential Revision: D4236963
Pulled By: mkonicek
fbshipit-source-id: 72c059596216602f9ab30dea6eb5f9cdbf89d31b
Summary:
Adding documentation for the CLI for 2 reasons:
1. It's not immediately clear to most how the CLI is part of `react-native` and not the node module they installed. This begins clarifying.
2. I plan on adding some additional documentation to this section pending an upcoming PR I've discussed with Mike.
screen shot provided:
Closes https://github.com/facebook/react-native/pull/11097
Differential Revision: D4237028
Pulled By: mkonicek
fbshipit-source-id: c1dc50fe1be7f6947a33ee6472b5862306888055
Summary:
The windows and linux block didn't have the command to install react-native-cli.
The command is the exact same as it is on macOS. It makes the guide a little confusing because it leaves out this critical step and it's difficult to understand whether or not this needed component was already indirectly installed in one of the other steps.
Closes https://github.com/facebook/react-native/pull/11135
Differential Revision: D4236984
Pulled By: mkonicek
fbshipit-source-id: dca237132df7d80b5a02eaf09faec53e13e005cb
Summary:
"com.facebook.react.ReactPackage" is imported twice so fixed it to once.
Closes https://github.com/facebook/react-native/pull/11165
Differential Revision: D4236961
Pulled By: mkonicek
fbshipit-source-id: 84765dd9f8731b978972959f3825bf3c9c0684e3
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Warning about new Buffer when init
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#s
Closes https://github.com/facebook/react-native/pull/11153
Differential Revision: D4234591
fbshipit-source-id: a9373f3151de8a50c18342f45fb9684a5c7416a6
Summary:
When building the website, I saw this warning:
`Warning: Unknown DOM property for. Did you mean htmlFor?`
So, here's the fix.
1. do `npm start`
2. load the homepage (with the newsletter input)
3. see warning: `Warning: Unknown DOM property for. Did you mean htmlFor?`
Closes https://github.com/facebook/react-native/pull/10948
Differential Revision: D4200031
Pulled By: hramos
fbshipit-source-id: 7a17e3961ec59a1f28e81d3639a5376880873bd6
Adam Comella
David Aurelio
Tim Yung
mlanter
Brent Vatne
Kevin Cooper
Gaëtan Renaudeau
Vojta Bartos
Emil Sjolander
Sokovikov
Jean Lauliac
Martin Konicek
Venryx
Loic CHOLLIER
Max Sherman
Alex Kotliarskyi
Ryan Gomba
Pieter De Baets
Gabe Levi
Nicolas Cuillery
Sota Yamashtia
Seph Soliman
Gant Laborde
Martin Konicek
George K
Vishal Kakadiya
Indragie Karunaratne
yicheng
penx
Damien
