Summary:
Changelog: [internal]
We have a comment explaining how to update all generated files everywhere but here.
Reviewed By: NickGerleman
Differential Revision: D56717344
fbshipit-source-id: cc538e37dd6ab09f67d67bb13ce4e560870d44d0
Summary:
There are a couple scenarios where flattening the child of a ScrollView can cause problems.
1. `maintainVisibleContentPosition` on both Android and iOS rely on reading live positions in the view tree
2. `snapToAlignment` on Android uses live view tree, for items to snap to. iOS seems to have very different behavior, and aligns assuming that children are scroll view height, or that a snap interval has been set.
This change adds a prop `collapsableChildren` which can be used to disable children of scroll content view from being collapsed.
Differentiator is... complicated... but we can mostly just adapt the code dealing with existing traits at the surface level.
Changelog:
[General][Fixed] - Automatically disable flattening of scroll content view children when needed
[General][Added] - Add `collapsableChildren` prop
Reviewed By: javache
Differential Revision: D56226241
fbshipit-source-id: ed81f7fff5a15eac424708f763afc9b844aefa9c
Summary:
Set the proper build flags for debugging in Bridgeless mode.
This fixes [#44240](https://github.com/facebook/react-native/issues/44240)
## Changelog:
[iOS][Fixed] - Add `HERMES_ENABLE_DEBUGGER=1` flag to React-RuntimeApple
Reviewed By: cortinico
Differential Revision: D56575647
fbshipit-source-id: a0613a5d46caeb1d3e636e54ecd43428fbaf46e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44231
changelog: [internal]
The flag is not used and is statically set to false, let's delete it.
Reviewed By: NickGerleman
Differential Revision: D56473851
fbshipit-source-id: fe1076d20a765ffed2437f080764f2b5fe060bb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44236
## Changelog:
[Android] [Fixed] - fix a case when view preallocation or props forwarding on Android lead to dropped props update
# What does this fix
This fixes a bug where prop change is not delivered to Android mounting layer if the prop change was initiated from state update inside of `useLayoutEffect`, `componentDidMount` or `componentDidUpdate`.
This affects android only and when batched rendering is enabled.
There are two root causes of this problem:
1. View preallocation on Android: https://fburl.com/code/r62p3vot
2. Prop forwarding on Android: https://fburl.com/code/644f1ppk
Minimal repro :
```
import React, {useLayoutEffect, useState} from 'react';
import {Button, SafeAreaView, View} from 'react-native';
function Foo() {
const [bgColor, setBgColor] = React.useState('red');
useLayoutEffect(() => {
console.log('useLayoutEffect');
setBgColor('blue');
}, []);
return (
<View
style={{
backgroundColor: bgColor,
width: '100%',
height: '100%',
}}
/>
);
}
function RNTesterApp() {
const [show, setShow] = useState(false);
return (
<SafeAreaView>
<Button title="Toggle" onPress={() => setShow(!show)} />
{show && <Foo />}
</SafeAreaView>
);
}
export default RNTesterApp;
```
# The underlaying problem
The problem is combination of view preallocation and batched rendering updates.
Here is a step by step what happens in the repro above:
1. React issues asks Fabric to create new shadow node A with background colour **red**.
2. Fabric asks Android to allocate a view for shadow node A with background colour **red**.
3. React commits tree **T1** and calls layout effects. Meanwhile Fabric waits, without trying to mount the tree **T1**, to prevent painting state that is about to be updated and prevent flickering.
4. React clones node A, changing the background colour to **blue** and commits the new tree **T2**.
5. Fabric, will now go ahead and mount the latest tree **T2**. While creating mount instructions, it will drop prop updates because it believes prop updates where delivered already as part of step 2.
# The fix
The fix is to change two things:
1. Ignore view preallocation for shadow nodes which were cloned with new props.
2. Set hasBeenMounted flag on ShadowNode later in the Fabric pipeline to fix it.
Both of these are hidden behind a single feature flag: `fixMountedFlagAndFixPreallocationClone`
## Performance implication:
I estimate that this will impact around 3% of views.
Reviewed By: rubennorte
Differential Revision: D56353589
fbshipit-source-id: 651d3cd2d0f78bfbbe9c05aa1ae1b1690c15e4ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44188
The current approach used for `batchRenderingUpdatesInEventLoop` is not compatible with Android due to limitations in its props processing model. The raw props changeset is passed through to Android, and must be available for the Android mounting layer to correctly apply changes.
We have some logic to merge these payloads when multiple ShadowNode clones take place but were previously assuming that a ShadowTree commit was a safe state to synchronize.
In the current implementation this means that two commits driven from layout effects (triggering states A → B → C) may cause Android to observe only the B → C props change, and miss out on any props changed in A → B.
Changelog: [Android][Fixed] Cascading renders were not mounting correctly when `batchRenderingUpdatesInEventLoop` is enabled.
Reviewed By: rubennorte
Differential Revision: D56414689
fbshipit-source-id: 7c74d81620db0f8b7bd67e640168afc795c7a1d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44209
## Changelog:
[Android] [Fixed] - When React Native is destroyed, unmount all Fabric surfaces.
Previously, Fabric surfaces would not be torn down. Meaning that passive and layout effects wouldn't be unmounted and surface infra wouldn't be cleaned up.
For example:
```
useEffect(() => {
return () => {
console.log('unmounted');
}
)};
```
When calling `ReactNativeHost.clear()` on Android in native code, the above effect should be unmounted.
This is a requirement for Fabric.
Reviewed By: javache
Differential Revision: D56238947
fbshipit-source-id: 5dbf5cdef520f34c78953c2b8f2d42349549e893
Summary:
This decouples the listing of modules from the linking of those modules into Cocoapods. I've made this backwards compatible, but our internal template wont lean on the community config.
The user can now override how they capture a list of React Native modules, providing an escape hatch for Framework authors to build on.
Changelog: [General][iOS] Use our fork of the react-native-communti/cli-platform-ios use_native_modues.rb script
Reviewed By: cipolleschi
Differential Revision: D56242486
fbshipit-source-id: 78505669ab6abd6718348388c3bfba3290f7071b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44206
Changelog: [internal]
We finally managed to implement mount hooks without reliability issues on Android, so we can clean up the feature flag and enable it unconditionally.
Reviewed By: cortinico
Differential Revision: D56467379
fbshipit-source-id: d797ec770b731135332bc9f39df1c1e684b3bde4
Summary:
This change splits the React-Fabric podspec in two podspecs: React-Fabric and React-FabricComponents.
The reson is that we are codegenerating some of the core components and we want for the FabricComponents to depend on ReactCodegen.
Before this change, we had a circular dependency if we make ReactFabric depends on Codegen because ReactCodegen has to depend on ReactFabric.
Now, the dependency graph would be:
`React-FabricComponents --> ReactCodegen --> React-Fabric`
and no cycle is created
## Changelog
[internal] Split React-Fabric in React-Fabric and React-FabricComponents
Reviewed By: cortinico
Differential Revision: D56306355
fbshipit-source-id: 8b609d9c962913d5d730ac1c4e3614777b5953d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44097
There are two places where we use a feature specific to the system version of 'cp', the:
-X Do not copy Extended Attributes (EAs) or resource forks.
This feature isn't available in GNU's cp, which is commonly installed on macOS using:
brew install coreutils && brew link coreutils
We can avoid the problem alltogether by being specific about the path of the system cp.
Changelog: [General][Fixed] don't break script phase and codegen when coreutils installed on macOS
Reviewed By: cipolleschi
Differential Revision: D56143216
fbshipit-source-id: f1c1ef9ea2f01614d6d89c4e9eedf43113deb80c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44128
Changelog: [Internal]
idk what happened but this link got abbreviated when i copypastad it, fixing it here
Reviewed By: javache
Differential Revision: D56228228
fbshipit-source-id: 35c5c9fb44e82083773302618474c1e3bbc71712
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44120
changelog: [internal]
Prevent measuring the same text twice in `ParagraphShadowNode`.
The current implementation calls `TextLayoutManager::measure` twice for a single `ParagraphShadowNode`. The first time to measure the node for Yoga. The second time inside `ParagraphShadowNode::layout`. I think the original author counted on the cache inside of `TextLayoutManager` to deal with this, but this is not always the case and `TextLayoutManager::measure` is called with two different available widths, leading to cache miss and fills the cache faster.
Reviewed By: NickGerleman
Differential Revision: D55757264
fbshipit-source-id: 0bf8b49f062f802a4e2f04cad1bf1d4bf001b870
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44089
While doing the release of 0.74.0-RC.9, we encountered some failures while building because the committed project had some new flags that have been added by cocoapods and that required Ccache.
However, Ccache is not a hard requirement to run React Native and the build started failing on systems that does not have ccache installed.
That happened because we were missing the piece of code that removed Ccache from the project in case the tool is not installed in the system.
We already committed such commit in the stable branch of 0.74, with [this commit](https://github.com/facebook/react-native/commit/2b18fdf8063b423a0fb5762f2c6044244b4c35e6). This change will port the same fix in main.
## Changelog
[iOS][Fixed] - Make sure to remove ccache scripts when ccache is not installed
Reviewed By: cortinico
Differential Revision: D56140015
fbshipit-source-id: 24e7ebb4e5c08766b29705e8b6f03c3f164a96ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44022
changelog: [internal]
move the new state reconciliation algorithm to the unified feature flag system.
Reviewed By: rubennorte
Differential Revision: D55965530
fbshipit-source-id: 3edde0858a670e86dc2d1cb561f03f584ff21896
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44015
Changelog: [internal]
## Context
When we introduced synchronous state updates in Fabric, we saw some crashes on coming from the mounting layer on Android.
It seems some of these crashes are caused by nested mount operations. When we're mounting some views, like [scroll views](https://github.com/facebook/react-native/blob/881c0bc8970b9e402df6b4f87e1759b238b24735/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactHorizontalScrollView.java#L383), we dispatch state updates that end up doing more mutations. When we were doing these state updates asynchronously, all the original mutations were processed before these updates, but now that we do them synchronously, the mutations are interleaved causing errors.
## Changes
This introduces a new flag that will force all the mutations going through `MountItemExecutor` in `FabricUIManager` to be batched instead of executed synchronously. This fixes the issues I saw locally and I'm expecting this will unblock synchronous state updates in production.
Potentially, this might fix other crashes we've been seeing with a low frequency.
Reviewed By: sammy-SC
Differential Revision: D55942125
fbshipit-source-id: b8d9c145ec307de7318dbbed14880bc9a84fdb2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43963
changelog: [internal]
This experiment did work out. Let's clean it up
Reviewed By: cortinico
Differential Revision: D55797519
fbshipit-source-id: a5da97a7d31b9395b25bfd37db567054721599b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43853
Changelog: [internal]
## Context
This is part of a refactor to decouple the performance entry reporter from the rendering infra and from the native module that uses it.
## Changes
This moves the logic to report the timing of events to a separate class (outside `PerformanceEntryReporter` that now is agnostic to the rendering infra).
Reviewed By: sammy-SC
Differential Revision: D55646392
fbshipit-source-id: 5032a36b23d0741b19fb74cb04f0af3d3d476ef0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43913
changelog: [internal]
We have this turned on in ParagraphShadowNode, let's roll it out for TextInput as well.
I came across this while profiling scroll performance when TextInput is part of the view hierarchy.
Reviewed By: javache
Differential Revision: D55751341
fbshipit-source-id: 2af20ddb5a4fb9b0ccd33217e60e8b9e8a95b920
Summary:
This allows build configuration named like `StagingDebug` to match with settings applied to `Debug` This fixes https://github.com/facebook/react-native/issues/43185
Custom build setting were only applied to `Debug` build configurations, preventing configurations named `StagingDebug` or similar to access the new experimental debugger, as reported in https://github.com/facebook/react-native/issues/43185
This now applies the setting to every configuration ending with `Debug`
## Changelog:
[IOS] [CHANGED] - fix: build settings for custom build configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/43780
Reviewed By: dmytrorykun
Differential Revision: D55688996
Pulled By: cipolleschi
fbshipit-source-id: 1f34cd722f6acfaa08d3377e19a04d08af97ed7c
Summary:
Changelog: [iOS][Added]
this creates the RN privacy manifest in the ios build step if user has not created one yet. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53687232
fbshipit-source-id: 6dffb1a6013f8f29438a49752e47ed75c13f4a5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43653
Changelog: [internal]
This will allow us to clean up some code in `UIManager` (using methods in the native module instead) and prepare to use the DOM APIs in OSS behind a feature flag.
This doesn't enable the DOM APIs in OSS, only the native module.
Reviewed By: javache
Differential Revision: D55365252
fbshipit-source-id: 70ec0eb022df586ad554c5b8ce6915b8ceddef5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43580
Changelog: [internal]
This introduces a new feature flag to commit state updates synchronously from the UI thread (generally) instead of dispatching them to the JS thread to be processed there. We can do this now because we introduced a UI consistency mechanism in D55024832 to JS would see a consistent revision during the execution of a specific task.
Reviewed By: sammy-SC
Differential Revision: D55083029
fbshipit-source-id: 8aa84ddaee383f098252fa679cfb07012ba29bf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43581
Changelog: [internal]
This implements a mechanism to ensure that JavaScript tasks have a consistent view of the state of the UI during their execution.
## Context
Fabric allows committing new revisions of the ShadowTree from any thread, but we don't make use of this capability and instead always commit them from the JS thread (e.g.: when we schedule Fabric state updates to update the offset of a list on scroll). This was done to make sure that JS work didn't see changes in the state of the tree at random points during its execution. E.g.:
```
useEffect(() => {
const rect = ref.current.getBoundingClientRect();
// do something
const newRect = ref.current.getBoundingClientRect();
// `rect` and `newRect` should always be the same
}, []);
```
This isn't used by Reanimated at the moment, which means JS can inadvertently see the result of animations in non-specific times during execution.
You can find additional context about this in the [RFC for DOM Traversal & Layout APIs in RN](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0607-dom-traversal-and-layout-apis.md#consistency-and-updates).
This works correctly at the moment, but we introduce a limitation in the execution model to prevent updating the tree synchronously from the main thread. One of the main problems this introduces is that computing intersections (for `IntersectionObserver`) relies on the information in the shadow tree, but this is updated asynchronously on scroll.
There are 2 potential solutions for that problem:
1) Send the timestamp of the scroll even with the state update to backdate the timestamps of the intersections. This could work but introduces more complexity and possibly accuracy problems due to batching those state updates with other changes (e.g.: what happens if we update the state and commit another tree in the same task? should we use the backdated timestamp or wait for mount?).
2) (**Preferred**/ this diff) Allow committing new revisions from any thread, but lock the JS thread into seeing a specific revision, which would only update/progress in specific moments when it's safe. Some of those moments would be:
1) When we start a new JS task.
2) When we commit a new tree from React (JS).
## Changes
This implements the solution outlined in 2), creating a few abstractions to handle what's the current tree that should be visible to JS and to lock/unlock it in specific moments.
More specifically:
* Creates `ShadowTreeRevisionProvider` as an abstract class for APIs consuming the visible revision of the ShadowTree (mainly DOM APIs and layout methods like `measure`, etc.).
* Creates `ShadowTreeRevisionConsistencyManager` as an abstract class to handle what trees are visible (with a `lockRevision` and `unlockRevision` to be called from `RuntimeScheduler` at the beginning and end of each JS task).
* Creates 2 different implementations of these abstractions:
* One that preserves the current behavior (`LatestShadowTreeRevisionProvider`, which just returns the last committed revision at the time of the call).
* One that locks revisions lazily (the first time they're accessed) (`LazyShadowTreeRevisionConsistencyManager`).
Reviewed By: sammy-SC
Differential Revision: D55024832
fbshipit-source-id: b59985bc83714ae7ec915baba72bf92b3d6fa140
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43583
Fail during `pod install` if user's version of XCode is too old to avoid cryptic errors (e.g. https://github.com/reactwg/react-native-releases/issues/163).
I reused existing mechanism for version detection, though it may not be reliable for future versions of XCode.
Changelog:
[iOS][Changed] - Warn users during "pod install" if XCode is too old
Reviewed By: dmytrorykun
Differential Revision: D55149636
fbshipit-source-id: 78387ff19a6eb10f3ca0d4aa78e6b934ae3b0711
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43385
`rncore` and `FBReactNativeComponentSpec` contain the same symbols, which leads to conflicts when we try to merge them into a single shared library. Cleanup the duplication and standardize on `FBReactNativeComponentSpec` everywhere. I've left the Android OSS targets as is, to avoid breaking deps.
Changelog: [Internal]
Reviewed By: cortinico, dmytrorykun
Differential Revision: D54630694
fbshipit-source-id: 75cb961ded9fd75508755c0530e29409fef801cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43504
Changelog: [internal]
We identified the issue in the experiments already, so we can remove this flag.
Reviewed By: sammy-SC
Differential Revision: D54945099
fbshipit-source-id: 4d547569eb3bbfd011f5d6894d87bfa542cac07b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43506
Changelog: [internal]
We've been making all the built-in C++ TurboModules in RN extend `enable_shared_from_this` because we copied from the same template that needed it, but none of them do. This removes that unnecessary extension.
Reviewed By: sammy-SC
Differential Revision: D54901332
fbshipit-source-id: 795c7696e70041d640399e3b9f177999e22fd90b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43482
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Now that we are confident that `CDPAgent` is stable, switch to it by default and remove the previous integration.
- Drop `inspectorEnableHermesCDPAgent` feature flag.
- Rename and replace `HermesRuntimeAgentDelegateNew` as `HermesRuntimeAgentDelegate`.
- Drop "Hermes integration: CDPAgent" log message.
- Update tests.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54897841
fbshipit-source-id: 8a5212d27f21c54112c0820a2a3611e05d606880
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43397
Changelog: [internal]
This migrates the Hermes-specific use of microtasks to an engine agnostic implementation based on the new JSI method to queue microtasks.
Reviewed By: sammy-SC
Differential Revision: D54687056
fbshipit-source-id: b077ba47b80f7b31c77b7e449def8a56061b0b69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43395
Changelog: [internal]
This moves native module specs to `specs` directory to align with the general convention.
Reviewed By: cortinico
Differential Revision: D54680056
fbshipit-source-id: 8b6ae6187e2ffa9120159b7d1fa25957677e0f4f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43393
Changelog: [internal]
The generator doesn't create intermediate directories, which is causing issues now that we're moving the generated native module spec to a new directory.
This fixes that.
Reviewed By: rshest
Differential Revision: D54690126
fbshipit-source-id: 1ba0d821872da7bbe1f6120ef6d0c1f800326778
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43353
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Integrates `HermesRuntimeAgentDelegateNew` (using the new Hermes `CDPAgent` setup) into `HermesRuntimeTargetDelegate` behind a new feature flag, `inspectorEnableHermesCDPAgent`. This completes the initial integration for all platforms.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54586162
fbshipit-source-id: 5f26c28af4414d961b1c8c9cb4cd7135bd00b410
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43368
This diff replaces direct invocation of the `cp` command with the platform agnostic `fs.cpSync`.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D54634108
fbshipit-source-id: 41fe7b44b6534026ef1b930da85725bf3eb1e7bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43356
To make it accessible across different dylib/bundle.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D54601288
fbshipit-source-id: e65b724b228a680784e81b8c51ecd3f4df3fd668
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43349
Changelog: [internal]
We still haven't found the root cause of some of the crashes we're seeing in the experiments to enable mount hooks on Android.
This adds a new feature flag to skip part of the mount hooks pipeline to see if we can scope the investigation to that specific part (where we query the root tree in the base revision from the mounting coordinator).
Reviewed By: sammy-SC
Differential Revision: D54587739
fbshipit-source-id: 792aa8b06808e96638d1bba072bf4060ec492bd2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43350
Changelog: [internal]
Mount hooks have been shipped on iOS, so this removes the flag for them.
On Android, we're still testing them so it's worth moving them to the new system and scoping them to that platform.
Reviewed By: sammy-SC
Differential Revision: D54587740
fbshipit-source-id: d074927fee1a967bd3928970c31975d07cd393bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43329
Improve maintainability of this file, in particular reducing the probability of a merge conflict for new entries.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D54539469
fbshipit-source-id: dc2fca42b4490d87c532b21043b0855d8d1a894d
Summary:
This change moves the prepack script of react-native in a separate script, so we can make sure we execute all the preprocessing we need before packing and publishing React Native to OSS.
## Changelog:
[General][Changed] - Moved the tasks of prepack in a separate node script
Reviewed By: huntie
Differential Revision: D54308411
fbshipit-source-id: 989c2b8c6cf88a1e9d87cf34e43351b5c0e7ea73
Summary:
Added a check to avoid the regeneration of RNCore components in case they have been generated already.
In order to maintain backward compatibility and to make sure not to break internal use cases, I think we should still keep the possibility to generate these components at `pod install` time.
Internal users of RNTester, for example, will not run `yarn prepack` before building react-native using OSS technology.
Notice that, in this specific case, the Codegen generates the file in a path that is not `node_modules`.
## Changelog:
[General][Added] - Skip generation of RNCore if the files have been already generated
Reviewed By: dmytrorykun
Differential Revision: D54308832
fbshipit-source-id: 0b5822a367eb0b191c42bc92f8bff20d541c5b29
Summary:
This change extracts the function to create RNCore components in a separate reusable unit.
RNCore is now generate in the `node_modules` folder when the app runs pod install, which is a problem because there are use cases where it's not possible to modify the `node_modules` folder or the generated files might be lost.
The goal is to:
- extract this function
- execute this function before packing react-native during the release. (see D54308411)
In this way, we are going to generate the RNCore files in the react-native path that will be packaged and then released.
Users of react-native will have the generated code directly in the node_modules with no need to generate it.
## Changelog:
[General][Added] - Add function to only generate RNCore components
Reviewed By: huntie
Differential Revision: D54308713
fbshipit-source-id: 0fa9ab4ba7b66c577663f0c736742c4d5583f617
Summary:
This change factor out in a variable the `libraryName` to avoid verbosity.
## Changelog:
[Internal] - factor out libraryName
Reviewed By: dmytrorykun
Differential Revision: D54308601
fbshipit-source-id: 1a64a6b960cc86a1cff059e3ba6a45c33bf3150e
Summary:
This change refactor the RNCORE_CONFIGS in a separate variable to simplify reuse.
## Changelog:
[Internal] - Refactor code
Reviewed By: dmytrorykun
Differential Revision: D54308346
fbshipit-source-id: b9d7c8e0a9b4042f2ab1adeb7aae875264d22499
Summary:
This diff removes extra argument from the `extractLibrariesFromJSON` call inside `findLibrariesFromReactNativeConfig`.
This should fix the iOS failurte discribed in https://github.com/facebook/react-native/issues/43204
Changelog: [iOS][Fixed] - Codegen correctly handles react-native.config.js.
Reviewed By: cipolleschi
Differential Revision: D54248400
fbshipit-source-id: 2ae5d0d29f49725877559a5b0edd7d59f8bdefaa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43159
Changelog: [internal]
This modifies the default `RCTAppDelegate` for iOS apps in OSS to provide an implementation for the C++ native module for feature flags.
In a following diff I'll replace the `React-featureflagsnativemodule.podspec` file with one that includes all built-in C++ native modules.
Reviewed By: RSNara
Differential Revision: D54082349
fbshipit-source-id: 8c4ed7499c6fd35916ba105edcae0e2c85961e1c
Summary:
This diff renames React-Codegen to ReactCodegen. This way we'll no longer have to try both
```
#include <React-Codegen/MyModule.h>
```
and additionally
```
#include <React_Codegen/MyModule.h>
```
for cases with `use_frameworks`.
Changelog: [iOS][Breaking] - Rename React-Codegen to ReactCodegen
Reviewed By: cipolleschi
Differential Revision: D54068492
fbshipit-source-id: dab8ea2034d299266482929061caa14397421445
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43135
This change makes the New Architecture the default on both iOS and Android.
This means that new application will be created using the New Architecture by default.
It is still possible to opt out from it.
## Changelog
[General][Changed] - Make the new architecture the default
Reviewed By: cortinico, sammy-SC, dmytrorykun
Differential Revision: D54006751
fbshipit-source-id: bd7de0814925b65ab180105e18c1f6f275ba2672
Rubén Norte
Nick Gerleman
Riccardo Cipolleschi
Samuel Susla
Pieter De Baets
Blake Friedman
Phillip Pan
Andrew Datsenko
Jean-Baptiste LARRIVIERE
Pieter De Baets
Alex Hunt
Dmitry Rykun
Adam Ernst