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:
# Problem:
I enabled Fabric for "Profile About", when I navigate to "Marketplace Home" from "Profile About", I get following warning "<Component> is not Fabric compatible yet". Even though the component has been migrated to Fabric and is getting registered. The component works if I navigate straight to "Marketplace Home".
{F172219008}
# How it was solved:
It turns out, there was a missing call that added newly created registry to `componentDescriptorRegistries_`.
Reviewed By: shergin
Differential Revision: D16542109
fbshipit-source-id: 22a315333cfff0895ce77e8439816f4e7bf34d35
Summary:
Yesterday we shipped hermesengine.dev as part of the current 0.60 release. This PR brings those changes to master.
## Changelog
[General] [Added] - Added support for Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/25613
Test Plan:
* CI is green both on GitHub and at FB
* Creating a new app from source can use Hermes on Android
Reviewed By: cpojer
Differential Revision: D16221777
Pulled By: willholen
fbshipit-source-id: aa6be10537863039cb666292465ba2e1d44b64ef
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:
Implements a new host function on the global object in debug builds, called `globalEvalWithSourceUrl`. This performs a global `eval()` and attaches a URL/filename to the evaluated script (in stack traces, debuggers, etc).
It serves a similar purpose to the `//# sourceURL=` directive (which most JS engines support, but JSC doesn't) and to the old `nativeInjectHMRUpdate` function which was dropped in the JSC->JSI migration.
Reviewed By: cpojer
Differential Revision: D16491506
fbshipit-source-id: bd9a89311dcbb1d0baece77ead16b9ecfb13bfe3
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 https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302.
- 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: This diff exposes the legacy measure() method on Fabric. This method will be replaced by getRelativeLayoutMetrics in the future, but we are exposing this in order to make Fabric migration easier.
Reviewed By: JoshuaGross, shergin
Differential Revision: D16432928
fbshipit-source-id: 25cc21fb48ec0749081f112af9230bfe53314d6b
Summary: This diff exposes the new methods SetJSResponder and clearJSResponder in the UI ManagerBinding interface
Reviewed By: shergin
Differential Revision: D16420689
fbshipit-source-id: 606bede1de6b9d5fd5a56e832ad27100b6998c55
Summary:
This change lets `registerBundle(bundleId, file)` throw an exception
when the file is empty, improving on the current behavior of an
eventual SIGABRT saying "MAP_FAILED: Invalid argument"
Reviewed By: ridiculousfish
Differential Revision: D16451938
fbshipit-source-id: b8b2d0bfed476319c379122fad59a5bf0a8c813b
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: Adds internal API that we can use to conduct experiments.
Reviewed By: SidharthGuglani
Differential Revision: D16340463
fbshipit-source-id: 07a8bb7dbc4a02c5c95f1ad29b18845ab43752cf
Summary: Right now we register ReactFabric as a callable module with the bridge so that we can call `ReactFabric.unmountComponentAtNode` in `ReactInstanceManager.detachViewFromInstance`. In bridgeless mode we don't have callable modules, so I'm just setting a global variable that can be called from C++ instead. Using this in a new `unmount` method in FabricUIManager.
Reviewed By: shergin, mdvacca
Differential Revision: D16273720
fbshipit-source-id: 95edb16da6566113a58babda3ebdf0fc4e39f8b0
Summary:
Remove check whether `measureCache_` is nullptr. It was part of the experiment
which is no longer running.
Reviewed By: shergin
Differential Revision: D16360332
fbshipit-source-id: 2fc8baa93a87754da6255bf1c134901447349f7a
Summary: Using enum struct for using enums in form ENUM_NAME::ENUM_VALUE for better code readablility
Reviewed By: davidaurelio
Differential Revision: D16356562
fbshipit-source-id: cbe7adadad78eb5d0756c44679c0e102b7d31ec6
Summary:
`YGStyle` puts Yoga enums (which are signed integers by default) into bitfields: https://fburl.com/7fowlunu
Mixing signed values and bit-fields can be error-prone and it also fails to build on Windows with `clang-cl` due to `-Wbitfield-constant-conversion` warning being treated as error:
```
stderr: In file included from xplat\yoga\yoga\YGLayout.cpp:8:
In file included from xplat\yoga\yoga/Utils.h:8:
In file included from xplat\yoga\yoga/YGNode.h:13:
xplat\yoga\yoga/YGStyle.h(110,9): error: implicit truncation from 'YGAlign' to bit-field changes value from 4 to -4 [-Werror,-Wbitfield-constant-conversion]
alignItems_(YGAlignStretch),
```
This diff fixes the problem by making all enums unsigned integers. This change can be problematic only if values of the enums are serialized somewhere. CC: David Aurelio
Reviewed By: davidaurelio
Differential Revision: D16336729
fbshipit-source-id: ee4dabd7bd1ee429e644bd322b375ec2694cc742
Summary:
Based on Hermes Issue: https://github.com/facebook/hermes/issues/47
It was not actually a bug in Hermes, but a bug in JSI, assuming that all string property names from
`folly::dynamic` are ASCII.
Now we'll be more intentional and directly state `forUtf8` rather than the implicit ASCII encoding.
Reviewed By: mhorowitz
Differential Revision: D16347857
fbshipit-source-id: 6bcfbf9f918dc0a7a485b88a1b537d6c2dd322cc
Summary: Ran clang-format on all of JSI.
Reviewed By: mhorowitz
Differential Revision: D16347858
fbshipit-source-id: 004afde1944f60a2c0989a7c38d5b3c58587f1cb
Summary:
`stubViewTreeFromShadowNode` was implemented without using `calculateShadowViewMutations` (aka Diffing algorithm).
The problem is that we use `stubViewTreeFromShadowNode` to test the diffing, so it was not fully correct to use the algorithm to test itself.
Reviewed By: JoshuaGross
Differential Revision: D16342526
fbshipit-source-id: 2674245ed5ec71309fe5d362779a33d8dd31dc7b
Summary: That's extremly helpful for debugging, it allows to see the generated view structure (as diffing sees it).
Reviewed By: JoshuaGross
Differential Revision: D16342528
fbshipit-source-id: bc303d5cab992e517b7cf29962d7c1232e8aeec7
Summary:
1. The check is now correct.
2. Now we call that "Invalid", not "Empty" because this case is invalid indeed.
Reviewed By: JoshuaGross
Differential Revision: D16342527
fbshipit-source-id: 433f6c5759d2d0756d55acb057b5639a8eab2e5d
Summary:
Trivial.
Before that we didn't have a way to get a root node from a Tree object.
It's useful during debugging (and some coming changes use that).
Reviewed By: mdvacca
Differential Revision: D16342529
fbshipit-source-id: 27c7516f3b3fccc8d8b25d4d2748006f7958ae41
Summary:
This diff fixes the parsing of the textAlign prop in Fabric. The current parsing does not support 'justify' or 'auto' values.
See https://facebook.github.io/react-native/docs/0.59/text-style-props#textalign for more details about the values of these props in the JS side.
Reviewed By: shergin
Differential Revision: D16269509
fbshipit-source-id: e0d9168d6022245430de644f7c4e45c968b1326b
Summary:
When you call a TurboModule method with JS arguments, we necessarily convert these JS args to Java objects/primitives before passing them to the Java implementation of the method. The problem is that we let the type of the JS arg dictate the type of the Java object/primitive to convert said arg to. This means that if a JS developer passes in an `number` to a function that expects an `Array`, we'll convert the number to a `double` and try to call the Java method with that `double`, when it actually expects a `ReadableArray`. This will trigger a JNI error, and crash the program. Ideally, we should be able to catch these type mismatches early on.
In this diff, on every TurboModule method call, I parse the method signature to determine the Java type of each JS argument. Then, for any argument, if the JS arg and the Java arg types aren't compatible, I raise an exception, which gets displayed as a RedBox in development. This diff also implements support for `?number` and `?boolean` argument and return types in TurboModules.
Reviewed By: mdvacca
Differential Revision: D16214814
fbshipit-source-id: 4399bb88c5344cff50aa8fe8d54eb2000990a852
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: That should help to fail early in situations when we lose critical class data members.
Reviewed By: sammy-SC
Differential Revision: D16179539
fbshipit-source-id: da73b81568c2f3657b9bc2bd1cc7ee6624e75626
Summary: This is a very similar mechanism that we use in UIManager and it should be eventually unified.
Reviewed By: sammy-SC
Differential Revision: D16179524
fbshipit-source-id: 7c8c45b7581ac4a1db3a773d62004ff368f18321
Summary: Adds Baseline start and end events to be handled later for instrumentation
Reviewed By: davidaurelio
Differential Revision: D16048790
fbshipit-source-id: 8409dbb633168753a7bf8fab20bc6551d113ddd6
Summary: Using layoutPassStart and LayoutPassEnd events instead of YGMarkerLayout for instrumentation
Reviewed By: davidaurelio
Differential Revision: D16048789
fbshipit-source-id: 041a35bc2cb1b7281ca83cf9d35041b4011cfeb9
Summary: Accessibility is essential but seems we don't have any use of AccessibleShadowNode in Fabric.
Reviewed By: sammy-SC
Differential Revision: D16139595
fbshipit-source-id: a6aec6d22c4a6050d7ee5e6b21ef4ad04d80ffce
Summary:
The instrumentation header only needs the forward declarations for ostream, so
we can use just include `iosfwd`, as suggested by Riley in an earlier diff.
Reviewed By: kodafb
Differential Revision: D16152451
fbshipit-source-id: 2afbc40e623b180dfc5917fc8093ab15bf647968
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: This diff exposes LayoutDirection as part of UpdateLayoutMountItem
Reviewed By: JoshuaGross
Differential Revision: D16060521
fbshipit-source-id: 163bf2a0bdca62dcecb03a8aaa2f4bf595b18c8f
Summary: This fixes the parsing of textAlign prop in BaseTextProps class. The name is textAlign and not alignment.
Reviewed By: JoshuaGross
Differential Revision: D16057477
fbshipit-source-id: a00a472af4c7df0a6cd3d6efb17b30cd9134907b
Summary:
Previously, we stored `keyIndex_` in a Parser object which is incorrect because it makes the parsing process thread-unsafe (the Parser is shared between parsing processes).
That worked previously most of the time because we never parsed props concurrently but we actually do this in the native animation library.
Reviewed By: yungsters
Differential Revision: D16064557
fbshipit-source-id: 211f4301d0746e0f5126a1dcdd59f1ae9a420aa9
Joshua Gross
Samuel Susla
Championrunner
cpojer
James Treanor
Moti Zilberman
Emily Janzer
David Vacca
Will Holen
Min ho Kim
Peter Argany
Eli White
David Aurelio
Sidharth Guglani
Uladzislau Paulovich
Riley Dulin
Valentin Shergin
Ramanpreet Nara
Kevin Gozali
Ashok Menon