Summary: The previous rename from RCT->RN prefix ended up causing some confusions on which prefix to use for which files and under what circumstances. To avoid further confusion before we're done with the re-architecture project, let's keep them as RCT.
Reviewed By: mdvacca
Differential Revision: D16705566
fbshipit-source-id: 395bff771c84e5ded6b2261a84c7549df1e6c5e5
Summary:
Updated the message from
> Loading from pre-bundled file
to
> Connect to Metro to develop JavaScript
I also added a new RCT_PACKAGER_NAME so other packagers can override "Metro"
Reviewed By: yungsters, cpojer
Differential Revision: D16427501
fbshipit-source-id: 1b7f9e261f7521ba930c6248087fe6f3c3659cb7
Summary: For some reason the conversion from a BOOL object to `bool` (C++ style) may lead to incorrect boolean value. This fixes the value provided to the builder to be of `bool` type instead.
Reviewed By: JoshuaGross
Differential Revision: D16657766
fbshipit-source-id: b66922aceadd20d16226a07f73b24ee0a3b825dc
Summary: It's actually the first module in OSS which is typed with taking advantages of codegen.
Reviewed By: RSNara
Differential Revision: D16620334
fbshipit-source-id: 65d6656506f2a4c68d493939ecfa65ba975abead
Summary: This diff implements the JSResponderHandler methods in the core of RN (scheduler API and friends)
Reviewed By: ejanzer
Differential Revision: D16543437
fbshipit-source-id: dac03e30c4330d182ecf134f3174ba942dbf7289
Summary: Fabric ObjC(++) files will be prefixed by RN* for the time being, this codemod is a simple rename. This includes `interface` and `protocol` definition
Reviewed By: PeteTheHeat, yungsters
Differential Revision: D16611524
fbshipit-source-id: 868d2571ea2414dde4cbb3b75b1334b779b5d832
Summary:
Duplicate category method implementations cause undefined behavior in Objective-C; one is chosen essentially at random. The linker also issues a noisy warning about this (which is how I noticed this case).
It didn't matter in this particular case since both implementations do the same thing, but we should clean this up so people don't get desensitized to these linker warnings. There is no need to have two implementations.
Reviewed By: fkgozali
Differential Revision: D16587219
fbshipit-source-id: 56dc3493735443c476484092f4a7eacfcddee8cb
Summary:
The activityIndicatorViewStyle property overrides the previous set color
if it's changed. Depending on the property set order you may end in a state
that the color property will never be respected since it first sets
the color and then the activityIndicatorViewStyle property (which overrides
the color property). In order to prevent this problem
before setting the new activityIndicatorViewStyle save the old
color and override it after activityIndicatorViewStyle is set. Thus
always respecting the user's color.
## Changelog
[iOS] [Fixed] - Do not override ActivityIndicator color when setting its size
Pull Request resolved: https://github.com/facebook/react-native/pull/25849
Test Plan:
Using the code below on iOS notice that the last ActivityIndicator will always have its color set to white while te testID is provided
### Without the patch
Notice the white -> blue transition when disabling the testID
### With the patch
Color remains unchanged
```javascript
import React from "react";
import { View, StyleSheet, ActivityIndicator, Button } from "react-native";
const App = () => {
const [enableTestID, onSetEnableTestID] = React.useState(true);
const onPress = React.useCallback(() => {
onSetEnableTestID(!enableTestID);
}, [enableTestID]);
return (
<View style={styles.container}>
<ActivityIndicator size="large" color="red" />
<ActivityIndicator size="small" color="red" />
<ActivityIndicator size="small" />
<ActivityIndicator color="green" />
<ActivityIndicator
key={enableTestID.toString()}
size="large"
color="blue"
testID={enableTestID ? 'please work' : undefined}
/>
<Button
title={enableTestID ? 'Disable testID' : 'enable testID'}
onPress={onPress}
/>
</View>
);
};
export default App;
const styles = StyleSheet.create({
container: {
flex: 1,
alignItems: "center",
justifyContent: "center",
backgroundColor: "black"
},
});
```
Closes https://github.com/facebook/react-native/issues/25319
Reviewed By: cpojer
Differential Revision: D16559929
Pulled By: sammy-SC
fbshipit-source-id: ac6fd572b9f91ee5a2cbe46f8c46c1f46a1ba8b3
Summary:
# Disclaimer:
I might be missing something as the solution I implemented here seems like something that was considered by original author. If this solution isn't good, I have a plan B.
# Problem:
`onDismiss` prop isn't being called once the modal is dismissed, this diff fixes it.
Also I've noticed that `onDismiss` is meant to only work on iOS, why is that? By landing this diff, it'll be called on Android as well so we need to change the docs (https://facebook.github.io/react-native/docs/modal.html#ondismiss).
## Video that shows the problem
Following code is in playground.js P70222409 which just increments number everytime onDismiss is called
{F166303269}
Reviewed By: shergin
Differential Revision: D16109536
fbshipit-source-id: 3fba56f5671912387b217f03b613dffd89614c9d
Summary: I think it's possible that there's a race condition between creating the scheduler and setting the delegate leading to bugs like T47272192.
Reviewed By: mdvacca
Differential Revision: D16537737
fbshipit-source-id: 9c579537658be5a9aeed37c0e4935c997cabb6aa
Summary:
As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context).
This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled.
However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries.
This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required.
This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors.
## Changelog
I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619.
Pull Request resolved: https://github.com/facebook/react-native/pull/25816
Test Plan:
Check `RNTesterPods` still works both with and without `use_frameworks!`:
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: hramos
Differential Revision: D16495030
Pulled By: fkgozali
fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
Summary:
UIManager.measureLayoutRelativeToParent will not be supported as part of fabric.
This diff deprecates this method in the current version or React Native.
Reviewed By: fkgozali
Differential Revision: D16471845
fbshipit-source-id: acfda9bfb2dd8553ff8e359ea2c8d7d88a14c6d2
Summary:
This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349.
It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`.
The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` .
There are still a few breaking changes which I hope will be acceptable:
- `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path.
- ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967.
- ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled.
Still to do:
- ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by 33573511f0.
- I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? �
## Changelog
[iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks.
Pull Request resolved: https://github.com/facebook/react-native/pull/25619
Test Plan:
### FB
```
buck build catalyst
```
### Sample Project
Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed.
You can see that it works with these steps:
1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git`
2. `git checkout fix-frameworks-subspecs`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`
The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again.
### RNTesterPods
`RNTesterPodsPods` can now work with or without `use_frameworks!`.
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: PeteTheHeat
Differential Revision: D16465247
Pulled By: PeteTheHeat
fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
Summary: Right now RuntimeExecutor is only used in Fabric. Moving it out of Fabric's uimanager/primitives.h and into react/utils so we can use it more broadly.
Reviewed By: shergin
Differential Revision: D16385366
fbshipit-source-id: 96063e536e1480bac078a9376fe55f7d8750477e
Summary:
These helper functions will be used by the ObjC generated code for support on commands.
This is an example of what that code might look like and how these functions will be used.
```
- (void)handleCommand:(NSString const *)commandName args:(NSArray const *)args
{
if ([commandName isEqualToString:@"scrollTo"]) {
if ([args count] != 2) {
RCTLogError(
@"%@ command %@ received %d arguments, expected %d.", @"ScrollView", @"scrollTo", (int)[args count], 2);
return;
}
NSObject *arg0 = args[0];
if (!RCTValidateTypeOfViewCommandArgument(arg0, [NSNumber class], @"number", @"ScrollView", @"scrollTo", @"1st")) {
return;
}
int x = [(NSNumber *)arg0 intValue];
NSObject *arg1 = args[1];
if (!RCTValidateTypeOfViewCommandArgument(arg1, [NSNumber class], @"number", @"ScrollView", @"scrollTo", @"2nd")) {
return;
}
int y = [(NSNumber *)arg1 intValue];
[self scrollTo:x y:y];
} else if ([commandName isEqualToString:@"scrollToEnd"]) {
if ([args count] != 0) {
RCTLogError(
@"%@ command %@ received %d arguments, expected %d.", @"ScrollView", @"scrollToEnd", (int)[args count], 0);
return;
}
[self scrollToEnd];
}
}
```
Reviewed By: JoshuaGross
Differential Revision: D16474117
fbshipit-source-id: 2bb9f01d7c97cc59e9373b7759021c65980fcc0e
Summary:
This enables Fast Refresh by default.
More concretely:
* For clean installs, it's enabled by default. (You can opt out at any time via the dev menu.)
* For updated DEV apps (on device or simulator), it flips from disabled to enabled **but only if you never touched the setting before**.
* If you previously explicitly enabled and/or later disabled it, we keep your previous setting.
Reviewed By: yungsters
Differential Revision: D16442656
fbshipit-source-id: 1bfe0bf4bcf2830284f9c757fbfacc10db92acb4
Summary:
Macro `ENABLE_PACKAGER_CONNECTION` invalid because of `__has_include` can't find the header now. Leads to packager connection not work anymore.
## Changelog
[iOS] [Fixed] - Fixes iOS packager connection not work
Pull Request resolved: https://github.com/facebook/react-native/pull/25803
Test Plan:
1. Init a new project.
2. Run and input `curl http://localhost:8081/reload` in terminal. Reload operation can execute.
Differential Revision: D16458384
Pulled By: TheSavior
fbshipit-source-id: 27e7e02b5666a2131e995accd34e4da7bad42335
Summary:
The method UIManagerModule.removeSubviewsFromContainerWithID will not be part of fabric. This diff deprecates it to avoid future usage before the migration.
This can not be removed, as it is currently used from React-VR
Reviewed By: shergin
Differential Revision: D16420687
fbshipit-source-id: a06810cabb434e35e5a371444114db2633a35a29
Summary:
The method UIManagerModule.replaceExistingNonRootView will not be part of fabric. This diff deprecates it to avoid future usage before the migration.
This can not be removed, as it is currently used from React-VR
Reviewed By: shergin
Differential Revision: D16420685
fbshipit-source-id: c534e2ee6371698638751f1482bb619db1569733
Summary: We no longer want to access RCTImageLoader from the bridge category. Instead, let's use the `moduleForClass` API.
Reviewed By: shergin
Differential Revision: D16389113
fbshipit-source-id: c638f4b9851698afc53aaaa2b302d21cc19f76e7
Summary: Been reading a lot of code comments getting familiar with Fabric & TM, just fixing a few typos and removing an unused bridge category method.
Reviewed By: shergin
Differential Revision: D16371581
fbshipit-source-id: bf0cc9c873c60e37124dc715c92d7f105e54e42f
Summary: Supporting View Manager Commands on the new UIManager in Fabric. This is needed for things like scrollTo on ScrollView.
Reviewed By: JoshuaGross
Differential Revision: D16175575
fbshipit-source-id: a74effdf7e47b56a150a4e3fb6c4d787659e0250
Summary: `RCTActivityIndicatorViewComponentView` is a component for `ActivityIndicator` not for `ShimmeringView`.
Reviewed By: cpojer
Differential Revision: D16360505
fbshipit-source-id: d6f7685eea24060c9e1b43d5782a65396d6c375e
Summary:
See the comment in the code.
As part of proper fix of it, we also should remove a line in RCTScrollView that nulls the delegate.
Reviewed By: mdvacca
Differential Revision: D16296050
fbshipit-source-id: 54a4c6c60de4bd97c5cfb44652b5dc26852c540c
Summary:
I finally convinced that we need to add this everywhere.
iOS internals can call those methods at any moment (which is happening in coming diffs), so we cannot predict `_eventEmitter` being not null.
Reviewed By: mdvacca
Differential Revision: D16296052
fbshipit-source-id: 34447c2b5af4117d75930d68593d60bace119bbd
Summary: I originally added `forceFullRefresh` as an escape hatch in case Fast Refresh is too unreliable. In practice we haven't seen any major issues with it. Since this option is already very obscure, I'm just removing it.
Reviewed By: shergin
Differential Revision: D16286632
fbshipit-source-id: c3dc44cffd459912e194e273acf868f3380c64cc
Summary:
^
No need for a constructor here.
Reviewed By: fkgozali
Differential Revision: D15056802
fbshipit-source-id: 32a2c541e5c1fa6336b7f6f2131772198740626c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25583
We now use CocoaPods for better maintainability.
Reviewed By: hramos
Differential Revision: D16193719
fbshipit-source-id: 26382f2da4eaba14a71771540b587fdc80b41108
Summary: For now, suppress this warning - they are harmless.
Reviewed By: mdvacca
Differential Revision: D16198994
fbshipit-source-id: b167d0e98bbc4abcd0461d50f01f364d8d560aec
Summary:
Adding viewIsDescendantOf back again, more context 9ae7f0c7da
This method might no not be implemented in Fabric
Reviewed By: fkgozali
Differential Revision: D16186406
fbshipit-source-id: 9cd4c9e20c01713d4e8608a54c6f54082067e27f
Summary:
This is the first step towards fixing https://github.com/facebook/react-native/issues/25349. These are the changes to the podspec to correctly update dependencies and build config that will cause any breaking change for users or libraries.
I am breaking these changes out from https://github.com/facebook/react-native/pull/25393 as suggested by fkgozali in https://github.com/facebook/react-native/pull/25393#issuecomment-508322884.
These are the changes:
- Made C++ headers in `React-Core` private by default so that ObjC files can import the module without failures.
- Reduced the number of `yoga` headers that are exposed for the same reason as above. As far as I can see this doesn't cause issues but we can find another solution if it does.
- Adding some missing dependencies to fix undefined symbols errors.
- Added `DoubleConversion` to `HEADER_SEARCH_PATHS` where it was missing.
## Changelog
[iOS] [Fixed] - Updated podspecs for improved compatibility with different install types.
Pull Request resolved: https://github.com/facebook/react-native/pull/25496
Test Plan:
Everything should work exactly as before. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which points at this branch to show that it is still working `Podfile` to demonstrate this is fixed.
You can see that it works with these steps:
1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git`
2. `git checkout podspec-updates`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`
The sample app will build and run successfully.
Reviewed By: mmmulani
Differential Revision: D16167346
Pulled By: fkgozali
fbshipit-source-id: 1917b2f8779cb172362a457fb3fce686c55056d3
Summary: We have exactly same code in classic RCTScrollView component. We need that to not interfere with iOS automagical behaviours.
Reviewed By: sammy-SC
Differential Revision: D16160846
fbshipit-source-id: 5b5affcc64abe5e3204f619216412f9da5b03b78
Summary:
All props to Eric Lewis! cc ericlewis
This revert of revert of land of changes originally published in #24873 (with some slight fixes). The change removes usage of LocalData from the `<Text>` component.
After this change we only have ---one (maybe two)--- three components left using LocalData.
Reviewed By: mdvacca
Differential Revision: D15962376
fbshipit-source-id: 19f41109ce9d71ce30d618a45eb2b547a11f29a2
Summary: D14477611. The duplicat line may cause the test failure in T46242216 : https://fburl.com/9svdqopu
Reviewed By: sammy-SC, cpojer
Differential Revision: D16082601
fbshipit-source-id: fbd4f4b1ffe6b08faff4b65d7fd44faffc611393
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
Kevin Gozali
Rick Hanlon
Michał Osadnik
David Vacca
Adam Ernst
Samuel Susla
Guilherme Iscaro
Joshua Gross
zhongwuzw
James Treanor
Valentin Shergin
Emily Janzer
Eli White
Dan Abramov
Min ho Kim
Peter Argany
Jeff Thomas
Yike Xue
Radosław Pietruszewski
Ben Blackburne
