Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41732
Was reading the code in this file and noticed that this comment is no longer true after D51068417 (https://github.com/facebook/yoga/pull/1460). Updated the comment to reflect the current state of things
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51730986
fbshipit-source-id: beaa5de9576d86e56def35f6e970376c7be8f7ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41712
I fixed the const correctness of YGConfigGetErrata a while back when fixing up other YGConfig accessors.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51689323
fbshipit-source-id: 1af3deb44ec03a8a65643fa1496c534ac8f6d057
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41436
Add a JSI API for associating some native memory with a JS object. This
is intended to provide a mechanism to trigger more frequent garbage
collection when JS retains large external memory allocations, in order
to avoid memory buildup.
This diff just adds the JSI method, without any implementations.
Changelog:
[General][Added] - Added JSI method for reporting native memory to the GC.
Reviewed By: tmikov
Differential Revision: D50524912
fbshipit-source-id: c8df0e18b0415d9523e0a00f6d0ed2faa648ac68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41719
We leak ReactInstanceManager into a static singleton in `ReactCxxErrorHandler.setHandleErrorFunc`. Clean it up in `destroy()`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D51706624
fbshipit-source-id: 642825ba14ff0a9710b4435f5fb6026b3a81b711
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41704
`mOnViewAttachItems` was set to be be concurrent, but this would be unexpected, as all mount item operations occur solely on the main thread.
Simplify this to be just a LinkedList and annotate the methods as being UI thread only.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51662154
fbshipit-source-id: 9fe5784bce8a38d1339b5e3675791414676b6f4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41711
We want the default position to be relative for a number of reasons. This should be fine for the most part but putting a killswitch around this change just in case things blow up.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51643446
fbshipit-source-id: 4f7d1e498eb663801ef6d88ba9cd9b64c781d66b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41709
We shipped these new create()/reload()/destroy() methods to the Facebook app:
- Part 1: D50802718
- Part 2: D50803283
This diff just enables them everywhere, by default.
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D51590843
fbshipit-source-id: 02abeea78b7b7b844552989ad58d0a2f048424ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41700
The type definition of `useMergeRefs` is incorrect, which forces all callsites to use `$FlowFixMe`. This fixes the definition and removes all the `$FlowFixMe`s caused by it.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D51660716
fbshipit-source-id: 4d4d3a72bdca8c409fd1dda59cc2c94113b024bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41701
I did a hotfix for this logic in D51618512. This does a small refactor to improve the code (moving more shared code to the hook and avoiding creating a closure unnecessarily in every call to it).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D51660288
fbshipit-source-id: 472836840b19958402bd0de3e2c09c7cec004156
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41695
When I went to update documentation, I kinda internalized how inconsistent the API is if we don't change iOS Paper.
The potential for breaks is if an iOS-specific component ignores a warning, and uses `onScroll` without `scrollEventThrottle`, then relies on `onScroll` only being called once.
It didn't seem like we hit this scenario in practice when migrating Fabric ComponentView behavior, and components will need to support it in new arch anyway, so this change takes the less conservative option of unifying the behavior everywhere.
Changelog:
[iOS][Changed] - scrollEventThrottle no longer needs to be set for continuous scroll events
Reviewed By: cipolleschi
Differential Revision: D51647202
fbshipit-source-id: e2a57f3501b9096e4033cb198bbc214d53e9913c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41681
## Rationale
Make initHybrid static. So that the derived class can initialize the C++ part with constructor arguments.
**Note:** This diff just applies the fix from D51550623. into CxxReactPackage.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51642219
fbshipit-source-id: 095e452e03848379288af960969789aa5e9c0542
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41708
RN-Tester is currently instacrashing due to a method accepting a `Float?` rather than a `Float`.
`Float` from Kotlin gets converted to Java's `float`, while `Float?` gets converted to the boxed type, which is not recognized by the framework and is making the app crash.
On top of this, the implementation of `setColor` was wrong as we don't properly handle the null case. Fixing it here as well.
Changelog:
[Internal] [Changed] - Fix broken RN Tester custom ViewManager
Reviewed By: NickGerleman
Differential Revision: D51667346
fbshipit-source-id: b7498a520936f81a0524ba53dc7230ad7ef57bf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41706
This change introduces a ReadME in the CircleCI folder.
This can be used as documentation to learn more about our CircleCI setup and will also help GitHub employees in executing the migration.
## Changelog:
[Internal] - Add CircleCI documentation
Reviewed By: cortinico
Differential Revision: D51665453
fbshipit-source-id: f61325ed26572c4a8d4a68db1cca5934d3d968fb
Summary:
Currently, when we have an additional platform in `react-native.config.js`, users cannot use custom `resolver.resolveRequest` functions as they are overwritten by `reactNativePlatformResolver`. Goal of this PR is to allow OOT platforms to use additional custom resolvers besides remapping react native imports.
## Changelog:
[GENERAL] [FIXED] - Allow Out Of Tree platforms to pass custom resolvers
Pull Request resolved: https://github.com/facebook/react-native/pull/41697
Test Plan:
1. Add additional platform in `react-native.config.js`
2. Pass custom resolver to `metro.config.js`:
```js
resolveRequest: (context, moduleName, platform) => {
console.log('resolveRequest', moduleName, platform);
return context.resolveRequest(context, moduleName, platform);
}
```
3. Check if user's `resolveRequest` function is called.
Reviewed By: huntie
Differential Revision: D51659721
Pulled By: robhogan
fbshipit-source-id: 952589b59a6fa34e9406d36c900be53a7c1a79c3
Summary:
This is my proposed solution to https://github.com/facebook/react-native/issues/41677.
Fixes https://github.com/facebook/react-native/issues/41677.
## Changelog:
[ANDROID] [FIXED] - Fix android root view group removal during instance re-creation
Pull Request resolved: https://github.com/facebook/react-native/pull/41678
Test Plan:
Both with fabric enabled and disabled (new architecture):
1. Clone repro repo: https://github.com/wschurman/rn-reload-repro
2. Build and run on android (I use android studio)
3. Click reload button, see timestamp doesn't change (indicating that the view is not removed)
4. Apply this PR as a patch.
5. Re-build and run.
6. Click reload button, see view is correctly disposed of and the new view is set.
Reviewed By: cortinico
Differential Revision: D51658524
Pulled By: javache
fbshipit-source-id: d9a026cde677ad1ec113230bc31bd9297bca8bfc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41698
With the previous changes on the Pod configuration, the build setup for the New and Old architecture are the same.
The only observable difference happens at runtime.
This change:
1. Removes the build job that are split by architecture (which is now duplicated work)
2. Add two more test jobs to run runtime tests (unit and integration test) to make sure that the two architectures continue working.
## Changelog:
[Internal] - [CI] Remove duplicated build jobs, add tests jobs
Reviewed By: cortinico
Differential Revision: D51659275
fbshipit-source-id: 769c9ee004e7f4f1a7444f39c02b7083e007b780
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41669
In some previous changes ([a607692](https://github.com/facebook/react-native/commit/a6076924bf43dff6cf4d38d51df279edba3882d0) and [6b53205](https://github.com/facebook/react-native/commit/6b5320540adfe16803ef41353f23115d08819309)) we make sure to always include all the pods (including Fabric) and we unify codegen to run in the same way on both architectures.
While doing so, we enabled codegen to run on libraries tat already migrated to Fabric.
These makes those libraries to fail when building as they were not including the Fabric code when the New Architecture is disabled.
This change will make sue that the code is always included, thus the library should always build, and it also make sure that we can control the New/Old Architecture at build time.
## Changelog
[iOS][Changed] - Make sure that libraries always include Fabric code also in the old architecture
Reviewed By: dmytrorykun
Differential Revision: D51617542
fbshipit-source-id: 883d1e258c341feb0405ad389bb8af34d64b59b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41496
Refactoring `DefaultReactNativeHost` to use the new way of Fabric initialization through `FabricUIManagerProviderImpl`
Reviewed By: christophpurrer
Differential Revision: D51224854
fbshipit-source-id: 2af8021404365fa2adc9388f44bcc7c6301137dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41676
This has been used in a significant amount of production for about 2 months, with no consistently statistically significant metric impact. Let's ship it.
Note that we would not want to keep this change in a holdout if we remove the warning, since new usages could be added that relied on the behavior not in the holdout.
It didn't seem worth the churn to make the same change to Paper, which leaves a question on how to handle the JS-side warning. Instead of jimmying in impl detection, I thought it might be more sane to remove the warning, though that also has a potential hit to Paper DevX.
Changelog:
[iOS][Changed] - `scrollEventThrottle` no longer needs to be set for continuous scroll events when using the new architecture.
Reviewed By: javache
Differential Revision: D51608970
fbshipit-source-id: 193019de208f3088519e6f6333dbec4e6b45a1eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41693
This diff fixes app warm start time. Before this change, we cache the first time when app start timing is logged, and ignore future loggings. Some apps are warm started and the startup time should be updated.
Reviewed By: dmitry-voronkevich
Differential Revision: D50481710
fbshipit-source-id: 03e00b75ee7ac578209ae3478adabe567e92a950
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41480
X-link: https://github.com/facebook/yoga/pull/1469
The previous version of static didn't do anything inside of Yoga. Now that we're making it do something, this changes the default back to relative so that users with no errata set don't see their deafult styles changing.
Reviewed By: joevilches
Differential Revision: D51182955
fbshipit-source-id: c0ea357694e1367fb6786f1907dfff784b19a4bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41481
This will allow us to keep RN on it's "pseudo-static" mode, while changing the Yoga default back to relative, to avoid breaking existing layouts.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D51182861
fbshipit-source-id: 25489d7f0642c4ff78340438c2b266e95a5fb207
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41506
Adding APIs for `getFabricUIManager()` to ReactContext and it's subclasses. This will replace the `getJSIModule()` post JSI module deletion.
Thereby replacing the callsite to context.getFabricUIManager() in UIManagerHelper.
NOTE: This still has fallback to getJSIModule() in case the UIManagerProvider is not set
Changelog:
[Internal] internal
Reviewed By: philIip
Differential Revision: D50926218
fbshipit-source-id: f311affb0f82895b254fd4664aa8ea23ab31bac0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41575
We currently do not validate the incoming native exception message
before passing it to the char* constructor of TwineChar16.
Treat it as UTF-8 and convert it to UTF-16 before creating the
JavaScript exception.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D49551640
fbshipit-source-id: 762f8038b29818d804bda5a7f3b4762621c94336
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41680
Just like how React Native can have n ReactPackages, it will support n CxxReactPackages.
This way, many applications can share common CxxReactPackages.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51484844
fbshipit-source-id: b9b70cab719e80a7ff7e635057d710f1a86fb1c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41679
This fixes a bug in the original implementation of image attached callbacks (still experimental). The problem was that we were unconditionally caching the ref passed to the underlying image component, which meant that whenever users passed new ref setters we wouldn't call them again.
This fixes that by forcing the creation of a new ref value whenever a new ref is passed to the image component.
Changelog: [internal]
Reviewed By: jehartzog
Differential Revision: D51618512
fbshipit-source-id: ac15160c528563c2131e8b3444dea4a6096f20bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41673
## The Problem
The cxxReactPackage property isn't initialized by the time initHybrid was executed. So, initHybrid was being called with null as the cxxReactPackage.
Why;
1. The default turbomodule manager delegate receives cxxReactPackage as a constructor param.
2. Java then executes all the constructors of the class hierarchy. This executes initHybrid.
3. Java finally initializes the properties of the derived class: default tmmd.cxxReactPackage (i.e: the parameter to initHybrid). **This is too late**
## The Fix
Refactor the code such that hybrid data creation doesn't depend on property initialization:
1. Create a static initHybrid method in default tmmd.
2. Call this static method with the cxxReactPackage, and assign the resultant HybridData to mHybridData (in tmmd).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51550623
fbshipit-source-id: ed2b7587351cfca408cda3c8cef4dcf7547e5f1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41674
The problem: The Java runtime couldn't find CatalystCxxReactPackage.initHybrid.
Why: I think is because CxxReactPackage loads CatalystCxxReactPackage's so in its constructor. This might be too late to load the derived class's so.
So, I just switched derived delegates to load the so in the static initializer (i.e: the recomended approch for so loading):
https://www.internalfb.com/code/fbsource/[91c4e41c49ed191ac864250ccaec52c01ddaeccc]/fbandroid/libraries/soloader/java/com/facebook/soloader/SoLoader.java?lines=52-54%2C60-61%2C63-67
This way:
1. The So's are loaded plenty early (the method not found error went away).
2. We don't create our own so loading infra, which complicates this abstraction, and makes it harder to work with, even more.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51550622
fbshipit-source-id: f4782d6fa9387f21fbf611191e9483e2a58b3a34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41675
FBJni expects the HybridData object to exist on the mHybridData property of the java object. So, we have to call this propery mHybridData.
Otherwise, this fbjni class just won't work.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51550621
fbshipit-source-id: d169266474717f0a38799ede7c07af57461012b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41667
changelog: [internal]
I made a mistake during refactor in D51471667 where I removed the check if rawProps is nullptr. We must check if props are empty during `UIManager::clone`, leaving the check for `ConcreteComponentDescriptor::cloneProps` does not lead to the same result.
There is a deeper problem here that needs to be analysed but this should resolve the lunch blocker.
Reviewed By: javache
Differential Revision: D51614396
fbshipit-source-id: 055694c4a71a914d8732a3632c50026cc24cbe7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41660
While working on other things, I noticed those warnings firing on console which I'm fixing here.
Changelog:
[Internal] [Changed] - Fix several build warnings on RN Tester Android
Reviewed By: cipolleschi
Differential Revision: D51589072
fbshipit-source-id: 1ddb29afd0d150f1ccbc7a8def9f27ecedb69724
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41661
This aligns the Kotlin version used inside fbsource to the one used for React Native GitHub
Changelog:
[Internal] [Changed] - Kotlin to 1.8.22
Reviewed By: NickGerleman
Differential Revision: D51587726
fbshipit-source-id: 5f985bd50c7688e4d369184b79dbf1bdc799876e
Summary:
While working in an app I kept getting these `View X of type Y has a shadow set but cannot calculate shadow efficiently. Consider setting a background color to fix this` warnings even though I had added a background color to that view. Upon inspecting RCTView.m I notice that what is actually required to fix this is a solid background
To make this a bit clearer to developers I believe we should update this log message to explicitly say "solid background" instead of "background"
## Changelog:
[IOS] [CHANGED] - Update 'cannot calculate shadow efficiently' log message to explicitly say solid background
Pull Request resolved: https://github.com/facebook/react-native/pull/39700
Test Plan: N / A
Reviewed By: christophpurrer
Differential Revision: D51584574
Pulled By: javache
fbshipit-source-id: b1741f7002ebb876e4a50959bef7f39df76a5c3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41394
X-link: https://github.com/facebook/yoga/pull/1463
Now that are enums are unsigned, and we don't have BitfieldRef, we can convert the last remaining user of NumericBitfield to a plain old bitfield, for better readability (e.g. the default values), debugability, and less complexity. We also break a cycle which lets us properly group public vs private members.
Reviewed By: joevilches
Differential Revision: D51159415
fbshipit-source-id: 7842a8330eed6061b863de3f175c761dcf4aa2be
Summary:
This PR removes duplicated `pod 'Yoga'` as it is already declared in `use_react_native`.
## Changelog:
[INTERNAL] [REMOVED] - duplicated pod 'Yoga' in RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/41627
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D51603340
Pulled By: NickGerleman
fbshipit-source-id: 89e77e5a544cb54d77b969462130725853b36d5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41658
changelog: [internal]
FabricEventDispatcher does not need to run on every frame. Whenever a new event is added to Fabric's event queue, it will call `FabricUIManager.onRequestEventBeat` in Java. This in turn calls `FabricEventDispatcher.maybePostFrameCallbackFromNonUI` and adds a frame callback on the Choreographer.
This makes code simpler, as we do not need to manage the frame callback subscription.
Reviewed By: sammy-SC
Differential Revision: D50604303
fbshipit-source-id: ce2c7b77678bfc14aa7ecac71e40f78263c7036a