Summary: This adds internal script to automatically sync the plugins definition. For github consumption, the CoreModulesPlugins.* will stay checked in, nothing change.
Reviewed By: RSNara
Differential Revision: D16102352
fbshipit-source-id: 8f74ea9dde046183ae620682fd7e181b4cc95a94
Summary: To look up TurboModule Class based on its name, this new function `RCTCoreModulesClassProvider()` can be used to find a TurboModule impl in the app. For now this is manually maintained and sync'ed with FB internal version. Only modules that live under React/CoreModules/ should be handled here.
Reviewed By: PeteTheHeat
Differential Revision: D16100291
fbshipit-source-id: 6b7556dec1fa83d1e081c7e8c0fe295187934274
Summary:
We should be able to just use `header_path_prefix` and normal `glob(["**/*.h"])` patterns, and that should be compatible with the build system.
This also allows `RCTPlatform.mm` to import `"RCTPlatform.h"` directly without any namespace.
Reviewed By: RSNara
Differential Revision: D16096779
fbshipit-source-id: b17b79baf958f1e9a63085a928b64663cb29bbbb
Summary:
This PR adds initial support for Project Catalyst a.k.a. UIKitForMac. This is not yet meant for production, but this is enough for RNTester to successfully compile and mostly work :)
Some APIs are not supported on the Mac -- e.g. telephony, and deprecated APIs are removed on Mac ���-- those had to be ifdef'd out via platform checks.
The biggest limitation right now is that I couldn't get Web Socket code to successfully compile, and so there are a lot of temporary platform checks for that , and the RCTWebSocket.xcodeproj is marked as not supporting UIKitForMac. Again -- temporary, until someone with more knowledge knows how to fix this.
https://github.com/react-native-community/discussions-and-proposals/issues/131
## Changelog
[iOS] [Added] - Fixed compilation for macOS (Project Catalyst) -- not meant for production use yet
Pull Request resolved: https://github.com/facebook/react-native/pull/25427
Test Plan:
- Open RNTester/RNTester.xcodeproj with Xcode 10.2, run it like a normal iOS app -- make sure it compiles and runs correctly (no regression)
- Open the same project with Xcode 11 beta 2 (or higher) on macOS Catalina beta, select "My Mac" as device target, and run -- see that it actually compiles and runs. **Note** there are unfortunately some required steps:
- change build configuration to Release (because packager doesn't work correctly yet)
- change development team to yours if Xcode tells you to
- go to RNTester project → Build phases → Link binary with libraries, and change `platforms` for `libRCTWebSocket.a` to `iOS` (without Mac compatibility). I can't commit that change because it breaks compatibility with earlier Xcode versions
The two extra steps for successful compile will disappear once web socket compilation for Catalyst is fixed
Reviewed By: mmmulani
Differential Revision: D16088263
Pulled By: sammy-SC
fbshipit-source-id: 9c0b932b048e50a8e0f336eaa0612851b1909cae
Summary: This is an attempt to use internal iOS plugin system for NativeModules in github.
Reviewed By: RSNara
Differential Revision: D16082484
fbshipit-source-id: 81d9f20b20419e9613a2babdd56d0e037705bf4e
Summary: First attempt to make RCTPlatform module implement the generated specs for TurboModule.
Reviewed By: PeteTheHeat
Differential Revision: D16001262
fbshipit-source-id: 24067c2840b9aa2be224c0c7c82fe7edc98d40d9
Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs.
Reviewed By: PeteTheHeat
Differential Revision: D16043221
fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
Summary: Right now the entire RN core code lives inside one giant internal Buck target. This makes it hard to refactor the infra and to roll out TurboModules. For now, create a baseline for how RN core dir can be structured.
Reviewed By: PeteTheHeat
Differential Revision: D16001260
fbshipit-source-id: bba947e2fb75576a2e1f3f4c816575f1157dcb03
Summary: It just makes the code much more readable.
Reviewed By: sammy-SC
Differential Revision: D16038432
fbshipit-source-id: db68dd38356660078bc94ec802fbdbb6c27ceead
Summary:
By default absolutely everything gets logged twice (https://github.com/facebook/react-native/issues/25380).
This was introduced over 4 years ago here:
[React Native Log to ASL · facebook/react-native@d1b14ef · GitHub](d1b14ef062)
with the reason to support ASL.
With this PR the support for that will be removed but I believe this is justified because:
- the benefit of not having every log message twice far outweighs the benefit of having Apple System Log.
- ASL was superseded by "unified logging" (yellow box on https://developer.apple.com/documentation/os/logging).
- I assume that people who use asl_log is very small. There is also very little information about it on the internet
## Changelog
[iOS] [Fixed] - Logs would get printed twice
Pull Request resolved: https://github.com/facebook/react-native/pull/25382
Differential Revision: D16048052
Pulled By: cpojer
fbshipit-source-id: 51519570bbee79571e4ff63f433b9b70bcd55671
Summary:
Apparently, settings `frame` and `transform` at the same view is UB and that's documented.
https://developer.apple.com/documentation/uikit/uiview/1622621-frame?language=objc
> Warning
> If the transform property is not the identity transform, the value of this property is undefined and therefore should be ignored.
Reviewed By: JoshuaGross
Differential Revision: D16038431
fbshipit-source-id: 9f282dfad97af293e5e70d3cdd849ae3e9c775c9
Summary: See the comment in the code.
Reviewed By: JoshuaGross
Differential Revision: D16031147
fbshipit-source-id: e165f423f5ee35d1ae5e667dba9ef8da7b9a388c
Summary:
TurboModules seem to be pretty much done, but there's no easy way to reference them on iOS side if you're linking the React project (the classic, non-CocoaPods way). So I added it.
Also updated RNTester (non-CP based) to compile TM samples
## Changelog
[iOS] [Added] - RCTTurboModule now available from RCTTurboModules.xcodeproj
Pull Request resolved: https://github.com/facebook/react-native/pull/25031
Test Plan:
~~1. Add `#import <jsireact/TurboCxxModule.h>` to a `.h` file on iOS project -- see if it compiles correctly~~
1. Open RNTester/RNTester.xcodeproj, compile, and see if TurboModule sample works
Reviewed By: hramos
Differential Revision: D16019600
Pulled By: fkgozali
fbshipit-source-id: 53c691f035a4e02abd7569840137705f3862be81
Summary:
Right now JS triggers a view manager command with the following code:
```
UIManager.dispatchViewManagerCommand(
nullthrows(this.scrollResponderGetScrollableNode()),
UIManager.getViewManagerConfig('RCTScrollView').Commands.scrollTo,
[x || 0, y || 0, animated !== false],
);
```
As we want to get rid of calls to UIManager, we need to stop looking for the integer defined in native from JavaScript. We will be changing methods like this to be:
```
UIManager.dispatchViewManagerCommand(
nullthrows(this.scrollResponderGetScrollableNode()),
'scrollTo',
[x || 0, y || 0, animated !== false],
);
```
We need to support ints and Strings to be backwards compatible, but ints will be deprecated.
This is the same change as made for Android here: 3cae6fa950
Reviewed By: PeteTheHeat
Differential Revision: D15983041
fbshipit-source-id: 6cb0f3001553d1f9d26e7e8fb5481e16fbca6847
Summary:
When starting a React Native app, one gets to see the message in the image.
I propose to remove it, because it provides little information to the developer and is noisy.
```
Initializing <RCTCxxBridge: 0x7fded270fbf0> (parent: <RCTBridge: 0x600001b95570>, executor: (null))
```
## Changelog
[iOS] [Fixed] - Debug message was logging to the console
Pull Request resolved: https://github.com/facebook/react-native/pull/25381
Test Plan: -
Differential Revision: D15983841
Pulled By: cpojer
fbshipit-source-id: 27f7d25ee0c580640d03f0db9adcd3c2a205b270
Summary: This fixes a crash happened in Image component caused by a race between recycling a component and image loading event are being delivered asynchronously.
Reviewed By: mdvacca
Differential Revision: D15977418
fbshipit-source-id: ac6f4b3d2b995af2afd56e551380a32d0f14ab15
Summary: The app crashed on assert which was not actually legit. See the comment in the code.
Reviewed By: JoshuaGross
Differential Revision: D15976177
fbshipit-source-id: 612bbbd510187ffdc86369aa943d4b652b748694
Summary:
We have too many options in the Dev Menu, and they're really hard to pick from. They're also somewhat conflicting. This replaces two menu choices that have a similar purpose (faster iteration cycle) with one.
"Fast Refresh" tries to only update the affected modules, but falls back to doing a full reload if the update can't be handled by the React components.
If for some reason you prefer the "Reload-on-Save" behavior, please:
- Reach out to me so I can learn more about your use case.
- As a workaround, you can add `if (__DEV__) require.Refresh.forceFullRefresh = true` to your app's entry point to always do a full refresh.
Also note that I only removed the user-facing part of "Reload-on-Save". So if you have automation depending on it, that's gonna keep working.
I moved it above Systrace since it's a more generic feature.
As a total aside nit, I renamed "Enable Inspector" and "Disable Inspector" to "Show Inspector" and "Hide Inspector" because... that's what those options do, really.
Reviewed By: rickhanlonii
Differential Revision: D15958697
fbshipit-source-id: 20e856d56f661fe4d39b5ab47d8c44754bf70f67
Summary:
As we saw in D15947985, and later traced down to D5623623, the `hot` option isn't used by Metro anymore. The relevant transforms _always_ run in DEV regardless of the option.
Given that, it doesn't make sense that enabling or disabling Hot Reloading forces a full refresh. This significantly raises the usage barrier because **currently, you might have to wait ~20 seconds (on a large app) to just start using Hot Reloading when you're already in the middle of some screen.** So you just end up not using it.
This diff changes enabling/disabling Hot Reloading to be _instant_.
Here's how it works:
1. Now we always send the necessary info to the client via the new `HMRClient.setup()` function. It creates a Metro HMR client instance, but only actually sets up the socket if Hot Reloading is on.
2. The "Enable Hot Reloading" menu no longer forces a reload. Instead, it calls `HMRClient.enable()` which lazily sets up a socket (at most once).
3. The "Disable Hot Reloading" menu also doesn't trigger a refresh now. Instead, it calls `HMRClient.disable()`. We don't actually tear down the socket here because it's a pain to deal with race conditions and such. Instead, we keep the connection — but we _ignore the updates_ that come in while we're disabled.
4. As a result, it is possible to enable and disable it many times during a single session. (Updates while disabled would be ignored — which has a risk of making your running app inconsistent — but I'd argue it's expected and is worth it. You can always save a particular file to force it to update once the mode is on.)
5. In order to support "ignoring" updates, Metro's `HMRClient` (not to be confused with RN's module) now supports a `shouldApplyUpdates` field. The RN module uses it to disable handling updates when the mode is off.
6. In case there is an error that makes hot reloading unavailable (such as the server disconnecting), we surface the error only if the mode is on. If the mode is off, we stash the error message in the `_hmrUnavailableReason` variable, and display it next time you try to enable Hot Reloading.
Reviewed By: rickhanlonii
Differential Revision: D15958160
fbshipit-source-id: 8256fc4d5c2c3f653a78edf13b8515a5671953e4
Summary:
Original commit changeset: 4849a8e94141
# Problem:
This diff caused https://github.com/facebook/react-native/issues/25339.
It was converting non string values to strings whenever the conversion was available.
The original problem that this diff was trying to solve is described here -> https://twitter.com/estevao_lucas/status/1117572702083190785?s=215
# Solution introduced by this diff
This diff introduced a conversion. So for any value that was meant to be string but wasn't we would attempt to convert it. Which is not always wanted.
# Solution for problem in the twitter
I think we should improve the error message if incorrect type is being passed as a prop. However this isn't a problem if views are Flow typed.
Reviewed By: cpojer
Differential Revision: D15964298
fbshipit-source-id: 3d027a378561b87e7a9e89fc5e39dc6f359d8d22
Summary: This is strange why it's happening but it's not a reason to crash here. We will migrate the text component to State anyway, so we will fix the problem then.
Reviewed By: JoshuaGross
Differential Revision: D15951391
fbshipit-source-id: c1d1217fab1180f1eef84dfc2b2fd1ed0864b035
Summary: There are still race condition during bridge invalidation. Some modules may be accessing other modules during invalidation, but it's racing with the TM manager clearing the cache.
Reviewed By: JoshuaGross
Differential Revision: D15947488
fbshipit-source-id: 3bd51382264f538a03ca565b0f099da40c3daadf
Summary: We didn't update the header name. The ref was weak so it just didn't pull in the module.
Reviewed By: fkgozali
Differential Revision: D15944635
fbshipit-source-id: 8599c091a2265f807662c3deea4bd3c59e1a8aa8
Summary: We should not use `self.contentView` accessor to insert container views (views that might be used as a container for nested views) into component view otherwise it causes double applying of padding values.
Reviewed By: mdvacca
Differential Revision: D15862075
fbshipit-source-id: aad834aeca06f66b19c2f7bbaa0b58f937e66994
Summary: Setting value directly to ivar makes impossible to subclasses to react of this; this is a bug.
Reviewed By: mdvacca
Differential Revision: D15776691
fbshipit-source-id: 10f9be975ee673b2db46c24ba41b18f6d6ddf0a3
Summary:
In some cases, the view class is the only that retains stored `props_` variable. At the same time the `[super updateProps:props oldProps:oldProps];` actually resets the pointer with a pointer to new props value which sometimes causes the deallocation of the old value. All that is okay unless the implementation of `updateProps:oldProps:` in superclasses stores a raw reference to an old value in the very beginning of the method (for convenience and perf reasons).
So, to prevent preliminary deallocation of the old value pointed by `_props` we moved all `[super updateProps:props oldProps:oldProps];` calls to the end of overloaded methods.
Reviewed By: mdvacca
Differential Revision: D15770068
fbshipit-source-id: af36b3e70560ab00846cd26b0963bbc059e977bc
Summary: It's a antient left over which was copy pasted a dozen of times. All `RCTViewComponentView` subclasses have own copy of the old props `_props`, so it's useless to check for `oldProps`.
Reviewed By: mdvacca
Differential Revision: D15770067
fbshipit-source-id: 39f4d71ccdcf0c9a5b911b17a3b922dbe6dd9a8e
Summary: This makes it so that you don't have to specify the package to the bundle. When you don't specify it, it will use the default bundle that is chosen when the app starts.
Reviewed By: PeteTheHeat
Differential Revision: D15742001
fbshipit-source-id: cd5906a66d04eea308dbc0516bc1fec60caed6bb
Summary:
The necessity of this feature was removed in 2017. To intercept React Native gesture recognizer, implement UIGestureRecognizer delegate for conflicting gestures.
Here is the quote from the internal note:
> Previously we had lots of super weird bugs where React Native would inaccurately recognize touch gestures which were meant to be addressed by the native environment. Usually, these bugs occurred as unintentional taps happening right after swipe gestures. In all of these cases, we had to manually call method `cancelTouches` as part of an external gesture recognition process which prevented touch delivery to React Native. Furthermore, we had to delay touch delivery to React Native to wait for these cancellations. That code always looked like a hack (in the bad meaning of this word), like in some random place something dispatch event to another random place where something finally calls `cancelTouches`, yak. It was super annoying because it required adding this hack to all existing apps and screens, and because sometimes it was even too late to cancel touches.
> We fixed that. Instead of delaying touch delivery and waiting for calls to `cancelTouches`, we set up the React Native gesture recognizer in such way that it always agrees to fail in favor of any native gestures (from non-RN-based and served views which are placed higher in a hierarchy). React Native will now cancel all active touches itself so that we no longer need to call `cancelTouches` manually. We already removed all these calls and supported code from Facebook and Instagram.
See also: https://github.com/facebook/react-native/pull/25193
Reviewed By: PeteTheHeat
Differential Revision: D15734129
fbshipit-source-id: 289f77a437cb40199c591153b5801d24d0c10d1e
Summary: We have to use a getter instead of an ivar to enable lazy initialization of ContextContainer.
Reviewed By: mdvacca
Differential Revision: D15731877
fbshipit-source-id: eb4d0e70c337026a91cb12a3eb26ed4d94f39f9f
Summary:
... and slighly new behaviour for one of them.
The method does nothing if given `key` already exists in the container.
This diff finishes the transition of ContextContainer from an internal bag of things with unclear yet ownership into a legit dedicated dependency injection container for the product code.
The original names of methods imply that the container can have only one object of a given type which is no longer true. The new API is much more generic and idiomatic to C++, it mimics `std:map` API which is intuitive to anyone who familiar with C++ containers.
Besides the naming, `insert` method changed the semantic a bit; now it does nothing in case of inserting an object with a key that already exists. That might seem counterintuitive for "normal" people, but C++ has some wired reasons for that and, hopefully, it's expected behavior in the C++ community.
Fun fact: We need this to fix hot-reload.
Reviewed By: sahrens
Differential Revision: D15681736
fbshipit-source-id: 194f342528446a911eaf072ba3a94a5d8af3cb52
Summary: Restores the bridge description in the debug menu on iOS.
Reviewed By: fkgozali
Differential Revision: D15680775
fbshipit-source-id: c17ad44f2287e03bb2039b4aa4b1311e7ec9106b
Summary:
Fixes#18177 . Related #24497. Autoresizing mask would conflict with `AutoLayout`. For example , it would impact `SafeAreaView`. And actually we don't need to use autoresizing mask, we observe the bounds change notification and [update the frame manually](1151c096da/React/Views/RCTModalHostView.m (L59)).
## Changelog
[iOS] [Fixed] - Removed autoresizing mask for modal host container view
Pull Request resolved: https://github.com/facebook/react-native/pull/25150
Differential Revision: D15645148
Pulled By: cpojer
fbshipit-source-id: 95d5f40feaa980b959a3de6e273dccac8158c57b
Summary:
In environments with McAfee EPro software, port 8081 is used and cannot be unbound. (See [#20466](https://github.com/facebook/react-native/issues/20466) for a recent example issue.) Most issues can be worked around by passing a `--port` option or setting `RCT_METRO_PORT`, but there are a couple places where 8081 is hardcoded that block adoption. Right now the workaround I've seen pushed on Stack Overflow and elsewhere is to modify node_modules after a `yarn install`, so I'd like to fix it at the source.
This PR changes the react "Start Packager" build step and some code in the iOS DevSupport library to read from the `RCT_METRO_PORT` variable.
## Changelog
[General] [Changed] - Removed hardcoded references to port 8081 and replaced them by reading from RCT_METRO_PORT (w/ fallback to 8081)
Pull Request resolved: https://github.com/facebook/react-native/pull/25144
Differential Revision: D15630119
Pulled By: cpojer
fbshipit-source-id: aff5d24691e0e9892a035cfbd25330fed6441199
Summary:
Fixes build in Xcode 11 beta, the signature for `__unused` was changed. This adds a new check for the new style.
## Changelog
[iOS] [Fixed] - Xcode 11 beta build
Pull Request resolved: https://github.com/facebook/react-native/pull/25146
Differential Revision: D15628404
Pulled By: cpojer
fbshipit-source-id: 781a188a0e1562a3316fbe62920b12b03a44e4a7
Summary:
The accessibilityActions accessors in UIView+React.m are not aligned with the property declaration in the header file.
## Changelog
[General] [Fixed] - Fix accessibilityActions accessors
Pull Request resolved: https://github.com/facebook/react-native/pull/25134
Differential Revision: D15621848
Pulled By: cpojer
fbshipit-source-id: f344689292ae7988e46d0d4263980306d364366b
Summary:
I noticed that the RNTester-tvOS target is not compilable when I wanted to test the TVOS capacity of React Native.
More specifically, the changes included in this PR are:
### RNTester-tvOS target
1. Add `AppDelegate.mm` to the target.
2. Add `.m` files under `turbomodule` to the target.
3. Add the following directories to **header search path**.
```
$(SRCROOT)/../third-party/boost_1_63_0
$(SRCROOT)/../third-party/folly-2018.10.22.00
$(SRCROOT)/../third-party/glog-0.3.5/src
```
4. Add `RN_BUNDLE_PREFIX` to the scheme argument.
5. Add `RN_BUNDLE_PREFIX` entry to the plist file.
### React-tvOS target
1. Add `RCTCxxBridgeDelegate.h` and `JSCExecutorFactory.h` to the **Copy headers**.
## Changelog
[iOS] [Fixed] - Fixed the issue that the RNTester-tvOS is not compilable.
Pull Request resolved: https://github.com/facebook/react-native/pull/25110
Differential Revision: D15602450
Pulled By: cpojer
fbshipit-source-id: e7eda18c8193b7d88355feafa69043ffef4a8edb
Summary:
We need to use second for calculation, so change 17ms to 0.017s instead.
## Changelog
[iOS] [Fixed] - Fixes wrong time unit of scroll event throttle
Pull Request resolved: https://github.com/facebook/react-native/pull/25098
Reviewed By: sahrens, cpojer
Differential Revision: D15576526
Pulled By: sammy-SC
fbshipit-source-id: ddd8dd9098cbe582c6923ce8466892c363c090fc
Summary:
This PR fixes incorrect unhooking for UI manager views in `RCTProfileUnhookModules`. `view` is actually a key, not the view itself; instead, use `viewForReactTag:` to obtain the view itself.
This fixes issue #24952.
## Changelog
[iOS] [Fixed] - Fix incorrect unhooking for UI manager views in `RCTProfileUnhookModules`, causing an infinite `RCTProfileTrampoline ` recursion (#24952)
Pull Request resolved: https://github.com/facebook/react-native/pull/25042
Differential Revision: D15580978
Pulled By: PeteTheHeat
fbshipit-source-id: 3483a7f6380b6fb1db4249374d86f692348c9aa2
Summary:
Addresses a number of pieces of feedback regarding the debug menu.
- Simplify labels for the debugger actions (e.g. no "remote", no emoji).
- Reorder actions so that modal items are generally lower.
- Changed "Toggle Inspector" to "Show/Hide Inspector".
- Renamed "Live Reloading" to "Reload-on-Save".
- Hide disabled debug items when profiling is enabled.
- Changed "Start Systrace" to "Systrace Unavailable" when debugging.
- Renamed "Change packager location" to "Configure Bundler".
- Revised nomenclature in "Configure Bundler" menu to be clearer.
- Removed extraneous debug menu title.
- Consistently refer to HMR as "Hot Reloading".
Changelog:
[iOS] [Changed] - Cleaned up debug menu.
Reviewed By: axe-fb
Differential Revision: D15548628
fbshipit-source-id: 26b2ddca8280d1f6f8ff904439b403600e98a3b3
Summary:
Related #23674, in that PR, we imported background timer support, but it's not sufficient, I think the reason that works is because it enable the `Background Modes` and do some background tasks, for the users who don't enable it, timer would pause immediately before goes into background.
To fix it, we can mark a background task when goes into background, it can keep app active for minutes, try best to support timing when in background.
cc. cpojer .
## Changelog
[iOS] [Fixed] - Timing: Fixes timer when app get into background
Pull Request resolved: https://github.com/facebook/react-native/pull/24649
Differential Revision: D15554451
Pulled By: cpojer
fbshipit-source-id: a33f7afe6b63d1a4fefcb7098459aee0c09145da
Kevin Gozali
Radosław Pietruszewski
Ben Blackburne
Valentin Shergin
Jonny Burger
radex
David Vacca
Eli White
Dan Abramov
Samuel Susla
Mehdi Mulani
Tim Yung
zhongwuzw
Jim Berlage
Eric Lewis
Sharon Gong
Alex Cohen
spdr admin
Leo Natan
