Summary:
The updated Dangerfile config lets pull-bot warn when the PR lacks a Summary, on top of the existing Test Plan and Changelog warnings.
It will also be a bit more lenient when it comes to the changelog, making the `-` optional after TYPE.
Finally, I removed the "large PR" warning. We haven't had a problem with large PRs recently, and I feel we can deal with these on a case by case basis.
[GENERAL] [Changed] Adjust pull-bot to handle new PR template.
Tested against this PR (note the non-standard section titles):
```
$ yarn
$ yarn danger pr https://github.com/facebook/react-native/pull/23236📋 Missing Summary - <i>Can you add a Summary? To do so, add a "## Summary" section to your PR description. This is a good place to explain the motivation for making this change.</i>
-
📋 Missing Test Plan - <i>Can you add a Test Plan? To do so, add a "## Test Plan" section to your PR description. A Test Plan lets us know how these changes were tested.</i>
-
📋 Missing Changelog - <i>Can you add a Changelog? To do so, add a "## Changelog" section to your PR description. A changelog entry has the following format: [`[CATEGORY] [TYPE] - Message`](http://facebook.github.io/react-native/docs/contributing#changelog).</i>
Found only warnings, not failing the build
✨ Done in 4.86s.
```
Pull Request resolved: https://github.com/facebook/react-native/pull/23236
Differential Revision: D13915716
Pulled By: cpojer
fbshipit-source-id: 6f1c3e67140c14359fc369b36b900aedf9a3bd8a
Summary:
NativeModules are instantiated by the bridge. If they choose, they can capture the bridge instance that instantiated them. From within the NativeModule, the bridge can then be used to lookup other NativeModules. TurboModules have no way to do such a lookup.
Both NativeModules and TurboModules need to be able to query for one another. Therefore, we have four cases:
1. NativeModule accesses NativeModule.
2. NativeModule accesses TurboModule.
3. TurboModule accesses NativeModule.
4. TurboModule accesses TurboModule.
In summary, this solution extends the bridge to support querying TurboModules. It also introduces a `RCTTurboModuleLookupDelegate` protocol, which, implemented by `RCTTurboModuleManager`, supports querying TurboModules:
```
protocol RCTTurboModuleLookupDelegate <NSObject>
- (id)moduleForName:(NSString *)moduleName;
- (id)moduleForName:(NSString *)moduleName warnOnLookupFailure:(BOOL)warnOnLookupFailure;
- (BOOL)moduleIsInitialized:(NSString *)moduleName
end
```
If TurboModules want to query other TurboModules, then they need to implement this protocol and synthesize `turboModuleLookupDelegate`:
```
protocol RCTTurboModuleWithLookupCapabilities
property (nonatomic, weak) id<RCTTurboModuleLookupDelegate> turboModuleLookupDelegate;
end
```
NativeModules will continue to use `RCTBridge` to access other NativeModules. Nothing needs to change.
When we attach the bridge to `RCTTurboModuleManager`, we also attach `RCTTurboModuleManager` to the bridge as a `RCTTurboModuleLookupDelegate`. This allows the bridge to query TurboModules, which enables our NativeModules to transparently (i.e: without any NativeModule code modification) query TurboModules.
In an ideal world, all modules would be TurboModules. Until then, we're going to require that TurboModules use the bridge to query for NativeModules or TurboModules.
`RCTTurboModuleManager` keeps a map of all TurboModules that we instantiated. We simply search in this map and return the TurboModule.
This setup allows us to switch NativeModules to TurboModules without compromising their ability to use the bridge to search for other NativeModules (and TurboModules). When we write new TurboModules, we can have them use `RCTTurboModuleLookupDelegate` to do access other TurboModules. Eventually, after we migrate all NativeModules to TurboModules, we can migrate all old callsites to use `RCTTurboModuleLookupDelegate`.
Reviewed By: fkgozali
Differential Revision: D13553186
fbshipit-source-id: 4d0488eef081332c8b70782e1337eccf10717dae
Summary:
Specifically, updates the UWP .vcxproj for MSBuild and also exposes the UseLegacyStretchBehaviour API for use with react-native-windows.
Pull Request resolved: https://github.com/facebook/yoga/pull/848
Reviewed By: SidharthGuglani
Differential Revision: D13848609
Pulled By: davidaurelio
fbshipit-source-id: eab046ff3c47e49706f515e209d8aaf750c2198f
Summary:
Fixes#14161
Android crashes in some cases if an animated transform config contains a string value, like a rotation.
This PR fixes that by ensuring all values sent to the native side are doubles. It adds `__transformDataType` to AnimatedTransform.js.
Added integration test `ReactAndroid/src/androidText/js/AnimatedTransformTestModule.js` This test fails with the following error `INSTRUMENTATION_RESULT: longMsg=java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Double`, if the changes to AnimatedTransform.js are reverted.
[Android] [Fixed] - Fixes Android crash on animated style with string rotation
Pull Request resolved: https://github.com/facebook/react-native/pull/18872
Differential Revision: D13894676
Pulled By: cpojer
fbshipit-source-id: 297e8132563460802e53f3ac551c3ba9ed943736
Summary:
For better modularity, each module conforming to RCTTurboModule should provide a getter for the specific TurboModule instance for itself. This is a bit more extra work for devs, but simplify tooling and allow better modularity vs having a central function that provides the correct instance based on name.
Note: Android may or may not follow this new pattern -- TBD.
Reviewed By: RSNara
Differential Revision: D13882073
fbshipit-source-id: 6d5f82af67278c39c43c4f7970995690d4a82a98
Summary:
See https://github.com/facebook/react-native/issues/7680.
On iOS the RCTLocationObserver delegate is overriding `desiredAccuracy` every time CLLocationManager calls `didUpdateLocations` or `didFailWithError`. `desiredAccuracy` is reset to
`RCT_DEFAULT_LOCATION_ACCURACY` (100 meters) This effectively makes it impossible for a react-native app to use any location accuracy other than the default.
This commit simply removes the code which resets the desired accuracy, as there seems to be no rationale for doing so. The reset code was added as part of [a large general
change](705a8e0144) so the original intention is unclear from the history. If somebody can explain it to me, I'm happy to rework this PR accordingly.
Changelog:
----------
[iOS] [Fixed] - Location Services accuracy constantly reset to default of 100 meters.
Pull Request resolved: https://github.com/facebook/react-native/pull/23209
Differential Revision: D13879497
Pulled By: cpojer
fbshipit-source-id: f3c6c9c5ef698b23b99c407fd764ac990d69bf8c
Summary:
There is a variation in iOS and Android output while performing perspective transformation. The variation exists even when used in Android devices with different screen density.
Pull Request resolved: https://github.com/facebook/react-native/pull/18302
Differential Revision: D13877483
Pulled By: cpojer
fbshipit-source-id: e48be047a8047c7562722923a67666cb098243d8
Summary:
As a maintainer, I noticed that the description for a PR is often missing, which makes it hard to understand why a change is made. Because some of the text isn't using HTML comments, the same text explaining how to fill out the changelog and test plan pops up and isn't removed by people. This PR fixes both of these issues.
I also made another small update to the main issue template to urge people to use one of the other templates, with an explanation that we will close poorly formatted issues.
Changelog:
----------
[General] [Changed] - Updated GitHub templates
Pull Request resolved: https://github.com/facebook/react-native/pull/23187
Differential Revision: D13877752
Pulled By: cpojer
fbshipit-source-id: 8ed88cde9151a41931848cccc669208cabe1e9ef
Summary: simple diff to eager initialize the PreAllocateViewMountItem class with the rest of the Fabric classes
Reviewed By: sahrens
Differential Revision: D13860612
fbshipit-source-id: d1fbc653420c1c1546bbf605c682ad5bb611d76b
Summary: This diff changes the way pre-allocation of views are executed in Fabric. Before this diff the execution of view preallocation was schedulled at the end of the UIThread queue, now the views are pre-allocated in the next "tick"
Reviewed By: sahrens
Differential Revision: D13857614
fbshipit-source-id: 386bf966d3c8a0d5c0bd626119a92810465aecb7
Summary:
@public
Adds the maximum number of measure cache entries in use to the metrics for `YGMarkerLayout`
Reviewed By: SidharthGuglani
Differential Revision: D13844731
fbshipit-source-id: fa66dbf1b7a1799494f72ecc17dfaef04d0b56e4
Summary:
Fixes https://github.com/facebook/react-native/issues/23108. The TabBarIOS component is scheduled to be removed from core any day now, so it's OK to remove it from our test suite.
Changelog:
----------
[iOS] [Removed] - Remove TabBarExample SST
Pull Request resolved: https://github.com/facebook/react-native/pull/23206
Differential Revision: D13864064
Pulled By: hramos
fbshipit-source-id: f65da75e2789d384dcd713a27ca5528f0faa7526
Summary:
@public
Adds marker meta data to `YGMarkerLayout`: the number of measures, and the numbers of layouts for all nodes in the tree.
Reviewed By: SidharthGuglani
Differential Revision: D13838975
fbshipit-source-id: d575c26a3d5a4f0b66834eb6bedecadc3f3ca265
Summary:
pubic
Passes layout marker data through the recursive calls of the layout algorithm, in order to allow for collecting metrics.
Reviewed By: SidharthGuglani
Differential Revision: D13819444
fbshipit-source-id: cdca04964fba6a03ca3eeaca4d169107019ba457
Summary:
@public
Adds a class for triggering markers.
This calls `startMarker()` on construction, and `endMarker()` on destruction, thus being usable like a "scope guard": the object is instantiated, and automatically destroyed when going out of scope.
Reviewed By: SidharthGuglani
Differential Revision: D13817589
fbshipit-source-id: fd88884af970c1c0933d9ca6843f3f8f5d28b9e6
Summary:
RCTAsyncLocalStorage did not write the manifest after removing a value that was larger than RCTInlineValueThreshold. This meant that the values would still be on disk as null in the manifest.json, and if the app didn't do anything to make the manifest get written out again the null values would persist in the AsyncStorage and be returned by getAllKeys. We need to always write out the manifest.json even if the value is in the overflow storage files.
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.
Fixes#9196.
Not sure where the tests are for this?
none.
[IOS] [BUGFIX] [AsyncStorage] - Correctly remove keys of large values from AsyncStorage.
tadeuzagallo nicklockwood dannycochran
Pull Request resolved: https://github.com/facebook/react-native/pull/18613
Differential Revision: D13860820
Pulled By: cpojer
fbshipit-source-id: ced1cd40273140335cd9b1f29fc1c1881ab8cebd
Summary:
Currently, if an app uses AsyncStorage on the JS side, there is no public interface to access stored data from the native side.
In our app, written in Swift, I have written a [helper](https://gist.github.com/ejmartin504/d501abe55c28450a0e52ac39aee7b0e6) that pulls out the data. I accomplished this by reverse-engineering the code in RCTAsyncLocalStorage.m. It would have been far easier had this code been exposed to native.
I made this change locally and tested out getting the data from Swift code. This worked like a charm:
```swift
let storage = RCTAsyncLocalStorage()
let cacheKey = "test"
storage.methodQueue?.async {
self.storage.multiGet([cacheKey]) { values in
print(values)
}
}
```
[IOS ][ENHANCEMENT ][RCTAsyncLocalStorage.h] - Expose AsyncLocalStorage get/set methods to native code.
<!--
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [ {Component} ]
[ INTERNAL ] [ ENHANCEMENT ] [ {Filename} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/18454
Differential Revision: D13860333
Pulled By: cpojer
fbshipit-source-id: b33ee5bf1ec65c8291bfcb76b0d6f0df39376a7e
Summary:
Motivation:
----------
This is one of the more sought after feature requests for RN:
react-native.canny.io/feature-requests/p/add-speed-attribute-to-scrollto
This PR adds the support to add a "duration" whenever using "scrollTo" or "scrollToEnd" with
a scrollView. Currently this only exists for Android as the iOS implementation will be somewhat more involved.
This PR is also backwards compatible and does not yet deprecate the "animated" boolean. It may not make sense to ever deprecate "animated", as it could be the flag that is used when devs want the system default duration (which is 250ms for Android). I'm not sure what it is for iOS. It would simplify things to remove "animated", though.
Pull Request resolved: https://github.com/facebook/react-native/pull/22884
Differential Revision: D13860038
Pulled By: cpojer
fbshipit-source-id: f06751d063a33d7046241c95348b6abbb327d36f
Summary:
Make StatusBar style respect previously set systemUiVisibility
<!--
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!
-->
I tried to set `SystemUiVisibility` flag to `SYSTEM_UI_FLAG_LIGHT_NAVIGATION_BAR` to enable Android's light soft navigation bar, but when I had `<StatusBar />` component in my view, then it was always overwritten. This is how I found the bug and fixed it.
1. In MainActivity you can set systemUiFlags like this in onCreate method
```
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
Window window = getWindow();
View rootView = window.getDecorView().getRootView();
rootView.setSystemUiVisibility(View.SYSTEM_UI_FLAG_LIGHT_NAVIGATION_BAR);
}
```
2. Add <StatusBar /> to a view
3. In `android/app/build.gradle` file set `targetSdkVersion` to **27** instead of 22 or something like that
4. In `android/app/src/main/res/values/styles.xml` add 2 lines to `AppTheme`
```
<item name="android:windowDrawsSystemBarBackgrounds">true</item>
<item name="android:navigationBarColor">#ffffff</item>
```
5. Run the app.
6. Test. Previously bottom soft navigation bar was set to white and buttons also to white (so they weren't visible anymore), because StatusBar was overwriting previously set systemUiVisibility Flags. Now the bar should be white and buttons dark as expected.
Previous buggy android bottom navbar
<img width="379" alt="screen shot 2017-12-27 at 17 11 57" src="https://user-images.githubusercontent.com/571171/34385126-2a3edc44-eb29-11e7-812e-846cfd2fb88b.png">
New fixed android bottom navbar
<img width="379" alt="screen shot 2017-12-27 at 17 12 07" src="https://user-images.githubusercontent.com/571171/34385137-3e82517c-eb29-11e7-8af9-a3b7a41ae8e2.png">
This pull request does not change any existing feature. It only makes StatusBar coloring work more properly without affecting bottom navigation bar on android or any other system ui visibility feature.
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
[ANDROID] [BUGFIX] [StatusBar] - Fixed StatusBar overwriting previously set SystemUiVisibility flags
Pull Request resolved: https://github.com/facebook/react-native/pull/17370
Differential Revision: D13860079
Pulled By: cpojer
fbshipit-source-id: a0bca7acb7601eb78f0842239ea4dee76a63d1fd
Summary:
@public
Removes unused constexpr variables from YGStyle. Not polluting the global namespace is a good thing.
Reviewed By: SidharthGuglani
Differential Revision: D13816817
fbshipit-source-id: e4c27a8f2de466ccb759bbe52cdaea6fe451b961
Summary:
@public
Adds a function to allow to configure markers. The function is declared in `YGMarker.h`
Reviewed By: SidharthGuglani
Differential Revision: D13819111
fbshipit-source-id: f9158b3d4e5727da4e151c84b523c7c7e8158620
Summary: @public adds a first `YGMarker`, and the accompanying data type.
Reviewed By: SidharthGuglani
Differential Revision: D13817588
fbshipit-source-id: 6007eb09d19cf4021989bad5b5e880adb16364a0
Summary:
@public
this will lead to nicer enum member names.
Reviewed By: SidharthGuglani
Differential Revision: D13817587
fbshipit-source-id: 85355328f7977b4fb29a9474532f2d578a3cbf79
Summary:
His PR is related to #22609
There are still some warnings related to folly, but I plan to make the correction and send the PR to the repo of the folly.
Changelog:
[IOS][Changed] - Fix warning in JSCRuntime
Pull Request resolved: https://github.com/facebook/react-native/pull/23201
Differential Revision: D13859393
Pulled By: cpojer
fbshipit-source-id: 95df2b76b28b460f890d11e1395fddb6b1cc8fed
Summary:
Latest changes inside CLI now require that Metro configuration is provided when building RNTester app. This is to let CLI know that instead of looking for "react-native" under "node_modules" (that is obviously not present since we are running from source), it should check the paths provided.
When running "npm start", it finds the configuration at the root. However, when building through Xcode (e.g. "react-native bundle" or "xcodebuild" in Release scheme), it runs "react-native-xcode.sh" that works in different folder and makes Metro not detect the configuration file.
This PR explicitly sets path to the configuration via `BUNDLE_CONFIG`.
It also removes `pwd` from being prepended to all `BUNDLE_CONFIG` values. In my case, `pwd` was `/Users/grabbou` and the RNTester files where inside `/Users/grabbou/Repositories/react-native`. I was unable to point the script to correct location without making it aware of the folder structure - which is not going to work on the CI.
Pull Request resolved: https://github.com/facebook/react-native/pull/23191
Differential Revision: D13851741
Pulled By: hramos
fbshipit-source-id: d920353fd68d39468bd33bd1ad47e03b017a7727
Summary: This diff removes the components dependencies out of the Fabric/jsi/jni project
Reviewed By: shergin
Differential Revision: D13734001
fbshipit-source-id: 65182bfa5ee9fcd526a9afc40bd9fd6f0b86c5a5
Summary:
`com.facebook.react.uimanager.UIProp` doesn't exist anymore in React Native.
Remove all the old references to it in various redex and proguard configurations.
Reviewed By: int3, minjang, justinjhendrick
Differential Revision: D13847084
fbshipit-source-id: 366fb0b25f446903cc2885686850810778779e5e
Summary: Small changes to get Profile build working. Compiler errors or immediate crashes occur without these lines, when running a profile build on device.
Reviewed By: fkgozali
Differential Revision: D13823136
fbshipit-source-id: a1777d5337d8bd78ef3eb11bbeeb7e23c383ab83
Summary: Simple diff that adds QPL marker to track time it takes to load .so file from RN
Reviewed By: fkgozali
Differential Revision: D13845379
fbshipit-source-id: 6c2272605ba3fb08ab8ebce867f84c6a488438d0
Summary:
Reverting this change since it broke some initial scroll positions. It seems the proper API to use to limit overscrolling should be overScrollMode='never'
Original commit changeset: 2ec5787218ec
Reviewed By: olegbl
Differential Revision: D13845053
fbshipit-source-id: 673aa529ef5171f26ce138573ee36f31f5d9799e
Summary:
… suffix for asset
Better informational error message on getting Android drawable folder suffix error using the asset name scale.
<!--
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!
-->
I've got an not well described error when trying to bundle my React Native project package.
You can test the React Native bundle command like this:
node node_modules/react-native/local-cli/cli.js bundle --platform android --dev false --reset-cache --entry-file index.android.js --bundle-output /project/android/app/build/intermediates/assets/release/index.android.bundle --assets-dest /project/android/app/build
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/facebook/react-native-website, and link to your PR here.)
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/17751
Differential Revision: D13840597
Pulled By: cpojer
fbshipit-source-id: f755ef665b76ce3dd9c96e575fbc71e9aaf43a44
Summary:
For most cases, people saw this error when they are running a debug version. So they should check metro server first. However, they were misled to search for "bundle" keywords and finally they executed "react-native bundle" command and got an app that can never reload.
Pull Request resolved: https://github.com/facebook/react-native/pull/17055
Differential Revision: D13421737
Pulled By: cpojer
fbshipit-source-id: 8e108df06b7d416a74c33581457f3213b28306c1
Summary:
Right now you can choose to show Videos OR Photos.
This PR allows to show both in the same time.
[ANDROID][ENHANCEMENT] - Can show videos and photos from CameraRoll in the same time
Pull Request resolved: https://github.com/facebook/react-native/pull/16429
Differential Revision: D13839638
Pulled By: cpojer
fbshipit-source-id: 5edc039552888c3ba8a40f39e262919fa7c00b39
Summary:
This is a new attempt to get #11251 merged. I just cherry-picked the relevant commits. TextInputs are set to always ignore responder termination requests, which is not desirable when they are enclosed inside a swipeable area like a ListView
Create a TextInput inside a ListView and set the `rejectResponderTermination` prop to false. Otherwise, all TextInputs should have the same behavior they do now.
[IOS] [ENHANCEMENT] [TextInput] - Add `rejectResponderTermination` prop to to TextInput. This enables TextInputs inside Swipeables to function properly.
Pull Request resolved: https://github.com/facebook/react-native/pull/16755
Differential Revision: D7846365
Pulled By: cpojer
fbshipit-source-id: eb21140061ae1f475fbd83fc63a23819e931787d
Summary:
This method was originally intended to replace the OkHttp client used by React Native's networking library. However it has effectively been a noop since 0a71f48b13 (diff-177100ae5a977e4060b54cc2b34c79a7), when the Networking library was modified to create a new client rather than use the reference provided by OkHttpClientProvider.
Leaving this code in place is dangerous. There is no indication to users upgrading React Native that the method is no longer replacing the OkHttpClient used by the Networking library. Any functionality reliant on overriding the client will silently break. This caused us some problems internally.
There's been a PR out for some time that seeks to reintroduce this functionality: https://github.com/facebook/react-native/pull/14068
I've also put up a new PR that adds an interface for replacing the client without introducing breaking changes: https://github.com/facebook/react-native/pull/17237
Do our unit tests continue to pass? Should be safe as this method is not used anywhere inside React Native.
[ANDROID] [BREAKING] [Networking] - removed replaceOkHttpClient method in OkHttpClientProvider.
Pull Request resolved: https://github.com/facebook/react-native/pull/16972
Differential Revision: D13838805
Pulled By: cpojer
fbshipit-source-id: 43606d1d141afb9b5dda4dd64e5ac5448771b45c
Héctor Ramos
Joshua Gross
Matt Hargett
Kevin Gozali
Ramanpreet Nara
Eric Rozell
Richard Zito
zhongwuzw
scisci
Ram N
Oli Barnett
Ranjan Shrestha
cpojer
David Vacca
David Aurelio
Héctor Ramos
Elliott Sprehn
Teddy Martin
Shaun Stanworth
Michał Osadnik
rogerkerse
Rafael Lincoln
danibonilha
Mike Grabowski
Riley Dulin
Albert Sun
Bruno Nallis Villanova
Sunny Luo
Kesha Antonov
Connor McEwen
Chris Lewis
