Merge from upstream through 2020-05-09 #806
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary: Recently, a default Podfile has been modified to not contain all the React Native pods, but use a helper method `use_react_native!`. While this is great, it assumes a hardcoded path of `../node_modules/react-native` to be always the correct location of the React Native. https://github.com/facebook/react-native/blob/d4d8887b5018782eeb3f26efa85125e6bbff73e4/scripts/autolink-ios.rb#L7-L9 Unfortunately, due to the way Ruby works, this completely hides the path away from the users. Before, they could have seen the wrong path explicitly in a Podfile and knew to update it to resolve path-related issues. With the current version in `master`, I can see a lot of issues where developers wonder how to resolve the path issues and how to pass the path itself. https://github.com/facebook/react-native/blob/4118d798265341061105f3a53550db83c66a71cb/template/ios/Podfile#L5-L10 This PR uses React Native CLI configuration (that is already used to link 3rd party dependencies) to explicitly define the correct path to the React Native. As a result, we don't have to change the paths here whether we're running monorepo or not. ## Changelog [IOS] [INTERNAL] - Always provide an explicit path to React Native Pull Request resolved: facebook#28572 Differential Revision: D20945194 Pulled By: TheSavior fbshipit-source-id: 010f9754f2ed78ef62fd52f4d201f296f5af6d27
Summary: Upgrades Prettier in Xplat to 1.19.1 Ignores upgrading packages on already on versions greater than 1.19.1 Changelog: [Internal] allow-large-files bypass-lint (Note: this ignores all push blocking failures!) Reviewed By: gkz, cpojer Differential Revision: D20879147 fbshipit-source-id: 0deee7ac941e91e1c3c3a1e7d3d3ed20de1d657d
… in xplat Summary: Old deprecated function. Changelog: [Internal] Reviewed By: nlutsenko Differential Revision: D20148856 fbshipit-source-id: 79d6fb97824b059e50f67ff5a0b4c38ec7a19469
Summary: This adds a ProGuard for `hermes` rule so it does not have to be added by users manually. facebook#28270 ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [Android] [Added] - ProGuard rule for hermes Pull Request resolved: facebook#28571 Test Plan: 1. Create a project with/without hermes. 2. Enable proguard. Reviewed By: cpojer Differential Revision: D20947095 Pulled By: hramos fbshipit-source-id: 79b166ad2dd060f20041d9f5cfe2f794c754843d
Summary: Move CheckBox JS files to FB internal ## Changelog: [General] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module. Reviewed By: cpojer Differential Revision: D20910775 fbshipit-source-id: 809e135dc3f68911ac0a004e6eafa8488f0d5327
…#28526) Summary: With current master, when you render `<Pressable android_ripple={{borderless: false}}>`, there is no ripple effect at all. I think the expected behavior is to have ripple with default color and radius, just not borderless. This was how it was done (by me) in https://github.com/facebook/react-native/pull/28156/files but in the import process, the implementation was changed: facebook@bd38686 so either this PR is a fix or you can just close it (but I'd be curious why). ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [Android] [fixed] - ripple should be applied even when borderless == false Pull Request resolved: facebook#28526 Test Plan: `<Pressable android_ripple={{borderless: false}}>` on master  `<Pressable android_ripple={{borderless: false}}>` in this PR  Differential Revision: D20952026 Pulled By: TheSavior fbshipit-source-id: df2b95fc6f20d7e958e91805b1a928c4f85904f1
…acebook#28577) Summary: This change removes the `ColorAndroid` API. It was added more as a validation tool than as something useful to a developer. When making the original [PlatformColor PR](facebook#27908) we felt it was valuable and useful to have working platform specific methods for the two platforms in core to test that the pattern worked in app code (PlatformColorExample.js in RNTester) and that the Flow validation worked, etc. Practically `PlatformColor()` is more useful to a developer on Android than `ColorAndroid()`. Now that the construct has served its purpose, this PR removes the `ColorAndroid` function and its related tests and other collateral. ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [Android] [Removed] - Remove ColorAndroid function as it adds no value over PlatfromColor Pull Request resolved: facebook#28577 Test Plan: RNTester in both iOS and Android was tested. Jest tests, Flow checks, Lint checks all pass. Reviewed By: cpojer Differential Revision: D20952613 Pulled By: TheSavior fbshipit-source-id: 7d2cbaa2a347fffe59a1f3a26a210676008fdac0
Summary: Label some BUCK targets properly. Changelog: [Internal] Reviewed By: shergin Differential Revision: D20960917 fbshipit-source-id: 42fa2266105b6c3dd5108a1b56035a19a95cd61f
Summary: ``` Welcome to Gradle 6.3! Here are the highlights of this release: - Java 14 support - Improved error messages for unexpected failures For more details see https://docs.gradle.org/6.3/release-notes.html ``` ## Changelog [Android] [Changed] - Update Gradle Wrapper to 6.3 Pull Request resolved: facebook#28173 Test Plan: Build project Differential Revision: D20958894 Pulled By: mdvacca fbshipit-source-id: a02ab0eb6aff97148c12b844fdd1f9f2617ae53f
…er twice Summary: Calling `-[RCTRedBox showErrorMessage]` twice causes a crash We used `-[UIViewController isBeingPresented]` to tell whether view controller is already presented. But from the documentation: > A Boolean value indicating whether the view controller is being presented. Source: https://developer.apple.com/documentation/uikit/uiviewcontroller/2097564-beingpresented?language=objc# --- So this means that if you present it, wait until presentation animation is finished and then call `-[RCTRedBox showErrorMessage]` again, following exception will be thrown. ``` *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Application tried to present modally an active controller <UIViewController: 0x7fc33e422f50>.' ``` Changelog: Fix crash caused by presenting view controller twice from RCTRedBox Reviewed By: PeteTheHeat Differential Revision: D20946645 fbshipit-source-id: 763066e37db4e56efb0118b2e7867ad0724bae81
Summary: We currently see a lot of errors happens because of division by zero in `AnimatedDivision` module. We already have a check for that in the module but it happens during the animation tick where the context of execution is already lost and it's hard to find why exactly it happens. Adding an additional check to the constructor should trigger an error right inside render function which should make the error actionable. Changelog: [Internal] Early crash in AnimatedDivision in case of division by zero. Reviewed By: mdvacca Differential Revision: D20969087 fbshipit-source-id: 0d98774b79be2cc56d468a4f56d2d7c8abf58344
Summary: Now we can control the differentiator mode via MC. Changelog: [Internal] Fabric-specific internal change. Reviewed By: fkgozali Differential Revision: D20978857 fbshipit-source-id: 13264948762f02f874d8d051c873d378062d6db4
Summary: Use the latest published release of hermes-engine. Update RN to invoke `hermesc` instead of `hermes`. Changelog: [Android] [Changed] - Upgraded to Hermes 0.5.0 allow-large-files Reviewed By: mhorowitz Differential Revision: D20998564 fbshipit-source-id: 4824e273bcb044029a5a7e9379f168d3da47da50
… Undefined Summary: Make sure width/height is always passed as Undefined when measure mode is changed to Undefined. Changelog: [Internal][Yoga] Set width and height as Undefined when we change measure mode to Undefined Reviewed By: alickbass Differential Revision: D20029838 fbshipit-source-id: b9931f6ddb13ffd1565889535ade5bbffbe0c304
Summary: `const ReactNative` is assigned to but never used. Let's get rid of it. Changelog: [Internal] Reviewed By: JoshuaGross Differential Revision: D21016502 fbshipit-source-id: afcb0cfc501adf07e0c4d4452a831160e1cda088
…acebook#28580) Summary: This pull request updates RNTester's AppDelegate's Fabric mode to reflect changes made to the SurfacePresenter APIs. It now makes use of `RCTSurfacePresenterBridgeAdapter` to create its `SurfacePresenter`. ## Changelog [Internal] [Fixed] - Fixed outdated API usage in RNTester's AppDelegate Pull Request resolved: facebook#28580 Test Plan: `RNTester/RNTester/AppDelegate.mm` now compiles without error when `RN_FABRIC_ENABLED` is enabled. Reviewed By: hramos Differential Revision: D20966067 Pulled By: mdvacca fbshipit-source-id: 8d0168d468240cff61554f2f2df799aaf5d876c1
Summary: Early ViewCommand Dispatch will solve this category of crashes by going through an entirely different codepath. For users not in that experiment, it might be good to have a mitigation that prevents non-critical issues from crashing (like "blur" failing). Currently, "blur" failures cause lots of screens to crash. There's no useful signal and those crashes aren't super actionable, so seems better to swallow. If/when early viewcommand dispatch ships as the default/only mode, we can remove this try/catch entirely. The only concern I have with landing this is the perf implications of putting a try/catch inside this loop. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D21023213 fbshipit-source-id: 310fe2d55a44bc424692a2365ccd5882f35f9d82
Summary: Changelog: [Internal] We don't use view command `setMostRecentEventCount`, let's get rid of it. Reviewed By: JoshuaGross Differential Revision: D21016600 fbshipit-source-id: 6491c063e9d6a89252300cb47c010b248e473f4b
Summary: Enhance the label-actions config and support a "Type: Upgrade Issue" label. - Point to the Upgrade Support repository whenever the Type: Upgrade Issue label is applied. - Close the issue. Changelog: [Internal] label-actions: Add canned response for upgrade issues Reviewed By: cpojer Differential Revision: D20974607 fbshipit-source-id: 3cd7890aaeb1e57baf2acc5ca85a9b3ae5117c56
Summary: This pull request adds `YGNode.h` and `YGStyle.h` to the headers exported by Yoga's podspec. They are required by the new Fabric architecture of React Native. The modulemap and its umbrella header automatically generated by Cocoapods adds all exported headers to the `modulemap`. Having YGNode and YGStyle exported through here has problems, because they are only available in environments that have C++ available, and will produce errors otherwise. This pull request fences off the contents of those headers in an `#ifdef __cplusplus` block, so they will not cause errors when imported into environments where C++ isn't available. I had considered adding a custom modulemap to the podspec as part of this pull request, but this way seems the least "invasive", and this way you are able to add and remove exported headers in the podspec without needing to worry about updating the umbrella header at the same time. Changelog: [Internal] - Yoga Podspec: Export YGNore and YGStyle headers Pull Request resolved: facebook/yoga#997 Reviewed By: hramos Differential Revision: D20966075 Pulled By: mdvacca fbshipit-source-id: 5f5caa6b639d11e660b968d681da9a4de6c0eb8e
Summary: We're still seeing NativeModule eager-init crashes in T46487253. So, just to be extra careful, in case this diff doesn't fix the problem, I'm adding logging into `TurboModuleManager.getModule(moduleName)` to see why TurboModules are showing up as `null`. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D21027984 fbshipit-source-id: 74ee62aeac09a4fdb29547e90ef4fa7c07de17a6
Summary: This cache is unnecessary, because: 1. TurboModuleManager caches all created TurboModules 2. TurboModuleManager calls into the TurboModuleManagerDelegate at most once per NativeModule `moduleName`. This diff also makes ReactPackageTurboModuleManager thread-safe, which should help get rid of the crashes in T46487253. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D21027998 fbshipit-source-id: c9b5ccc3da7b81787b749e70aa5e55883317eed7
Summary: In D20659799, I improved `TurboModuleManager.getModule(moduleName)` thread-safety by ensuring that if two threads race to require the same NativeModule, only one thread creates the NativeModule, while the other one waits until it's created. ## The problem: What I failed to realize was that when two threads race to require two different NativeModules, we can get concurrent calls into `TurboModuleManagerDelegate.getModule(moduleName)`, and `TurboModuleManagerDelegate.getLegacyCxxModule(moduleName)`, which don't have any thread-safe guarantees. ## The fix `TurboModuleManagerDelegate` is supposed to be an input to the TurboModule system. So, rather than expecting that all TurboModuleManagerDelegates are thread-safe, which might be a reasonable ask (see T65532092), this diff has `TurboModuleManager` acquire the delegate's lock before calling into it. This ensures that we don't get concurrent access into the delegate, which could be reading from, or writing to, some data structure in these method calls. (This was the case with `ReactPackageTurboModuleManagerDelegate`, which is what Fb4a and Workplace use under the hood). Changelog: [Android][Fixed] - Control concurrent calls into TMMDelegate from TurboModuleManager Reviewed By: mdvacca Differential Revision: D21025965 fbshipit-source-id: d22c4abfe87f9e534717a06f186dde87d3cd24df
Summary: This release will include the new platform-colors rule. Changelog: [Internal] (Note: this ignores all push blocking failures!) Reviewed By: cpojer Differential Revision: D21022163 fbshipit-source-id: 65c831b3c820e44f75631b935118b043180ab3c7
Reviewed By: motiz88 Differential Revision: D20697095 fbshipit-source-id: ef35d02da0916109ce528d3026f7ca0956911dda
…ok#28625) Summary: The `cliPath` has always been optional value and in fact, even had its default value hardcoded in the React gradle file. In this PR, I am just taking use of it and remove throwing an error, which is going to be a really annoying breaking change. ## Changelog [ANDROID] [INTERNAL] - Don't require `cliPath` Pull Request resolved: facebook#28625 Test Plan: Run Android project, everything works. Provide custom `cliPath`, it gets respected Reviewed By: cpojer Differential Revision: D21044222 Pulled By: TheSavior fbshipit-source-id: 8029f988d92abb9f64f30e05932c0d407d0c997e
Summary: This fixes build failures where `CIRCLE_PR_NUMBER` is not set. This can happen if the PR did not come from a fork. ## Changelog [Internal] [Fixed] - Fix CIRCLE_PR_NUMBER may not always be set Pull Request resolved: facebook#28640 Test Plan: Report bundle size step should pass on both this PR and facebook#28641. Reviewed By: cpojer Differential Revision: D21045553 Pulled By: TheSavior fbshipit-source-id: fdfcb1bb88a96345b78ca69c49623df71d4cd608
Summary: This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper. Provided so that we don't drift too far from the Android code. Changelog: [Internal] Reviewed By: RSNara Differential Revision: D20784270 fbshipit-source-id: 6bb16431d25a6c093a583e2e041b8cffa6765ddd
Summary: > Starting April 30, 2020, all apps submitted to the App Store must use an Xcode storyboard to provide the app’s launch screen and all iPhone apps must support all iPhone screens. Updated iOS Launch screen as per [App Store policy change](https://developer.apple.com/news/?id=03042020b). Community discussion: react-native-community/discussions-and-proposals#209 ## Changelog Changed iOS Launch Screen from a `xib` to `storyboard`. The `LaunchScreen.xib` file has been replaced with `LaunchScreen.storyboard`. Xcode automatically picks up the new Launch Screen no additional change is required. [iOS] [Deleted] - Deleted LaunchScreen.xib [iOS] [Added] - Added LaunchScreen.storyboard Pull Request resolved: facebook#28239 Test Plan: Build the Xcode project under `template/iOS` and verify that the new launch screen is identical to the previous one. Reviewed By: cpojer Differential Revision: D20408892 Pulled By: hramos fbshipit-source-id: 9c38df58d1304088a23f3d73e0fbd87675804f1a
Summary:
## Problem
Every time we want to add, remove, or change the data passed to JavaTurboModule's constructor, we have to modify the C++ TurboModule codegen. (The same is true of `ObjCTurboModule`).
**Why was this necessary?**
- `JavaTurboModule` is effectively an abstract class whose constructor is always invoked by code-generated C++ classes. These C++ code-generated class constructors accept an argument list, and manually foward each and every item in that list to `JavaTurboModule::JavaTurboModule`.
## The fix
In this diff, I introduce a struct `JavaTurboModule::InitParams`, to represent a bag of arguments:
```
class JSI_EXPORT JavaTurboModule : public TurboModule {
public:
struct InitParams {
std::string moduleName;
jni::alias_ref<JTurboModule> instance;
std::shared_ptr<CallInvoker> jsInvoker;
std::shared_ptr<CallInvoker> nativeInvoker;
};
```
All `JavaTurboModules` will be created with an instance of this `InitParams` struct, instead of a list of arguments. Our code-generated C++ `jsi::HostObject` sublcasses will simply accept `InitParams` in their constructor, and forward it to `JavaTurboModule`'s constructor. This way, the codegen remains oblivious to what arguments JavaTurboModule requires.
## Okay, but why do we need this change now?
In the future, I plan to modify the constructor for `JavaTurboModule` to accept a performance logger, and a `RuntimeExecutor`. Similar modifications are planned for ObjC. For this reason, to avoid these four codemods, and any potential other codemods that occur because we're making modifications to `JavaTurboModule` or `ObjCTurboModule`, I'm launching this codemod, and the codemods in this stack.
## Misc Fix
- Previously, we were generating the TurboModule name from the Spec filename. This is incorrect because that name represents the spec name. Now, the name will be forwarded from TurboModuleManager in the `JavaTurboModule::InitParams` struct.
## Alternative implementations
I initially considered using `ContextContainer`, but decided against it because:
1. There are no type-safety guarantees.
2. I think it's a bit overkill for this scenario. We just need an opaque bag of data, and for our purposes a simple struct does the job fine.
## Commands run
Reviewed By: fkgozali
Differential Revision: D21035208
fbshipit-source-id: 9542cafea192081bc34d337ab3a7a783083eb06c
Summary:
Handle properties named 'id' as a special case.
An example of a native module that ran afoul of this is `ExceptionsManager`.
Observe how the ExceptionsManager spec at `Libraries/Core/NativeExceptionsManager.js` defines the ExceptionData type as containing an `id` property:
```
export type ExceptionData = {
message: string,
originalMessage: ?string,
name: ?string,
componentStack: ?string,
stack: Array<StackFrame>,
id: number,
isFatal: boolean,
// flowlint-next-line unclear-type:off
extraData?: Object,
...
};
```
Prior to this change, the generated code would redefine id in the SpecReportExceptionData struct...
```
namespace JS {
namespace NativeExceptionsManager {
struct SpecReportExceptionData {
// ...redacted...
double id() const; <---
// ...redacted...
SpecReportExceptionData(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
```
...which would result in a build time error:
```
inline double JS::NativeExceptionsManager::SpecReportExceptionData::id() const
{
id const p = _v[@"id"];
^--- build time error here
return RCTBridgingToDouble(p);
}
```
Comparing the above example with the currently checked in `FBReactNativeSpec.h`, I see the expected output should be:
```
namespace JS {
namespace NativeExceptionsManager {
struct SpecReportExceptionData {
// ...redacted...
double id_() const;
// ...redacted...
SpecReportExceptionData(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
```
...and...
```
inline double JS::NativeExceptionsManager::SpecReportExceptionData::id_() const
{
id const p = _v[@"id"];
return RCTBridgingToDouble(p);
}
```
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21395463
fbshipit-source-id: e412648013ff9f70ebd294b6f5f81f1faccb4604
Summary: This diff eager initializes Fabric Android classes. This should help load all the Fabric classes at Bridge load time. changelog: [Internal] Reviewed By: JoshuaGross Differential Revision: D21460507 fbshipit-source-id: 4b8d5c4e2d19e3a7eb3077027071e64ff16f1cbd
Summary: This removes the Hermes.setPauseOnLoad. It will be replaced by the more standard Debugger.setInstrumentationBreakpoint's "beforeScriptExecution" event. ChangeLog: [Internal] Remove Hermes.setPauseOnLoad message (to be replaced) Reviewed By: mhorowitz Differential Revision: D21418219 fbshipit-source-id: 93c53801c23487f9336b322c2bd737663ec21b97
Summary: This diff adds support for the "beforeScriptWithSourceMapExecution" instrumentation breakpoint via "Debugger.setInstrumentationBreakpoint". CDP describes it as a breakpoint, but we just set a flag in the inspector. A fake breakpoint ID is synthesized for optional removal later. Changelog: [Internal] Add Debugger.setInstrumentationBreakpoint to Hermes Inspector Reviewed By: mhorowitz Differential Revision: D21418218 fbshipit-source-id: 90fa49c0954980993815322d3a7effee416ed5db
Summary: For internal code attribution. Changelog: [Internal] Reviewed By: zlern2k Differential Revision: D21468924 fbshipit-source-id: 59cd2a52e0ae46bedbf54816820a5f40b684da8b
Summary: Adds a script that uses `react-native-codegen` to generate FBReactNativeSpec. The generated output should not be considered ready for production use at this time. The goal of adding this script at this time is to demonstrate the current status of native modules specs code generation in open source. For example, the generated output may be used in RNTester, with some modifications due to some naming differences in react-native-codegen's output when compared to the FBReactNativeSpec files generated by the old codegen. Usage: ``` ./scripts/generate-native-modules-specs.sh ./codegen-out ``` Changelog: [Internal] Reviewed By: TheSavior Differential Revision: D21471004 fbshipit-source-id: 5ff3c57807d9ba2c91dc7fe32d227d218732b059
Summary: When you profile your heap and memory allocations with Memory Profiler, files with *.hprof extension are created in /android folder that has big sizes (up to 600 MB for each). These files may be needed to add to gitignore. ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [Android] [Added] - Add *.hprof files to gitignore Pull Request resolved: facebook#28789 Differential Revision: D21432927 Pulled By: hramos fbshipit-source-id: a20f12645de5ca0874c9130094e2f97fe16b2203
Summary: *This is a follow-up to facebook#28645, redone using a build script based off of Metro's build script instead of using `flow-remove-types` and `flow-copy-source`.* This pull request adds a build step to `react-native-codegen` that builds the Flow-annotated JS files so that users of the NPM module `react-native-codegen` do not need to use require hooks to be able to import it. A new build script, `scripts/build.js` is added that builds every JS file in `src/` into a `lib/` folder, and also copies over the original Flow annotated files to `lib/` with a `.js.flow` extension, so users of `react-native-codegen` can still typecheck against it using Flow. The shell scripts in `src` are also copied over. It is based off of the [build script from Metro](https://github.com/facebook/metro/blob/00867816eb9b2f69c8af9cebb523e9e4d280671a/scripts/build.js) ## Changelog [General] [Added] - Codegen: Add prepublish script to build Flow files Pull Request resolved: facebook#28827 Test Plan: I am able to make use of the Codegen scripts without needing to use the `flow-node` CLI or the `flow-remove-types/register` require hook. Reviewed By: cpojer Differential Revision: D21412173 Pulled By: hramos fbshipit-source-id: 26ae67cdd04652ca4700a069a234a25558773cb1
Summary: Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D21483553 fbshipit-source-id: 0c681979a4988c36cfa6f05aa5bca896590f9e3d
Reviewed By: ejanzer Differential Revision: D21465166 fbshipit-source-id: b34e8e97330b897e20d9a4b05dba1826df569e16
Summary: Pull Request resolved: facebook#28851 This diff creates a RuntimeExecutor that uses the bridge and exposes it on CatalystInstanceImpl. Changelog: [Internal] Reviewed By: mdvacca, RSNara Differential Revision: D21051949 fbshipit-source-id: b3977fc14fa19089f33e297d29cedba0d067526d
Summary: This diff refactors the FrescoModule in order to receive an ImagePipeline as a parameter. This is necessary to ensure the same ImagePipeline is used by every RN module changelog: [Internal][Android] Reviewed By: JoshuaGross Differential Revision: D21428346 fbshipit-source-id: 70a6cc57c8585fe74b6d0b0d1fd86c539974ec23
Summary: This change is especially important for Fabric when a lot of objects (mostly `ShadowNode`s) have shared ownership. Without this change, JSVM could not know that bunch of natively allocated objects should be deallocated. Changelog: [Internal] Fabric-specific internal change. Reviewed By: dulinriley Differential Revision: D21484773 fbshipit-source-id: 46e32de0f108082e60df346884c9287023156149
Summary: Consolidates the logic for the default value of `blurOnSubmit` on `TextInput` in the JavaScript component. This only materially impacts Fabric. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D21491482 fbshipit-source-id: 16d8aba32e7d0321a4583e87e03405ea587e35d4
…an/0.64-merge-2020-mm-dd
…an/0.64-merge-2020-mm-dd
…an/0.64-merge-2020-mm-dd
|
I'm super excited to see macos integrating new upstream changes. Getting macOS up to date will have an incredibly large impact across the RN ecosystem. Something I've had success with for Windows merges was to limit a single integration to about a week of upstream changes. At that granularity you can inspect individual commits, either looking for changes that intersect with forked code, or doing a narrow search for what change could have caused a regression. |
|
"One of the more unusual modifications we had to do to ensure compatibility is the addition of the #if 0 block in React/CoreModules/RCTDevLoadingView.mm. Thankfully, we're blocking out unused code, so it shouldn't be a big deal. This will get cleaned up once we fix this upstream and get microsoft/react-native-macos caught up to that future commit." Can you elaborate on this? How do we know it's unused? Did fb add a #if 0 and we just don't have that commit synced yet? |
I've been doing this locally when moving forward. This PR is just several of these steps forward at a time. |
I know |
HeyImChris
approved these changes
Aug 3, 2021
| if (!CGRectIsEmpty(self.clipping)) { | ||
| CGContextClipToRect(context, self.clipping); | ||
| } | ||
|
|
||
| for (ARTNode *node in self.subviews) { | ||
| [node renderTo:context]; | ||
| for (RCTPlatformView *subview in self.subviews) { // TODO(macOS GH#774) |
There was a problem hiding this comment.
Did you add this? If so can we be explicit exactly what lines we're adding and why?
There was a problem hiding this comment.
The only thing I changed is replacing UIView with RCTPlatformView.
HeyImChris
pushed a commit
to HeyImChris/react-native-macos
that referenced
this pull request
Sep 2, 2021
* Update default Podfile to not depend on a path (#28572)
Summary:
Recently, a default Podfile has been modified to not contain all the React Native pods, but use a helper method `use_react_native!`.
While this is great, it assumes a hardcoded path of `../node_modules/react-native` to be always the correct location of the React Native.
https://github.com/facebook/react-native/blob/d4d8887b5018782eeb3f26efa85125e6bbff73e4/scripts/autolink-ios.rb#L7-L9
Unfortunately, due to the way Ruby works, this completely hides the path away from the users.
Before, they could have seen the wrong path explicitly in a Podfile and knew to update it to resolve path-related issues.
With the current version in `master`, I can see a lot of issues where developers wonder how to resolve the path issues and how to pass the path itself.
https://github.com/facebook/react-native/blob/4118d798265341061105f3a53550db83c66a71cb/template/ios/Podfile#L5-L10
This PR uses React Native CLI configuration (that is already used to link 3rd party dependencies) to explicitly define the correct path to the React Native.
As a result, we don't have to change the paths here whether we're running monorepo or not.
## Changelog
[IOS] [INTERNAL] - Always provide an explicit path to React Native
Pull Request resolved: https://github.com/facebook/react-native/pull/28572
Differential Revision: D20945194
Pulled By: TheSavior
fbshipit-source-id: 010f9754f2ed78ef62fd52f4d201f296f5af6d27
* Upgrade Prettier in Xplat to version 1.19.1
Summary:
Upgrades Prettier in Xplat to 1.19.1
Ignores upgrading packages on already on versions greater than 1.19.1
Changelog: [Internal]
allow-large-files
bypass-lint
(Note: this ignores all push blocking failures!)
Reviewed By: gkz, cpojer
Differential Revision: D20879147
fbshipit-source-id: 0deee7ac941e91e1c3c3a1e7d3d3ed20de1d657d
* Stop using get_fbobjc_enable_exception_lang_compiler_flags_DEPRECATED in xplat
Summary:
Old deprecated function.
Changelog: [Internal]
Reviewed By: nlutsenko
Differential Revision: D20148856
fbshipit-source-id: 79d6fb97824b059e50f67ff5a0b4c38ec7a19469
* Add ProGuard rule for hermes (#28571)
Summary:
This adds a ProGuard for `hermes` rule so it does not have to be added by users manually.
https://github.com/facebook/react-native/issues/28270
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Added] - ProGuard rule for hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/28571
Test Plan:
1. Create a project with/without hermes.
2. Enable proguard.
Reviewed By: cpojer
Differential Revision: D20947095
Pulled By: hramos
fbshipit-source-id: 79b166ad2dd060f20041d9f5cfe2f794c754843d
* Move CheckBox JS files to FB Internal
Summary:
Move CheckBox JS files to FB internal
## Changelog:
[General] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.
Reviewed By: cpojer
Differential Revision: D20910775
fbshipit-source-id: 809e135dc3f68911ac0a004e6eafa8488f0d5327
* fix: ripple should be applied even when borderless == false (#28526)
Summary:
With current master, when you render `<Pressable android_ripple={{borderless: false}}>`, there is no ripple effect at all.
I think the expected behavior is to have ripple with default color and radius, just not borderless.
This was how it was done (by me) in https://github.com/facebook/react-native/pull/28156/files but in the import process, the implementation was changed: https://github.com/facebook/react-native/commit/bd3868643d29e93610e19312571a9736df2cbdf8 so either this PR is a fix or you can just close it (but I'd be curious why).
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [fixed] - ripple should be applied even when borderless == false
Pull Request resolved: https://github.com/facebook/react-native/pull/28526
Test Plan:
`<Pressable android_ripple={{borderless: false}}>` on master
`<Pressable android_ripple={{borderless: false}}>` in this PR
Differential Revision: D20952026
Pulled By: TheSavior
fbshipit-source-id: df2b95fc6f20d7e958e91805b1a928c4f85904f1
* Remove ColorAndroid function as it adds no value over PlatfromColor (#28577)
Summary:
This change removes the `ColorAndroid` API. It was added more as a validation tool than as something useful to a developer. When making the original [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) we felt it was valuable and useful to have working platform specific methods for the two platforms in core to test that the pattern worked in app code (PlatformColorExample.js in RNTester) and that the Flow validation worked, etc. Practically `PlatformColor()` is more useful to a developer on Android than `ColorAndroid()`. Now that the construct has served its purpose, this PR removes the `ColorAndroid` function and its related tests and other collateral.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Removed] - Remove ColorAndroid function as it adds no value over PlatfromColor
Pull Request resolved: https://github.com/facebook/react-native/pull/28577
Test Plan: RNTester in both iOS and Android was tested. Jest tests, Flow checks, Lint checks all pass.
Reviewed By: cpojer
Differential Revision: D20952613
Pulled By: TheSavior
fbshipit-source-id: 7d2cbaa2a347fffe59a1f3a26a210676008fdac0
* iOS: mark some old NativeModule targets with depslint_never_remove
Summary:
Label some BUCK targets properly.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D20960917
fbshipit-source-id: 42fa2266105b6c3dd5108a1b56035a19a95cd61f
* Update Gradle Wrapper to 6.3 (#28173)
Summary:
```
Welcome to Gradle 6.3!
Here are the highlights of this release:
- Java 14 support
- Improved error messages for unexpected failures
For more details see https://docs.gradle.org/6.3/release-notes.html
```
## Changelog
[Android] [Changed] - Update Gradle Wrapper to 6.3
Pull Request resolved: https://github.com/facebook/react-native/pull/28173
Test Plan: Build project
Differential Revision: D20958894
Pulled By: mdvacca
fbshipit-source-id: a02ab0eb6aff97148c12b844fdd1f9f2617ae53f
* Fix crash inside RCTRedBox when trying to present same UIViewController twice
Summary:
Calling `-[RCTRedBox showErrorMessage]` twice causes a crash
We used `-[UIViewController isBeingPresented]` to tell whether view controller is already presented.
But from the documentation:
> A Boolean value indicating whether the view controller is being presented.
Source: https://developer.apple.com/documentation/uikit/uiviewcontroller/2097564-beingpresented?language=objc#
---
So this means that if you present it, wait until presentation animation is finished and then call `-[RCTRedBox showErrorMessage]` again, following exception will be thrown.
```
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Application tried to present modally an active controller <UIViewController: 0x7fc33e422f50>.'
```
Changelog: Fix crash caused by presenting view controller twice from RCTRedBox
Reviewed By: PeteTheHeat
Differential Revision: D20946645
fbshipit-source-id: 763066e37db4e56efb0118b2e7867ad0724bae81
* Animated: Early detection of division by zero in AnimatedDivision
Summary:
We currently see a lot of errors happens because of division by zero in `AnimatedDivision` module. We already have a check for that in the module but it happens during the animation tick where the context of execution is already lost and it's hard to find why exactly it happens.
Adding an additional check to the constructor should trigger an error right inside render function which should make the error actionable.
Changelog: [Internal] Early crash in AnimatedDivision in case of division by zero.
Reviewed By: mdvacca
Differential Revision: D20969087
fbshipit-source-id: 0d98774b79be2cc56d468a4f56d2d7c8abf58344
* Fabric: Controlling DifferentiatorMode via ReactNativeConfig
Summary:
Now we can control the differentiator mode via MC.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: fkgozali
Differential Revision: D20978857
fbshipit-source-id: 13264948762f02f874d8d051c873d378062d6db4
* Upgrade Hermes dependency to 0.5.0
Summary:
Use the latest published release of hermes-engine. Update RN to invoke `hermesc` instead of `hermes`.
Changelog: [Android] [Changed] - Upgraded to Hermes 0.5.0
allow-large-files
Reviewed By: mhorowitz
Differential Revision: D20998564
fbshipit-source-id: 4824e273bcb044029a5a7e9379f168d3da47da50
* Set width/height also to Undefined when we change the measure mode to Undefined
Summary:
Make sure width/height is always passed as Undefined when measure mode is changed to Undefined.
Changelog: [Internal][Yoga] Set width and height as Undefined when we change measure mode to Undefined
Reviewed By: alickbass
Differential Revision: D20029838
fbshipit-source-id: b9931f6ddb13ffd1565889535ade5bbffbe0c304
* Remove redundant input from TextInput
Summary:
`const ReactNative` is assigned to but never used. Let's get rid of it.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21016502
fbshipit-source-id: afcb0cfc501adf07e0c4d4452a831160e1cda088
* Update RNTester AppDelegate for changes made to SurfacePresenter API (#28580)
Summary:
This pull request updates RNTester's AppDelegate's Fabric mode to reflect changes made to the SurfacePresenter APIs. It now makes use of `RCTSurfacePresenterBridgeAdapter` to create its `SurfacePresenter`.
## Changelog
[Internal] [Fixed] - Fixed outdated API usage in RNTester's AppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/28580
Test Plan: `RNTester/RNTester/AppDelegate.mm` now compiles without error when `RN_FABRIC_ENABLED` is enabled.
Reviewed By: hramos
Differential Revision: D20966067
Pulled By: mdvacca
fbshipit-source-id: 8d0168d468240cff61554f2f2df799aaf5d876c1
* Retryable ViewCommand exceptions shouldn't crash
Summary:
Early ViewCommand Dispatch will solve this category of crashes by going through an entirely different codepath. For users not in that experiment, it might be good to have a mitigation that prevents non-critical issues from crashing (like "blur" failing).
Currently, "blur" failures cause lots of screens to crash. There's no useful signal and those crashes aren't super actionable, so seems better to swallow.
If/when early viewcommand dispatch ships as the default/only mode, we can remove this try/catch entirely.
The only concern I have with landing this is the perf implications of putting a try/catch inside this loop.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21023213
fbshipit-source-id: 310fe2d55a44bc424692a2365ccd5882f35f9d82
* Remove setMostRecentEventCount from TextInput view commands
Summary:
Changelog: [Internal]
We don't use view command `setMostRecentEventCount`, let's get rid of it.
Reviewed By: JoshuaGross
Differential Revision: D21016600
fbshipit-source-id: 6491c063e9d6a89252300cb47c010b248e473f4b
* label-actions: Add canned response for upgrade issues
Summary:
Enhance the label-actions config and support a "Type: Upgrade Issue" label.
- Point to the Upgrade Support repository whenever the Type: Upgrade Issue label is applied.
- Close the issue.
Changelog:
[Internal] label-actions: Add canned response for upgrade issues
Reviewed By: cpojer
Differential Revision: D20974607
fbshipit-source-id: 3cd7890aaeb1e57baf2acc5ca85a9b3ae5117c56
* Yoga Podspec: Export YGNode and YGStyle headers (#997)
Summary:
This pull request adds `YGNode.h` and `YGStyle.h` to the headers exported by Yoga's podspec. They are required by the new Fabric architecture of React Native.
The modulemap and its umbrella header automatically generated by Cocoapods adds all exported headers to the `modulemap`. Having YGNode and YGStyle exported through here has problems, because they are only available in environments that have C++ available, and will produce errors otherwise.
This pull request fences off the contents of those headers in an `#ifdef __cplusplus` block, so they will not cause errors when imported into environments where C++ isn't available.
I had considered adding a custom modulemap to the podspec as part of this pull request, but this way seems the least "invasive", and this way you are able to add and remove exported headers in the podspec without needing to worry about updating the umbrella header at the same time.
Changelog:
[Internal] - Yoga Podspec: Export YGNore and YGStyle headers
Pull Request resolved: https://github.com/facebook/yoga/pull/997
Reviewed By: hramos
Differential Revision: D20966075
Pulled By: mdvacca
fbshipit-source-id: 5f5caa6b639d11e660b968d681da9a4de6c0eb8e
* Add logging to catch null TurboModules
Summary:
We're still seeing NativeModule eager-init crashes in T46487253. So, just to be extra careful, in case this diff doesn't fix the problem, I'm adding logging into `TurboModuleManager.getModule(moduleName)` to see why TurboModules are showing up as `null`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21027984
fbshipit-source-id: 74ee62aeac09a4fdb29547e90ef4fa7c07de17a6
* Remove module cache from ReactPackageTurboModuleManagerDelegate
Summary:
This cache is unnecessary, because:
1. TurboModuleManager caches all created TurboModules
2. TurboModuleManager calls into the TurboModuleManagerDelegate at most once per NativeModule `moduleName`.
This diff also makes ReactPackageTurboModuleManager thread-safe, which should help get rid of the crashes in T46487253.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21027998
fbshipit-source-id: c9b5ccc3da7b81787b749e70aa5e55883317eed7
* Control concurrent calls into TMMDelegate from TMM
Summary:
In D20659799, I improved `TurboModuleManager.getModule(moduleName)` thread-safety by ensuring that if two threads race to require the same NativeModule, only one thread creates the NativeModule, while the other one waits until it's created.
## The problem:
What I failed to realize was that when two threads race to require two different NativeModules, we can get concurrent calls into `TurboModuleManagerDelegate.getModule(moduleName)`, and `TurboModuleManagerDelegate.getLegacyCxxModule(moduleName)`, which don't have any thread-safe guarantees.
## The fix
`TurboModuleManagerDelegate` is supposed to be an input to the TurboModule system. So, rather than expecting that all TurboModuleManagerDelegates are thread-safe, which might be a reasonable ask (see T65532092), this diff has `TurboModuleManager` acquire the delegate's lock before calling into it. This ensures that we don't get concurrent access into the delegate, which could be reading from, or writing to, some data structure in these method calls. (This was the case with `ReactPackageTurboModuleManagerDelegate`, which is what Fb4a and Workplace use under the hood).
Changelog:
[Android][Fixed] - Control concurrent calls into TMMDelegate from TurboModuleManager
Reviewed By: mdvacca
Differential Revision: D21025965
fbshipit-source-id: d22c4abfe87f9e534717a06f186dde87d3cd24df
* Bump eslint-plugin-react-native-community version to 1.1.0
Summary:
This release will include the new platform-colors rule.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D21022163
fbshipit-source-id: 65c831b3c820e44f75631b935118b043180ab3c7
* Update Babel to 7.8.x/7.9.x
Reviewed By: motiz88
Differential Revision: D20697095
fbshipit-source-id: ef35d02da0916109ce528d3026f7ca0956911dda
* fix: do not throw on missing `cliPath`, use the default value (#28625)
Summary:
The `cliPath` has always been optional value and in fact, even had its default value hardcoded in the React gradle file.
In this PR, I am just taking use of it and remove throwing an error, which is going to be a really annoying breaking change.
## Changelog
[ANDROID] [INTERNAL] - Don't require `cliPath`
Pull Request resolved: https://github.com/facebook/react-native/pull/28625
Test Plan:
Run Android project, everything works.
Provide custom `cliPath`, it gets respected
Reviewed By: cpojer
Differential Revision: D21044222
Pulled By: TheSavior
fbshipit-source-id: 8029f988d92abb9f64f30e05932c0d407d0c997e
* Fix CIRCLE_PR_NUMBER may not always be set (#28640)
Summary:
This fixes build failures where `CIRCLE_PR_NUMBER` is not set. This can happen if the PR did not come from a fork.
## Changelog
[Internal] [Fixed] - Fix CIRCLE_PR_NUMBER may not always be set
Pull Request resolved: https://github.com/facebook/react-native/pull/28640
Test Plan: Report bundle size step should pass on both this PR and https://github.com/facebook/react-native/issues/28641.
Reviewed By: cpojer
Differential Revision: D21045553
Pulled By: TheSavior
fbshipit-source-id: fdfcb1bb88a96345b78ca69c49623df71d4cd608
* Add "Open Debugger" and "Open React DevTools" to iOS dev menu
Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper. Provided so that we don't drift too far from the Android code.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D20784270
fbshipit-source-id: 6bb16431d25a6c093a583e2e041b8cffa6765ddd
* Changed iOS LaunchScreen from xib to storyboard (#28239)
Summary:
> Starting April 30, 2020, all apps submitted to the App Store must use an Xcode storyboard to provide the app’s launch screen and all iPhone apps must support all iPhone screens.
Updated iOS Launch screen as per [App Store policy change](https://developer.apple.com/news/?id=03042020b).
Community discussion: https://github.com/react-native-community/discussions-and-proposals/issues/209
## Changelog
Changed iOS Launch Screen from a `xib` to `storyboard`. The `LaunchScreen.xib` file has been replaced with `LaunchScreen.storyboard`. Xcode automatically picks up the new Launch Screen no additional change is required.
[iOS] [Deleted] - Deleted LaunchScreen.xib
[iOS] [Added] - Added LaunchScreen.storyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/28239
Test Plan: Build the Xcode project under `template/iOS` and verify that the new launch screen is identical to the previous one.
Reviewed By: cpojer
Differential Revision: D20408892
Pulled By: hramos
fbshipit-source-id: 9c38df58d1304088a23f3d73e0fbd87675804f1a
* Switch over to JavaTurboModule::InitParams
Summary:
## Problem
Every time we want to add, remove, or change the data passed to JavaTurboModule's constructor, we have to modify the C++ TurboModule codegen. (The same is true of `ObjCTurboModule`).
**Why was this necessary?**
- `JavaTurboModule` is effectively an abstract class whose constructor is always invoked by code-generated C++ classes. These C++ code-generated class constructors accept an argument list, and manually foward each and every item in that list to `JavaTurboModule::JavaTurboModule`.
## The fix
In this diff, I introduce a struct `JavaTurboModule::InitParams`, to represent a bag of arguments:
```
class JSI_EXPORT JavaTurboModule : public TurboModule {
public:
struct InitParams {
std::string moduleName;
jni::alias_ref<JTurboModule> instance;
std::shared_ptr<CallInvoker> jsInvoker;
std::shared_ptr<CallInvoker> nativeInvoker;
};
```
All `JavaTurboModules` will be created with an instance of this `InitParams` struct, instead of a list of arguments. Our code-generated C++ `jsi::HostObject` sublcasses will simply accept `InitParams` in their constructor, and forward it to `JavaTurboModule`'s constructor. This way, the codegen remains oblivious to what arguments JavaTurboModule requires.
## Okay, but why do we need this change now?
In the future, I plan to modify the constructor for `JavaTurboModule` to accept a performance logger, and a `RuntimeExecutor`. Similar modifications are planned for ObjC. For this reason, to avoid these four codemods, and any potential other codemods that occur because we're making modifications to `JavaTurboModule` or `ObjCTurboModule`, I'm launching this codemod, and the codemods in this stack.
## Misc Fix
- Previously, we were generating the TurboModule name from the Spec filename. This is incorrect because that name represents the spec name. Now, the name will be forwarded from TurboModuleManager in the `JavaTurboModule::InitParams` struct.
## Alternative implementations
I initially considered using `ContextContainer`, but decided against it because:
1. There are no type-safety guarantees.
2. I think it's a bit overkill for this scenario. We just need an opaque bag of data, and for our purposes a simple struct does the job fine.
## Commands run
Reviewed By: fkgozali
Differential Revision: D21035208
fbshipit-source-id: 9542cafea192081bc34d337ab3a7a783083eb06c
* RN: Shrinkwrap Text Layout (Android)
Summary:
When text is in a constrained parent view using `maxWidth`, long text may wrap. When the text wraps, the final width is dependent on the word breaking strategy and text content. This means that the text width is not necessarily `maxWidth`.
However, the current way that we compute text layout does not shrinkwrap the text width as much as possible. This leads to visual gaps to the end-side of wrapped text.
This changes the text layout slightly so that we use the length of the longest line.
This bug only exists on Android. After this change, Android behaves like iOS.
Changelog:
[Android] [Fixed] - Fixed excessive space in Text view with word-wrapping
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D21056031
fbshipit-source-id: e9b7793f2632caafcce69bc15bac61330b0ed958
* (eslint-config) update community eslint plugin in eslint config (#28642)
Summary:
Updating the community eslint-plugin used in the eslint-config to the latest version.
expecting new eslint-config version to be released with this change so that it can be included in new project template for 0.63 https://github.com/react-native-community/releases/issues/186
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Changed] - Update community eslint plugin in the eslint config
Pull Request resolved: https://github.com/facebook/react-native/pull/28642
Test Plan: yarn lint passes
Differential Revision: D21048976
Pulled By: cpojer
fbshipit-source-id: 2c3ec0ef450cf357d8c88db7873f4ca1154b2034
* chore: update CLI to the latest version (#28623)
Summary:
Bumps CLI to the latest version, needed by https://github.com/facebook/react-native/pull/28572 to work.
## Changelog
[INTERNAL] - Bump CLI to latest
Pull Request resolved: https://github.com/facebook/react-native/pull/28623
Reviewed By: hramos
Differential Revision: D21017766
Pulled By: cpojer
fbshipit-source-id: 62a873923c58f8752edb0394db7e6dfceed92485
* Add "Open Debugger" and "Open React DevTools" to Android dev menu
Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20784279
fbshipit-source-id: caecdace00007224692d994a75c106842c8b2acb
* Remove the post install step (#28651)
Summary:
Removes the post install step for Flipper, as the latest version of YogaKit is compatible with swift 5.
cc alloy
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Flipper] [Template] - Remove the post install step for Flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/28651
Test Plan: Tested a newly created RN app without post install step and it built successfully.
Reviewed By: passy
Differential Revision: D21064653
Pulled By: priteshrnandgaonkar
fbshipit-source-id: da56d0754d918e30a0ebe480c77590f0139d48ac
* Revert D21064653: Remove the post install step
Differential Revision:
D21064653
Original commit changeset: da56d0754d91
fbshipit-source-id: 1086cfdeca9aa3830370ea115ba7b5f05d3fb124
* Remove out of date TODO
Summary:
No longer relevant.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D21070955
fbshipit-source-id: 11b0384501b2780f5ac41899b5e8bbb4f7a4d730
* RNTester LayoutAnimation example: add more options
Summary:
Add more options to the LayoutAnimation example so it's easier to test more features of LayoutAnimations.
1) Add an option to animate reordering of views
2) Make animations slower, so it's easier to see what's going on and easier to trigger race conditions
3) Add options to mutate without animation, to test interrupting existing animations
Changelog: [Internal] Updated Catalyst RNTester LayoutAnimation example with additional options
Reviewed By: mdvacca
Differential Revision: D21050309
fbshipit-source-id: 1daba4fd487693c34a2d40eb39a68c7d03c24f93
* Add a "reparenting" LayoutAnimation example that animates flattening/unflattening
Summary:
Simple test to see what it looks like when view flattening/unflattening is animated with LayoutAnimations.
Changelog: [Internal] adding another example to LayoutAnimations example
Reviewed By: mdvacca
Differential Revision: D21074805
fbshipit-source-id: 551ed740f0ab5c5adcb19f5c35e932b8983cd108
* Fix jsi cmake include dirs (#207)
Summary:
I'm trying to use JSI for a React Native custom module. I saw these existing examples where the JSI API is used in the context of a CMakeLists.txt:
https://github.com/terrysahaidak/host-object-test/blob/master/libs/android-jsi/test-jsi/src/main/cpp/CMakeLists.txt
https://github.com/ericlewis/react-native-hostobject-demo/pull/4/files#diff-834320be1b4e4016bac27c05dcd17fb9
In both cases, they manually grab the include directories and jsi.cpp from node_modules/react-native, but I also saw that node_modules/react-native/ReactCommon/jsi/jsi already has a CMakeLists.txt that appears to be intended to provide a jsi static lib, so I tried to pull this into my own CMakeLists.txt like this:
```
add_subdirectory(${RN_DIR}/ReactCommon/jsi/jsi ${CMAKE_CURRENT_BINARY_DIR}/jsi)
...
target_link_libraries(MyLib jsi)
```
Unfortunately when doing this, the consuming project still doesn't see the correct include directories. The change I'm proposing here is to use `target_include_directories` and declare that `..` is a public (to consumers) include directory for the library named `jsi`. With this change, you can do what I showed above to consume the jsi lib by just pulling in the CMakeLists.txt file into your own CMakeLists.txt file.
Changelog: [General][Fixed] Fix jsi cmake include dirs
Pull Request resolved: https://github.com/facebook/hermes/pull/207
Reviewed By: willholen
Differential Revision: D21074270
Pulled By: tmikov
fbshipit-source-id: 7d9ec3255f57a16c0b2be489dffa4540727738a1
* Resolve `kind-of` vulnerability by bumping to 6.0.3
Summary:
https://github.com/advisories/GHSA-6c8f-qphg-qjgp
Changelog:
[General][Changed] Updated transitive dependency kind-of to 6.0.3 to resolve vulnerability
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D21077747
fbshipit-source-id: d5c19b21b665130c6423f5caeddcd6378bac7dcb
* Move CheckBox Android files to FB internal (#28658)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28658
This moves the Java files to FB internal and updates all the buck files.
## Changelog:
[Android] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.
Reviewed By: cpojer
Differential Revision: D21066998
fbshipit-source-id: 76821fcae899ff7342697ea7dd4737ef3b008213
* Part 1: Update ObjC++ codegen classes to use ObjCTurboModule::InitParams
Summary:
## Summary
Please check out D21035208.
## Changes
- `ObjCTurboModule::ObjCTurboModule` changed to accept a bag of arguments `const ObjCTurboModule::InitParams` instead of an argument list.
- TurboModule iOS codegen scripts updated to generated `ObjCTurboModule` subclasses that accept a `const ObjCTurboModule::InitParams` object in their constructor, and forward it to `ObjCTurboModule::ObjCTurboModule`.
- All manually checked in code-generated ObjC++ classes (i.e: RCTNativeSampleTurboModule, RCTTestModule, FBReactNativeSpec) are updated.
## Rationale
This way, the code-gen can remain constant while we add, remove, or modify the arguments passed to ObjCTurboModule.
## Commands run
```
function update-codegen() {
pushd ~/fbsource && js1 build oss-native-modules-specs -p ios && js1 build oss-native-modules-specs -p android && popd;
}
> update-codegen
```
Changelog:
[iOS][Changed] Update ObjCTurboModule to use ObjCTurboModule::InitParams
Reviewed By: PeteTheHeat
Differential Revision: D21036266
fbshipit-source-id: 6584b0838dca082a69e8c14c7ca50c3568b95086
* Part 2: Update ObjC++ codegen classes to use ObjCTurboModule::InitParams
Summary:
## Summary
Please check out D21035209.
## Changes
- Codemod all ObjC NativeModule `getTurboModuleWithJsInvoker:nativeInvoker:perfLogger` methods to `getTurboModule:(const ObjCTurboModule::Args)`
## Script
```
var withSpaces = (...args) => args.join('\s*')
var regexString = withSpaces(
'-',
'\(',
'std::shared_ptr',
'<',
'(?<turboModuleClass>(facebook::react::|react::|::|)TurboModule)',
'>',
'\)',
'getTurboModuleWithJsInvoker',
':',
'\(',
'std::shared_ptr',
'<',
'(?<fbNamespace>(facebook::react::|react::|::|))CallInvoker',
'>',
'\)',
'(?<jsInvokerInstance>[A-Za-z0-9]+)',
'nativeInvoker',
':',
'\(',
'std::shared_ptr',
'<',
'(facebook::react::|react::|::|)CallInvoker',
'>',
'\)',
'(?<nativeInvokerInstance>[A-Za-z0-9]+)',
'perfLogger',
':',
'\(',
'id',
'<',
'RCTTurboModulePerformanceLogger',
'>',
'\)',
'(?<perfLoggerInstance>[A-Za-z0-9]+)',
'{',
'return',
'std::make_shared',
'<',
'(?<specName>(facebook::react::|react::|::|)Native[%A-Za-z0-9]+SpecJSI)',
'>',
'\(',
'self',
',',
'\k<jsInvokerInstance>',
',',
'\k<nativeInvokerInstance>',
',',
'\k<perfLoggerInstance>',
'\)',
';',
'}',
)
var replaceString = `- (std::shared_ptr<$<turboModuleClass>>) getTurboModule:(const $<fbNamespace>ObjCTurboModule::InitParams &)params
{
return std::make_shared<$<specName>>(params);
}`
const exec = require('../lib/exec');
const abspath = require('../lib/abspath');
const relpath = require('../lib/relpath');
const readFile = (filename) => require('fs').readFileSync(filename, 'utf8');
const writeFile = (filename, content) => require('fs').writeFileSync(filename, content);
function main() {
const tmFiles = exec('cd ~/fbsource && xbgs -n 10000 -l getTurboModuleWithJsInvoker:').split('\n').filter(Boolean);
tmFiles
.filter((filename) => !filename.includes('microsoft-fork-of-react-native'))
.map(abspath)
.forEach((filename) => {
const source = readFile(filename);
const newSource = source.replace(new RegExp(regexString, 'g'), replaceString);
if (source == newSource) {
console.log(relpath(filename));
}
writeFile(filename, newSource);
});
}
if (!module.parent) {
main();
}
```
## Re-generating diff
```
> hg revert -r .^ --all
> node index.js # run script
```
Changelog: [iOS][Changed] - Make all ObjC NativeModules create TurboModules using ObjCTurboModule::Args
Reviewed By: PeteTheHeat
Differential Revision: D21036265
fbshipit-source-id: 404bcc548d1775ef23d793527606d02fe384a0a2
* Part 3: Update RCTTurboModuleManagerDelegate to use ObjCTurboModule::InitParams
Summary:
## Summary
Please check out D21035208.
## Changes
- Update `RCTTurboModuleManagerDelegate getTurboModule:instance:jsInvoker:nativeInvoker:perfLogger` to use `RCTTurboModuleManagerDelegate getTurboModule:(const ObjCTurboModule::InitParams)`
- Update all implementations of `RCTTurboModuleManagerDelegate` in accordance with this API change
Changelog:
[iOS][Changed] - Make RCTTurboModuleManagerDelegate create TurboModules via ObjCTurboModuleManager::InitParams
Reviewed By: PeteTheHeat
Differential Revision: D21036272
fbshipit-source-id: c16002c47db26e2ba143fc1080afe9e2fe1e7816
* chore: update `./scripts/test-manual-e2e.sh` (#28653)
Summary:
Recent changes broke the script - wrong path to open `RNTesterPods.xcworkspace` and other scripts - we change dir with `cd`.
Another change is incorrect use of `RNTesterProject.xcodeproj` instead of a `xcworkspace`.
This PR is a simple and short fix to make it run.
## Changelog
[INTERNAL] - chore: update `./scripts/test-manual-e2e.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/28653
Test Plan: Run `./scripts/test-manual-e2e.sh`. Things work.
Differential Revision: D21079792
Pulled By: hramos
fbshipit-source-id: 6bdb8be016f044852ed216ec53f80db40c84b5fd
* use default value of enums YGDirection and YGMeasureMode instead of -1
Summary:
Changelog:
[Internal][Yoga] YGDirection variable was initialized incorrectly by casting -1 to YGDirection. Changing it to default value of direction
Same for YGMeasureMode.
Reviewed By: pasqualeanatriello
Differential Revision: D20869042
fbshipit-source-id: 7bfe490193321baae875ef6fb49a938851950c9f
* fix typo as there is no file called YGJNI.cpp (#990)
Summary:
fix typo in `YogaJNIBase.java` as there is no such file called `YGJNI.cpp`
Pull Request resolved: https://github.com/facebook/yoga/pull/990
Reviewed By: pasqualeanatriello
Differential Revision: D20735102
Pulled By: SidharthGuglani
fbshipit-source-id: 3f9f4d78ba390feae3451330f997a221ab4ec70e
* Remove unused packages from xplat/js/package.json
Summary:
We have a large amount of small packages that are completely unused, or only have one call site. This diff cleans up a lot of them and reduces node_modules by 12 MiB (down to 187).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D21088213
fbshipit-source-id: 5fa7d3da5cbe744b0d9d3e3450d6135c1488ee79
* Make ColorValue public in StyleSheet.js
Summary:
This diff makes the ColorValue export "official" by exporting it from StyleSheet in order to encourage its use in product code.
Changelog: Moved ColorValue export from StyleSheetTypes to StyleSheet
Reviewed By: TheSavior
Differential Revision: D21076969
fbshipit-source-id: 972ef5a1b13bd9f6b7691a279a73168e7ce9d9ab
* Fabric: `LayoutableShadowNode:getLayoutMetrics` is not a virtual method anymore
Summary:
We don't use it as vitrual anymore (setLayoutMetrics is a non-virtual method already), so it does not need to be marker virtual.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21028572
fbshipit-source-id: 99f86fdd4cf2f5972034d9058d7b82bdc8680187
* Fabric: Proper traits for `ImageShadowNode` and `ViewShadowNode`
Summary:
* <Image> must be a leaf node; having a proper trait will fail earlier in case of misuse (mounting something inside).
* <View> must have a `View` trait because it's for what that trait is.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21028573
fbshipit-source-id: 457716d4661333eb2357f34316f3e495ab4fda24
* Fabric: "Attempt to mutate a sealed object." is now an assert (not exception)
Summary:
This is a debug-only feature that simply should be an assert. When it triggers in debugger and bubbles to some random exception catch block which makes it impossible to understand was exactly it happens. Making it an assert will stop debugger exactly where it happens.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21028571
fbshipit-source-id: 3df4ec0da922026bb9df61081cb71113577e06e9
* Fabric: Implementation of `getDebugDescription` for `std::array`
Summary:
Yoga uses `std::array` a lot (and `std::array` is not a `std::vector`), so it's useful for printing Yoga values.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21028570
fbshipit-source-id: c6bf114d5362f085ea201ecdc5b7d59646b33ebd
* Fabric: `componentregistry` module was decoupled from `uimanager`
Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20885163
fbshipit-source-id: 08eb1ba1d408fc0948e8d0da62380786a40973af
* Fabric: `scheduler` module was decoupled from `uimanager`
Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20885645
fbshipit-source-id: 8148bd934879802b076261ed86fa78acf0a07ed3
* Fabric: `templateprocessor` module was decoupled from `uimanager`
Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20885646
fbshipit-source-id: b8e3199c0eacc57a5be1481595cf97c84f972293
* Migrate deprecated frameInterval to preferredFramesPerSecond (#28675)
Summary:
[frameInterval](https://developer.apple.com/documentation/quartzcore/cadisplaylink/1621231-frameinterval) was deprecated in favor of [preferredFramesPerSecond](https://developer.apple.com/documentation/quartzcore/cadisplaylink/1648421-preferredframespersecond).
This migrates the deprecated call over.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Migrate frameInterval to preferredFramesPerSecond
Pull Request resolved: https://github.com/facebook/react-native/pull/28675
Test Plan: Xcode should no longer throw warnings about the deprecated call.
Differential Revision: D21109710
Pulled By: shergin
fbshipit-source-id: 772b9f625d3e22cd4d8cd60bddad57ff8611af54
* Fabric: Fix case of Glog include in MountingTest.cpp (#28616)
Summary:
This pull request changes the include of Glog from `<Glog/logging.h>` to `<glog/logging.h>` in `MountingTest.cpp`. This fixes building on a case-sensitive filesystem.
## Changelog
[Internal] [Fixed] - Fabric: Fix case of Glog include in MountingTest.cpp
Pull Request resolved: https://github.com/facebook/react-native/pull/28616
Test Plan: The `include` of Glog no longer causes issues with building `MountingTest.cpp` on a case-sensitive filesystem.
Differential Revision: D21118085
Pulled By: shergin
fbshipit-source-id: c958c54bf88333fd5001127779c855ce8c2666c3
* Fabric: Add Unicode prefix to AttachmentCharacter (#28617)
Summary:
This pull request adds a Unicode `u8` prefix to the string literal returned in `AttributedString.cpp`'s `Fragment::AttachmentCharacter()`.
This fixes the following error when building on MSVC:
```
react\attributedstring\AttributedString.cpp(21): error C4566: character represented by universal-character-name '\uFFFC' cannot be represented in the current code page (1252)
```
## Changelog
[Internal] [Fixed] - Fabric: Add Unicode prefix to AttachmentCharacter
Pull Request resolved: https://github.com/facebook/react-native/pull/28617
Test Plan: The Fabric test suite has been ran on a Clang-based build of Fabric on macOS, and no regressions in it have been noted.
Differential Revision: D21118078
Pulled By: shergin
fbshipit-source-id: c105de5e4edb67fed97ce44153a75d9d380bf588
* Fabric: Fixed incorrect early-return in `UIView+ComponentViewProtocol::updateLayoutMetrics`
Summary:
Before the change, an incorrect (NaN or Inf) values in LayoutMetrics might force an early return in the `updateLayoutMetrics:oldMetrics:` method implementation. This was not correct because the rest of the method also didn't run in this case, so it might force some value to stale.
E.g., imagine we have an instruction that contains NaN size and `display: none`. Previously, the function might just return right before applying sizes and progress the stored "already applied" value of LayoutMetrics which will cause the view being visible even if it should not.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21110644
fbshipit-source-id: 501319d7b1dcd5c18f27e0ceca3c8d207485c49b
* Fix border-stroke drawing after resetting border-radius (#28356)
Summary:
This PR fixes incorrect drawing of the View borders on Android, after changing the border-radius back to 0 *(and when no background-color is defined)*.
This happens because the `drawRoundedBackgroundWithBorders` function in ReactViewBackgroundDrawable changes the style on the Paint object to `STROKE`. This style is however never reverted back to `FILL`. This change ensures that the Paint style is set to `FILL` for the full execution of the `drawRectangularBackgroundWithBorders` function.
## Changelog
`[Android] [Fixed] - Fix border-drawing when changing border-radius back to 0`
Pull Request resolved: https://github.com/facebook/react-native/pull/28356
Test Plan:
**Faulty situation:**
**After the fix:**
Differential Revision: D21124741
Pulled By: shergin
fbshipit-source-id: 2044f8e8ad59a58df42b64d7ee8c4ad1d3b562f1
* Fabric: Using proper clock in MountingTelemetryTest
Summary:
Apparently, `std::this_thread::sleep_for` uses a different clock to measure time which causes ofter misalignment with the clock which Telemery uses which makes the test flaky. Using the same clock should fix it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21116058
fbshipit-source-id: 52dde2e325776d365431a2a957dcc12dfe53f890
* Fix rounded border drawing when border-radius is smaller than border-width (#28358)
Summary:
This PR fixes the drawing of the border rounded edges when the border-radius is small than the border-width. The current implementation capped the possible border-radius making it impossible to set smaller border-radii when using thicker borders. After inspection it was found that the rounded-rect calculation is incorrect.
## Changelog
`[Android] [Fixed] - Fix rounded border-drawing when border-radius is smaller than border-width`
Pull Request resolved: https://github.com/facebook/react-native/pull/28358
Test Plan:
**Faulty situation:**
As you can see, when the border-radius becomes very low, the border is stuck at a minimum value. Only after setting the border-radius fully to 0 is it again rendered correctly.
**After the fix:**
Differential Revision: D21124739
Pulled By: shergin
fbshipit-source-id: cefd1776b77b5b9fb335e95fd7fdd7f345579dc4
* Fabric: `ComponentDescriptor::cloneProps()` now never returns the base props objects
Summary:
The diff changes how the `empty raw props` optimization works in `ComponentDescriptor::cloneProps()`. Now it only fires only when the base `props` object is null, which is practically all production cases we have (and care about). (I tried, in a normal run there were no cases where the empty raw props were passed with non-null props.) From the other side, the old behavior that may return the same props objects previously several times created bugs and practically unexpected results and practically disallowed to clone props objects easily.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21110608
fbshipit-source-id: 884807cd8e9c5c3e6cc1c9e4c1f0227259cc21fb
* Upgrade to Jest 25
Summary:
This diff upgrades Jest to the latest version which fixes a bunch of issues with snapshots (therefore allowing me to enable the Pressable-test again). Note that this also affects Metro and various other tooling as they all depend on packages like `jest-worker`, `jest-haste-map` etc.
Breaking changes: https://github.com/facebook/jest/blob/master/CHANGELOG.md
This diff increases node_modules by 3 MiB, primarily because it causes more duplicates of `source-map` (0.8 MiB for each copy) and packages like `chalk` 3.x (vs 2.x). The base install was 15 MiB bigger and I reduced it to this size by playing around with various manual yarn.lock optimizations. However, D21085929 reduces node_modules by 11 MiB and the Babel upgrade reduced node_modules by 13 MiB. I will subsequently work on reducing the size through other packages as well and I'm working with the Jest folks to get rid of superfluous TypeScript stuff for Jest 26.
Other changes in this diff:
* Fixed Pressable-test
* Blackhole node-notifier: It's large and we don't need it, and also the license may be problematic, see: https://github.com/facebook/jest/pull/8918
* Updated jest-junit (not a Jest package) but blackholed it internally because it is only used for open source CI.
* Updated some API calls we use from Jest to account for breaking changes
* Made two absolutely egrigious changes to existing product code tests to make them still pass as our match of async/await, fake timers and then/promise using `setImmediate` is tripping up `regenerator` with `Generator is already run` errors in Jest 25. These tests should probably be rewritten.
* Locked everything to the same `resolve` version that we were already using, otherwise it was somehow pulling in 1.16 even though nothing internally uses it.
Changelog: [General] Update Jest
Reviewed By: rickhanlonii
Differential Revision: D21064825
fbshipit-source-id: d0011a51355089456718edd84ea0af21fd923a58
* Apply placeholderColor to TextInput component
Summary:
Changelog: [Internal]
TextInput's `placeholderTextColor` prop was being ignored. This diff fixes that.
Reviewed By: JoshuaGross
Differential Revision: D21064118
fbshipit-source-id: 33f148c355cee846db010153e0c65ea43155c3c9
* Fix mistake in swapping left/right layout properties
Summary:
Changelog: [Internal]
We were assigned `undefined` value to incorrect edge, instead of `YGEdgeLeft` it should have been `YGEdgeRight`.
If node has `YGEdgeRight` value, it needs to be reassigned to `YGEdgeEnd` and its original value set to undefined.
Reviewed By: mdvacca
Differential Revision: D21095234
fbshipit-source-id: fbecd9b7e6670742ad4a4bb097760aa10eec8685
* Fixed incorrect owner assignment in YGNode move constructor
Summary:
Assigning self as an owner makes a cycle which is obviously a bug.
Changelog: [Internal] Small change in Yoga (should not affect RN).
Reviewed By: SidharthGuglani
Differential Revision: D21111423
fbshipit-source-id: 1835561c055ac827f5ce98a044f25aed0d1845a5
* Easy diff to add a TODO
Summary:
Easy diff to add a TODO to refactor `sendAccessibilityEvent` to use ViewCommands
This was orginally added D17142507
changelog: [Internal] Internal change
Reviewed By: JoshuaGross
Differential Revision: D21137348
fbshipit-source-id: aff38ccad8dfbb222f83161e2bd5da82f543e5db
* Add support for generating custom messages
Summary:
Until now we've generated scaffolding entirely based on the official devtools
protocol spec. This diff adds support for defining custom domains in `custom.json`
which will be merged with the upstream protocol JSON definition.
ChangeLog: [Internal] Add support for Hermes-specific CDP messages
Reviewed By: bestander
Differential Revision: D20754605
fbshipit-source-id: a8075f81816a40114d1a3332192c7aa076b17848
* Implement Hermes.setPauseOnLoad
Summary:
This Hermes-specific mode is similar to Debugger.setPauseOnExceptions
and lets the VM know that it should enter a Pause state whenever a new
script is loaded/executed.
The debugger can then take its time to parse the source map and update
any breakpoints, before automatically continuing.
Changelog: [Internal] Implement a Hermes.setPauseOnLoad CDP call
Reviewed By: bestander
Differential Revision: D20754604
fbshipit-source-id: 7f9d0638706c99e9dcb534699b633f658e364909
* Switch isPackagerRunning to a class method.
Summary:
This diff exports `isPackagerRunning` as a class method to be used without and instance.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D21094414
fbshipit-source-id: 44becb59e3c08d66e4992c4c1b32d6efcd4fe257
* Fabric: Fixed `getDirtied` vs `isDirty` in `YogaLayoutableShadowNode`
Summary:
This is quite a fateful mistake. `getDirtied()` returns the pointer to a function which is obviously a mistake here; we should use `isDirty()` instead.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21028569
fbshipit-source-id: 95212b31f4e32d51c594d5209f295397af3f1252
* Fabric: More strict policies to dirty Yoga nodes in YogaLayoutableShadowNode
Summary:
Yoga uses a dirty flag to re-layout nodes. In normal, single-threaded approach the policy for dirtying is simple: if a node was changed, we need to dirty it. In the Concurrent Yoga approach, those rules are not so simple, and it seems we haven't formalized those rules yet.
Investigating some layout issues that we have in Fabric, I tend to believe that we don't dirty as much we should. Hense this change adds mode dirtying.
Reviewed By: JoshuaGross
Differential Revision: D21092815
fbshipit-source-id: 4603c97ccb79efcdf5e6a4cc450ebe61b63effb3
* Allow iOS PlatformColor strings to be ObjC or Swift UIColor selectors (#28703)
Summary:
Per discussion in https://github.com/react-native-community/releases/issues/186 the iOS `PlatformColor()` function is documented to use the semantic color names provided by the system. The referenced HIG documentation itself links to the `UIColor` documentation for semantic colors names. However, these names differ depending on if you are viewing the new Swift API docs or the Objective C docs. The current Objective C implementation in react-native assumes Objective C UIColor selector names that are suffixed 'Color'. But in Swift, Apple provides a Swift Extension on UIColor that makes aliases without the the 'Color' suffix and then makes the original selectors invalid presumably via `NS_UNAVAILABLE_SWIFT`.
Since both selector names are valid depending on if you are using Objective C or Swift, let's make both forms be legal for `PlatformColor()`. In `RCTConvert.m` there is a dictionary of legal selector names. The code already supports the ability to have names be aliases of other selectors via a RCTSelector metadata key. The change adds code to the initialization of the map: it iterates over the keys in the map, which are all ObjC style UIColor selectors, and creates aliases by duplicating the entries, creating key names by stripping off the ObjC "Color" suffix, adds the RCTSelector key referring to the original and then appends these new Swift aliases to the map.
## Changelog
[iOS] [Changed] - Allow iOS PlatformColor strings to be ObjC or Swift UIColor selectors
Pull Request resolved: https://github.com/facebook/react-native/pull/28703
Test Plan:
The PlatformColorExample.js is updated to use the new, shorter Swift selector names. There are still other examples in the same file and in unit tests that exercise the ObjC selector names.
<img width="492" alt="PlatformColor" src="https://user-images.githubusercontent.com/30053638/79809089-89ab7d00-8324-11ea-8a9d-120b92edeedf.png">
Reviewed By: shergin
Differential Revision: D21147404
Pulled By: TheSavior
fbshipit-source-id: 0273ec855e426b3a7ba97a87645859e05bcd4126
* Update Differ test
Summary:
Update differ test so it passes again. Previously to D21111423 (I think) nodes were being incorrectly detected as updated even if they weren't different, so now there are fewer unnecessary Update mutations generated.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21148647
fbshipit-source-id: cab6e3ecd0a457e1ac3155b3468bcc56663dab0b
* Enable Yoga logging in Fabric Debug
Summary:
This diff extends Fabric to support Yoga logging
changeLog: [Internal] Internal changes in Fabric to enable yoga logging
Reviewed By: JoshuaGross
Differential Revision: D21150195
fbshipit-source-id: a2e8308a79a7b422bf9ecc3a65f822b305f02c5d
* Easy diff to document in code how to enable logging of Shadow Tree instrospection
Summary:
Easy diff to document in code how to enable logging of Shadow Tree instrospection
changeLog: [Internal] Internal change used on Fabric
Reviewed By: JoshuaGross
Differential Revision: D21150196
fbshipit-source-id: 8eb23ec3ea1d574b79b09333428ab52c851065dd
* Flip text alignment in case layout direction is RTL
Summary:
Changelog: [Internal]
Flip text alignment in case layout direction is RTL.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D21130371
fbshipit-source-id: cf56ca052c17a48e321803b0f99f8a4baaa0e67b
* Daily `arc lint --take GOOGLEJAVAFORMAT`
Reviewed By: zertosh
Differential Revision: D21154707
fbshipit-source-id: 11956915c265f98e286638b91d66d51545e3a311
* Upgrade Flipper to 0.37.0 (#28545)
Summary:
Bump flipper to 0.37 for both iOS and Android
## Changelog
[Android] [Changed] - Upgrade Flipper to 0.37.0
[iOS] [Changed] - Upgrade Flipper to 0.37.0
Pull Request resolved: https://github.com/facebook/react-native/pull/28545
Test Plan: RNTester build pass
Reviewed By: rickhanlonii
Differential Revision: D20930069
Pulled By: hramos
fbshipit-source-id: a7cb719da3e51e6a42d27d5e64bc664398d0d3c5
* Upgrade babel-eslint in xplat/js
Summary:
`babel-eslint` is the parser you can supply to ESLint based off of Babel.
`babel-eslint` 10.1.0 is the newest production version of `babel-eslint`.
There are very few changes between 10.0.1 (the lowest previous version) and 10.1.0. There are only 3 non-version-bump commits: 2 bug fixes and enabling parsing of Flow enums.
The only project that was on a lower version than 10.0.1 was `/xplat/js/RKJSModules/Libraries/Relay/oss/__github__` - test below
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D21055850
fbshipit-source-id: bae0d8af5c6d833a4dbb0ad775c8e5e78ead1051
* RN: Create `RootTag` Type
Summary:
Creates a `RootTag` type and refactors the `RootTagContext` module a bit.
This creates space for eventually changing `RootTag` into an opaque type that is only created once by `AppContainer`, and only consumed by native abstractions.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D21127173
fbshipit-source-id: 60177a6e5e02d6308e87f76d12a271114f8f8fe0
* RN: Add `RootTag` Type to TurboModule
Summary:
Adds `RootTag` as a valid type for arguments and return types in TurboModules (on both Android and iOS).
This will enable us to change `RootTag` into an opaque type. There are two compelling reasons to do this:
- JavaScript will no longer be able to safely depend on `RootTag` being a number (which means we can change this in the future).
- Call sites using `unstable_RootTagContext` will can get a `RootTag`, but call sites using the legacy `context.rootTag` will not. This means the opaque type will give us a strategy for migrating away from legacy context and eventually making `unstable_RootTagContext` the only way to access `RootTag`.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: RSNara
Differential Revision: D21127170
fbshipit-source-id: baec9d7ad17b2f8c4527f1a84f604fc0d28b97eb
* RN: Fix Codegen Schema Buck Dependency (#28719)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28719
The Buck dependencies for the schema rule is missing the source files for the new codegen (and specifically, the parser).
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D21162993
fbshipit-source-id: 4addb6f257134e245a5d86dd427ee2536ed6d658
* Flow 0.123.0 in xplat/js
Summary:
Changelog: [Internal]
## Sync of generated files
Ran
```
js1 upgrade www-shared -p core_windowless
```
but had to manually revert
```
RKJSModules/Libraries/www-shared/core_windowless/logging/FBLoggerType.flow.js
RKJSModules/Libraries/www-shared/core_windowless/logging/FBLogger.js
```
because they introduced more errors
## Flow version bump
```
~/fbsource/fbcode/flow/facebook/deploy_xplat.sh 0.123.0
```
Reviewed By: gkz
Differential Revision: D21159821
fbshipit-source-id: e106fcb43e4fc525b9185f8fc8a246e6c3a6b14f
* Remove outdated metro type definitions
Summary:
RN itself does not depend on Metro any longer, which is abstracted away into the CLI. I don't think we need those type definitions any longer as we have proper Metro definitions internally. I'm removing them because they keep showing up in biggrep when I look for things.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D21089924
fbshipit-source-id: 2845277af12dae0f0baefaf85adefffb6ef9f2a5
* Daily `arc lint --take CLANGFORMAT`
Reviewed By: zertosh
Differential Revision: D21175893
fbshipit-source-id: 101734c1b968ce241a15648efdcaeabbd789952d
* remove tvOS from template (#28706)
Summary:
According to the [0.62 blog post](https://reactnative.dev/blog/2020/03/26/version-0.62), Apple TV support has moved to react-native-tvos.
The template still contains info.plist for tvOS, so I've removed them for future releases.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Removed] - Removed tvOS related files from the template
Pull Request resolved: https://github.com/facebook/react-native/pull/28706
Test Plan: run `react-native init TestTemplate` and remove tvOS related files and verified that iOS and Android runs on emulator.
Differential Revision: D21182211
Pulled By: hramos
fbshipit-source-id: 41d2e19e5158d7ec103a37c01a93cf511fc1e4c9
* Fabric: `ConcreteShadowNode::initialStateData()` now accepts a `ShadowNodeFamilyFragment` instead of just a `SurfaceId`
Summary:
We need it to be able pass an `EventEmitter` object to constructed concrete State objects.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21169581
fbshipit-source-id: 3eef0310de7e2f061108aa85c1a39678a43fe85e
* Fabric: Introducting `ShadowNodeFamilyFragment::Value`
Summary:
`ShadowNodeFamilyFragment::Value` is a value couter-part type for `ShadowNodeFamilyFragment`.
We need that to be able safely copy data stored inside a `ShadowNodeFamilyFragment` object.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: kacieb
Differential Revision: D21169580
fbshipit-source-id: 1a485e1b2ae47bc7da9476a60466934ac9d61366
* Overhaul RCTTurboModule creation and initialization
Summary:
## Problems:
In my investigation of T65656635, I realized that the TurboModule system has a number of problems:
- In TurboModules, we use 1 lock to create n TurboModules. We should change this setup to n locks for n TurboModules. This way, two threads creating two different NativeModules don't compete for the same lock. Also, this is how it's done in Android (TurboModules & NativeModules), and iOS (NativeModules).
- In TurboModules, we don't calculate "requires main queue setup" faithfully. In the legacy system, if a NativeModule has a custom `init` method or a custom `constantsToExport` method, it "requires main queue setup" with a warning.
- In TurboModules, we don't create the NativeModule on the main queue, if "requires main queue setup" is true. Instead, the NativeModule is always created on the thread that requires it.
- In TurboModules, we don't perform any concurrency control around `id<RCTTurboModule>` setup. We should.
## What this diff does
In this diff, I fixed all the aforementioned issues by re-implementing `provideRCTTurboModule:`.
**Algorithm Notes:**
- **Gist:** When `n` threads race to create NativeModule `x`, only the first thread creates and sets up `x`. All others are told to wait. Once the creator thread finishes its job, it notifies all other waiting threads, which then wake up and return the newly created NativeModule. This algorithm was initially implemented in NativeModules for Android inside (ModuleHolder.java). I modified and implemented it for TurboModules for Android, and now this diff implements it for TurboModules for iOS.
- The TurboModule cache is replace with a TurboModuleHolder map. A TurboModuleHolder manages the creation lifecycle of a TurboModule, and holds a condition variable and mutex for doing concurrency control around it. When the bridge invalidates, in TurboModuleManager, we set the `invalidating` flag to true, which prevents the insertion of new entries into the TurboModuleHolder map.
- I added a `std::mutex` to serialize calls into the TurboModuleManagerDelegate, so we don't get races if the delegate isn't thread-safe.
Changelog:
[iOS][Fixed] - Re-implement RCTTurboModuleManager provideRCTTurboModule:
Reviewed By: shergin
Differential Revision: D21170099
fbshipit-source-id: 8792812c2237d3bfc80c9834c818e011de85b0ea
* Fix folly::dynamic crash when attaching a debugger to Hermes
Summary:
folly_futures was compiled with and exported -DFOLLY_MOBILE=1, while
folly_json did not. This flag disables fancy F14 data structures for
folly::dynamic in favor of a simple std::unordered_map.
This caused inlined/templated code from modules depending on
folly_futures to disagree with the implementations in folly_json,
leading to a crash.
The only such libraries were libhermes-inspector and (transitively)
libhermes-executor-debug, and these only use folly::dynamic for CDP
serialization, which is why the problem was not more apparent.
Changelog: [Internal] Fix crash when attaching a Hermes debugger
Reviewed By: mhorowitz
Differential Revision: D21193307
fbshipit-source-id: 2b795bb6f4f7f991e2adaacec62d62616117322b
* Set black as default text color for <TextInput/> on iOS (#28708)
Summary:
This is a follow-up pull request to https://github.com/facebook/react-native/issues/28280 (reviewed by shergin).
This pull request tried to solve the problem of the default color in a TextInput in dark mode on iOS being white instead of black. I got suggested …
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please select one of the following
Summary
Merge facebook/react-native's main branch into react-native-macos's main branch through 2020-05-09 23:59:59 PDT (specifically, a1ac251).
These changes were made by repeatedly running
git merge <commit-id>and resolving merge conflicts as needed.One of the more unusual modifications we had to do to ensure compatibility is the addition of the
#if 0block in React/CoreModules/RCTDevLoadingView.mm. Thankfully, we're blocking out unused code, so it shouldn't be a big deal. This will get cleaned up once we fix this upstream and get microsoft/react-native-macos caught up to that future commit.Validation