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
Summary:
When using text inputs inside a ScrollView with `keyboardShouldPersistTaps=false` (default behavior) tapping another text input dismisses the keyboard instead of keeping it open and focusing the new text input which I think is the better and expected behavior.
See #10628 for more discussion about that. Note that this affects nothing but the behavior with text inputs unlike #10628.
cc satya164 MaxLap ericvicenti
Closes https://github.com/facebook/react-native/pull/10887
Differential Revision: D4178474
Pulled By: ericvicenti
fbshipit-source-id: 0c62ea2fac0017d559d1f8674b0a686a5e1b3d2d
Summary:
This exposes iOS's spellCheckingType functionality to JavaScript. The native functionality is a three state enum. It gets exposed to JavaScript as a boolean. The initial value and JS null map to the third state.
An alternative design for this API would have been to expose a three state enum to JavaScript:
- "on" which maps to UITextSpellCheckingTypeYes
- "off" which maps to UITextSpellCheckingTypeNo
- "auto" (default) which maps to UITextSpellCheckingTypeDefault
For consistency, I decided to use the same API design as spellCheck. We don't have many options for fixing spellCheck in #11055 without introducing a breaking change.
**Test plan (required)**
Verified that switching `spellCheck` between `true`, `false`, and `null` all work correctly in single line and multiline `TextInputs`.
Closes https://github.com/facebook/react-native/pull/11056
Differential Revision: D4232802
Pulled By: javache
fbshipit-source-id: 79e03307fa6a30a169f7e2fd0ec5ac826663e7c1
Summary:
This PR seeks to improve the documentation of PushNotificationIOS.
The method didReceiveRemoteNotification without a fetch completion handler is deprecated by Apple and they [discourage using it](https://developer.apple.com/reference/uikit/uiapplicationdelegate/1623117-application) in favor of the [version with the handler](https://developer.apple.com/reference/uikit/uiapplicationdelegate/1623013-application).
Reasons for this change:
1. Our docs say that this method is required for remote notifications, but it's not. (It's one of possibilities with a recommendation not to use it.)
2. The method is deprecated by Apple and people shouldn't use it.
3. If you use the deprecated method, in 99% of the cases it will behave in a different way from what you'd expect. In particular, you won't get remote notifications when your app is in the background.
As there's no benefit (as far as I know) of using the method, I don't think we should even mention it to the users.
This is a re-opened PR that was mis
Closes https://github.com/facebook/react-native/pull/11109
Differential Revision: D4232800
Pulled By: javache
fbshipit-source-id: d3b509db41a549aa7fbc41753c648085df43d8ee
Summary:
The C++ standard requires that when a function is used in a template it's prototype needs to be defined not only before the template specialization, but also before the template itself.
Because of that one needs to (in certain compilers) be aware of the proper order of includes so that the function prototype is defined before the JSCExecutor.h is included.
As a workaround the toValue might be written as a template (ValueEncoder<T>::toValue) defined in JSCExecutor.h instead of being an non-existing symbol.
Thanks to that the JSCExecutor.h does not have to be included before the specialization of the ValueEncoder template.
Reviewed By: mhorowitz
Differential Revision: D4182724
fbshipit-source-id: 9bdf239ae66ef7a7d2c82daf7db5926472687bde
Summary:
This removes support for `require('image!…')`, which has been deprecated for a long time.
It is still possible to use images that are already bundled by the native app using the `nativeImageSource` module.
Check http://facebook.github.io/react-native/docs/images.html for detailed documentation.
Reviewed By: matryoshcow
Differential Revision: D4231208
fbshipit-source-id: 05ec4c1ca0fabdc3fbb652f8ad1acdf240a67955
Summary:
This PR removes dependency to Jackson third-party library in Android React Native.
Looking at some older PRs that got merged, it seems like some work had already been done to move away from Jackson.
Anyway, there was only two classes left with a dependency on Jackson. I refactored the code to use android built-in `JsonReader` and `JsonWriter` classes instead.
Prep work was done in https://github.com/facebook/react-native/pull/10516 introducing a few unit tests around serialization, to make sure that refactoring around serialization would not break things.
All references to Jackson in build systems files (BUCK files & build.gradle) have also been removed now that no code depend anymore on this third-party library.
Motivation behind this work is that third-party dependencies in Android React Native can prove to be a pain when trying to integrate React Native components into an already existing large Android application (I know this is not the most common use case for react-native ... yet ;P), that might a
Closes https://github.com/facebook/react-native/pull/10521
Differential Revision: D4226705
Pulled By: mkonicek
fbshipit-source-id: e3a7430a79dd00c871ba3c6a705b0b0c3ec3a701
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary:
Expose aspectRatio style prop from css-layout to React Native.
This means the following will now work:
<View style={{backgroundColor: 'blue', aspectRatio: 1}}/>
Reviewed By: javache
Differential Revision: D4226472
fbshipit-source-id: c8709a7c0abbf77089a4e867879b42dcd9116f65
Summary:
Downloading from the CDN is much faster than from SourceForge, both on my home WiFi and at the office.
I checked using the `diff` utility that both files are identical.
**Test Plan**
Circle CI build on this PR.
Closes https://github.com/facebook/react-native/pull/11087
Differential Revision: D4226538
fbshipit-source-id: a30ec1d94fe3228342c4a198bf65df7a95e0c005
Summary:
On Android, if there is a small amount of space available around a text input (e.g. landscape orientation on a phone), Android may choose to have the user edit the text inside of a full screen text input mode. This behavior isn't always desirable. For example, if your app offers some UI controls for controlling the formatting of the text, you want the controls to be visible while the user is editing the text. This Android feature conflicts with that desired experience because the UI controls would be hidden while the text is being edited.
The `disableExtractUI` prop enables developers to choose whether or not Android's full screen text input editing mode is enabled. When this prop is true, Android's `IME_FLAG_NO_EXTRACT_UI` flag is passed to the `setImeOptions` method.
**Test plan (required)**
Verified `disableExtractUI` works for both `true` and `false` values in a test app.
My team is also using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10900
Differential Revision: D4226483
Pulled By: mkonicek
fbshipit-source-id: 8f1055f6e612b05bafabe6f07a3705dd8788e3da
Summary:
Follow up to #8190
Tested with custom parameter as well as w/o (using default value). All worked well.
Differential Revision: D4220565
Pulled By: mkonicek
fbshipit-source-id: e8a98542d3ff96d60ff6045b328f5b464f78ee74
Summary:
Brings back parts of the programmatic API removed in 7762f374d5. This is used by a few people. Also updates the docs accordingly.
cc akaila
Reviewed By: jeanlauliac
Differential Revision: D4226348
fbshipit-source-id: e5c0794f9c5415f14b54d16c6f35f902eafc3064
Summary:
There's an inconsistency in autoCorrect's default state:
- If you don't specify a value for autoCorrect, it defaults to on.
- If you specify true/false for autoCorrect and later specify null, autoCorrect turns off. It should have reverted to its initial state of on.
The reason for this discrepancy is that autoCorrect is exposed to JS as a boolean but it is actually an enum with three states in native:
- UITextAutocorrectionTypeDefault (the default value)
- UITextAutocorrectionTypeYes
- UITextAutocorrectionTypeNo
This is fixed by explicitly mapping JS null to UITextAutocorrectionTypeDefault.
**Test plan (required)**
Verified that switching `autoCorrect` between `true`, `false`, and `null` all work correctly in single line and multiline `TextInputs`.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11055
Differential Revision: D4226419
Pulled By: javache
fbshipit-source-id: e3e5769a3aa537f00fb56ca4ae622ff4213481c5
Summary:
When native events where handled they were not sent to JS as an optimization but this caused some issues. One of the major one is touches are not handled properly inside a ScrollView with an Animated.event because it doesn't receive scroll events so it can't cancel the touch if the user scrolled.
Closes https://github.com/facebook/react-native/pull/10981
Differential Revision: D4226403
Pulled By: astreet
fbshipit-source-id: 41278d3ed4b684af142d9e273b11b974eb679879
Summary:
Virtual shadow nodes (e.g. text) don't use CSSNodes so we don't need to create them. This shows large savings in CSSNodes allocated, depending on the app.
This could be breaking if:
- You have virtual nodes that still set and get CSS properties. The setters now no-op for virtual nodes (I unfortunately couldn't remove them completely -- see the comment on LayoutShadowNode), but the getters will NPE. If you see these NPE's, you should almost definitely be using your own datastructure instead of a CSSNode as virtual nodes will not participate in the layout process (and the CSSNode is then behaving just as a POJO for you).
I do not anticipate this to be breaking for anyone, but am including breaking in the commit message since this is a change in API contract.
Reviewed By: emilsjolander
Differential Revision: D4220204
fbshipit-source-id: b8dc083fff420eb94180f669dd49389136111ecb
Gabe Levi
Emil Sjolander
Nicolas Cuillery
Sota Yamashtia
David Aurelio
Pieter De Baets
Martin Konicek
Adam Comella
Seph Soliman
Gant Laborde
Martin Konicek
George K
Vishal Kakadiya
Indragie Karunaratne
yicheng
penx
Damien
Janic Duplessis
Wojciech Ogrodowczyk
Connor McEwen
Jean Lauliac
Lukas Piatkowski
Felix Krause
Ovidiu Viorel Iepure
rcaferati
Timur Gibadullin
Nicholas Young
Benoit Lemaire
Mike Grabowski
Andy Street
Pandiarajan Nagarajan
