Summary:
For the TurboModule interop layer, we'll pass in a second ModuleProvider. We'll default that second parameter to null, when the interop layer is disabled. This change will make that easier.
Changelog: [General][Changed] - Re-organize the parameters of TurboModuleBinding::install()
Reviewed By: javache, cortinico
Differential Revision: D43993199
fbshipit-source-id: 2d339cab1f9bfe481f4b72401caa203cd7536da1
Summary:
This diff is reverting PR https://github.com/facebook/react-native/pull/33468
Due to an increase of java.lang.IllegalStateException caused by the PR
Original commit changeset: cd80e9a1be8f
Original Phabricator Diff: D38410635
Changelog:
[Android][Fixed] - removed logic that calls the [AccessibilityNodeInfo#setError][10] and [#setContentInvalid][13] method to display the error message in the TextInput - Revert of PR https://github.com/facebook/react-native/pull/33468
Reviewed By: NickGerleman, makovkastar
Differential Revision: D44032331
fbshipit-source-id: 732ed0cf23e4f30ae00c51dace851a3fdfe65c01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36461
This change breaks a dependency cycle between `ReactCommon` and `React-Core`.
`React-Core` depends on `ReactCommon` to have access to the various `TurboModule` native files.
`ReactCommon` depends on `React-Core` because the content of the `core/platform/ios` folder and the `samples` folder needs to access the `RCTBridge` and other files in Core.
To break the circular dependency, we introduced two new `podspecs`:
* `React-NativeModulesApple` for the content of `core/platform/ios`.
* `ReactCommon-Samples` for the content of the `samples` folder.
In this way, the new dependencies are linear as `React-NativeModulesApple` and `ReactCommon-Samples` depends on `React-Core` and `ReactCommon` and `React-Core` only depends on `ReactCommon`.
While doing this, we also make sure that all the include path are aligned, to limit the amount of breaking changes.
## Changelog:
[iOS][Breaking] - Split the `ReactCommon/react/nativemodule/core/platform/ios` and `ReactCommon/react/nativemodule/samples` in two separate pods to break circular dependencies.
Reviewed By: mdvacca
Differential Revision: D44023865
fbshipit-source-id: a97569506350db5735ac5534b1592471de196cbe
Summary:
## Rationale
JavaTurboModule holds the module object as a JTurboModule. With the TurboModule inteorp layer, JavaTurboModule will also need to hold NativeModule objects.
## Changes
So, this diff makes JavaTurboModule hold the module object as a jobject instead.
This shouldn't impact method dispatch, because method dispatch doesn't rely on the JTurboModule interface.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D43918939
fbshipit-source-id: 7cc43dfe2df7571e39bcf4d6f362dde0e500e2fe
Summary:
## Rationale
Better separation of concerns. Less confusion. All the logic around TurboModule HostFunction management is in TurboModule::get(). And TurboModule::createHostFunction() is only responsible for creating the HostFunction. Also, there aren't two TurboModule::get functions, each with different/unclear responsibilities.
## Motivation
The interop layer (i.e: D43918998) will have to override TurboModule::createHostFunction():
- TurboModule::createHostFunction() relies on static functions for method dispatch.
- The interop layer cannot use static functions for method dispatch: interop modules' methods are only be discoverable at runtime.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D43918940
fbshipit-source-id: f2ffd210329a10967e9b2f0c925f4990cb470083
Summary:
Refactor the startup performance API so that we are not using a vector to store only a few startup metrics values. This makes the metrics more strictly typed and concise.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D43860049
fbshipit-source-id: 2c2102de2b64e2c5cda509ac26f0d1d072287083
Summary:
changelog: [internal]
This diff introduces a mechanism to cache NSTextStorage on Paragraph's state. The old renderer already has caching for NSTextStorage: https://github.com/facebook/react-native/blob/main/Libraries/Text/Text/RCTTextShadowView.m#L21
Fabric will store `NSTextStorage` inside `ParagraphLayoutManager` which is owned by state.
There is one notable change which is not gated: Paragraph's state strongly owns `TextLayoutManager`, not `ParagraphShadowNode` like previously. This shouldn't change anything
Reviewed By: mdvacca
Differential Revision: D43692171
fbshipit-source-id: efe6077222a30ab6d89abd9916534b9a96e745d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36385
This change moves the `graphics/conversions.h` files from `ReactCommon/react/renderer/graphics` to `ReactCommon/react/renderer/core`, renaming it to `graphicsConversions.h`.
This is required because React-Fabric imports graphics, but graphics imports React-Fabric due to this file.
The change would be breaking, but we don't want to break the ecosystem without even a warning. So, we put back the `conversions.h` file, which now just `include` the new one and outputs a warning when building. This actually maintain the dep cycle for the current version, but at least users are warned.
## Changelog:
[iOS][Deprecated] - Deprecate the `ReactCommon/react/renderer/graphics/conversions.h` in favor of `ReactCommon/react/core/graphicsConversions.h`
Reviewed By: cortinico, dmytrorykun
Differential Revision: D43836261
fbshipit-source-id: ffe53a8ce2b0ea2dd1e1e5aaf6b3d3c5b57ad46d
Summary:
Previously, the touch area could never extend past the parent view bounds. Thus, hitSlop would not have any effect if it extended beyond any ancestor view's view bounds.
In this diff, we apply hitSlop when calculating overflowInset. Specifically, we make sure to union the hit slop areas of all children when calculating the contentFrame.
overflowInset is then used for hit testing (as in [TouchTargetHelper.java](https://www.internalfb.com/code/fbsource/[b0f630bb24271d8ed543e98ff144590290e19805]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/uimanager/TouchTargetHelper.java?lines=195)).
A risk is that other optimizations that may potentially rely on overflowInset beyond hit testing (such as clipToBounds) may not be as efficient with a large hitSlop.
Changelog:
[General][Fixed] - Fix touch handling so that hitSlop can extend beyond parent view bounds.
Reviewed By: javache
Differential Revision: D43854774
fbshipit-source-id: 160bef135b8487c28c4ada662577c35a7a36f484
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36395
NativeState is a lighter-weight alternative to HostObject, which may simplify some of our use-cases of interacting with JS in the renderer. The down-side is that this approach doesn't allow exposing custom props or functions.
This diffs adds new feature flags to enable experimenting with this functionality and measure any perf impact.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D41553421
fbshipit-source-id: 3065bd7b60f0fa7b63c390e92a785582eee7e613
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36202
This changes all of the in-built dependencies in react native app components upon hermes from HermesAPI to HermesAPIFullOrLean.
HermesAPI (full) includes the bytecode compiler and thus has support for eval().
HermesAPILean does not include the bytecode compiler. It throws at runtime if eval is called. The native dependencies are significantly smaller without the bytecode compiler.
The HermesAPIFullOrLean target toggles between full and lean modes based on the value of buckconfig field `hermes.lean_vm` (default is false). Therefore, without overriding this config option, this change is a no-op and should result in react native apps being built with exactly the same dependencies as before.
If you do specify it, you lose eval support at runtime and gain an apk size savings of a few hundred kB after compression.
This also removes the vestigial `hermes_api_dep()` build macro.
skip-frl-buck-targeting
Reviewed By: javache
Differential Revision: D43283200
fbshipit-source-id: 0157be4a9339f70e73d29d694c18b31805107000
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36391
This include isn't required and was causing issues in the Cocoapods build.
Changelog: [iOS][Fixed] Unbreak cocoapods build
Reviewed By: cipolleschi
Differential Revision: D43870523
fbshipit-source-id: 7e31049d19ef025e9e16284712fb2a80dbdf235e
Summary:
Reland of https://github.com/facebook/react-native/issues/35319 with a fix for custom pull to refresh components.
Custom pull to refresh component in fabric will need to conform to the `RCTCustomPullToRefreshViewProtocol` protocol, this way we know that the view is a pull to refresh and not the content view.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [ADDED] - Add fabric support for maintainVisibleContentPosition on iOS
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36095
Test Plan:
This will need to be tested internally in the product the crash happened.
Take a local build of Wilde open Marketplace.
Reviewed By: jacdebug
Differential Revision: D43128163
Pulled By: cipolleschi
fbshipit-source-id: 6cf8ddff92aeb446072a3d847434e21b9e38af61
Summary:
A previous version of this experiment saw crashes on iOS once rolled out. Switching to WeakObject to make sure we're not accessing invalid references, and setting up the ability to experiment with this on iOS.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D41552667
fbshipit-source-id: dc0c54edc2ad18c1947941119ffd50038a47c5f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36367
* Don't iterate over JSI Value to get args, convert each of the args individually instead
* Make LongLivedObjectCollection constructor private
* allowRelease does not need to be virtual
* Move away from const-ness as a thread-safety indicator
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D43354535
fbshipit-source-id: eaf8eb931ab6ec307a3dc2690eabeb34bb6afa77
Summary: This will cause the library to be included multiple times in different dynamic libraries, leading to potentially different values of `CoreFeatures`.
Reviewed By: christophpurrer
Differential Revision: D43772552
fbshipit-source-id: 4590bb9aef7c2330b6e488fa1640eda2720b6e7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36364
## Changelog
[Internal] -
Fixes dependencies, so we don't pull in unneeded iOS ones when we don't care about them (in this case, when running C++ tests for the RN core).
The iOS dependencies came from the `ReactCommon/react/utils` library, that was including ObjectiveC files unconditionally.
Reviewed By: cortinico, dmytrorykun
Differential Revision: D43769718
fbshipit-source-id: e6414e9ee8c5464754a12901f39668331817396e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36346
1. Remove Paper native assertions for converting DimensionValue string to Yoga unit, and fix a case where Fabric could throw on invalid value.
2. Move DimensionValue types in TypeScript to use template literal types, to show malformed strings in-editor, during typechecking. Update min TS version to allow this (in conformance with the min TS version used by DefinitelyTyped).
Changelog:
[General][Added] - Improve handling of invalid DimensionValue usage
Reviewed By: javache
Differential Revision: D43153075
fbshipit-source-id: db4e813df6e81cbd3158edad7c07c7a90c009803
Summary:
This diff adds the `performance.reactNativeStartupTiming` API to the performance global object for RN. This property does not exist in web, and we are free to make up our own list of properties in the startup metrics to track RN app startup process. In our case, we have the following six properties to begin with (we may extend and add more to this list in the future):
```
- `(start|end)Time`: The time ‘zero’ for the startup timing and the end of app startup. RN has no knowledge of app start time, which will be provided by the platform. The `endTime` will be the time when the first JS bundle finishes executing (Note that RN supports multiple JS bundles, which can be loaded async)
- `executeJavaScriptBundleEntryPoint(Start|End)`: The time for RN to execute the JS entry point (and finish all sync job)
```
Changelog:
[General][Added] - Add new JS performance API to support getting RN app startup timings
Reviewed By: rshest
Differential Revision: D43326564
fbshipit-source-id: 7b4c7cae70ff64ba1714a1630cd5e183df6c06b0
Summary:
Changelog[Internal]:
[iOS][Fixed] - Fix crash from calling setProperty in RCTTurboModule
The crash is caused by passing a utf8 encoded string to a Object::setProperty overload which only allows ascii inputs.
Reviewed By: RSNara
Differential Revision: D43705999
fbshipit-source-id: b3f1b3fd27d43d40fe0a170d4c2e60faecc26dad
Summary:
This adds the `UnstableReactLegacyComponentDescriptor`, part of the Fabric Interop Layer for Android.
Summary of the changes are:
* Expose a new `rrc_legacyviewmanagerinterop` native module via prefab
* Extend default App Cmake setup so `rrc_legacyviewmanagerinterop` is exposed by default
* Add a sample legacy component inside RN Tester
Changelog:
[Internal] [Changed] - Expose UnstableReactLegacyComponentDescriptor inside react/renderer/core
Reviewed By: cipolleschi
Differential Revision: D43731219
fbshipit-source-id: ee26d7e9d7eff5ef6a3e22853f8ea363b9198567
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36344
This adds the `UnstableReactLegacyComponentDescriptor`, part of the Fabric Interop Layer,
inside the `react/renderer/components/legacyviewmanagerinterop` module so that it can be included by the user externally.
If we wish to place it somewhere else, I'm more than happy to move it around.
Changelog:
[Internal] [Changed] - Expose UnstableReactLegacyComponentDescriptor inside react/renderer/components/legacyviewmanagerinterop
Reviewed By: mdvacca, cipolleschi
Differential Revision: D43500868
fbshipit-source-id: acfcd89efc42ff7a4ee6cb0a1cbd71d69f79721f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36325
A lot of the code in YogaLayoutableShadowNode expects a 1:1 mapping from ShadowNode children to Yoga Node children, which is not always the case, e.g. for `RawTextShadowNode` (if text, or a number coerced to text, is rendered outside a Text component).
In S323291 we saw this cause memory corruption due to later invalid static_cast. I changed the casting mechanism to terminte instead of corrupting memory, but there is logic here that we need to make permissive (I think D29894182 (d3e836245b) also tried to previously do this?).
Normally Text will be rendered inside of a ParagraphShadowNode, where "Text" from React is mapped to ParagraphShadowNode (which is layoutable), "VirtualText" is mapped to TextShadowNode (which is also not layoutable), then finally the text fragment is mapped to "RawTextShadowNode". Arguably React renderer behavior should be not to send anything to native, but we can provide a generalized solution in YogaLayoutableShadowNode to handle any other cases of this issue.
This solution works by filtering ShadowNode children to those which are YogaLayoutable, then only ever operating on that list of children. This means a guaranteed invariant of the nodes we operate on being layoutable (vs the adhoc error handling right now for when they are not), and means we maintain the index based mapping of ShadowNode children to Yoga Node children.
Note, there is another similar API, `getLayoutableChildNodes()` which is protected and returns a filtered list of LayoutableShadowNode. This is public, to allow querying/setting layout results, whearas the similar operations in YogaLayoutableShadowNode are instead an implementation detail.
Changelog:
[General][Fixed] - Fix YogaLayoutableShadowNode handling of non-layoutable children
Reviewed By: sammy-SC
Differential Revision: D43657405
fbshipit-source-id: 8ed136b03b4da15a5e7dfbdd5539b04a2952420d
Summary:
I've noticed that `UIManagerCommitHooks` are applied after calling `layoutIfNeeded`, meaning that if a commit hook makes some changes to the tree, it needs to calculate the layout again, effectively making the first calculation redundant.
This PR swaps the order of these two operations and moves `shadowTreeWillCommit` call before `layoutIfNeeded`. Thanks to this change, commit hooks don't need to manually trigger layout calculations as well as can potentially operate on unsealed nodes which can make it more efficient in some cases.
Finally, this PR eliminates a crash on `emitLayoutEvents(affectedLayoutableNodes);` when commit hook actually modifies the tree and thus de-allocates old shadow nodes.
cc sammy-SC
## Changelog
[GENERAL] [CHANGED] - Run commit hooks before layout calculation
Pull Request resolved: https://github.com/facebook/react-native/pull/36216
Test Plan: The only `UIManagerCommitHook` I could find in the OSS repo is [`TimelineController`](8bd3edec88/ReactCommon/react/renderer/timeline/TimelineController.h (L26)).
Reviewed By: cipolleschi
Differential Revision: D43569407
Pulled By: sammy-SC
fbshipit-source-id: 9ab1de0954cac2eb00346be7af8c9b3572bd2c88
Summary:
In [this commit](e6cba99744), we renamed `Geometry.h` to `Vector.h`.
This is the last change of a series of updates that progressively altered the shape of `Geometry.h` from its [original version](https://github.com/facebook/react-native/blob/0.71-stable/ReactCommon/react/renderer/graphics/Geometry.h).
This is a breaking change as several libraries in the OSS are depending on Geometry.h and we removed it without deprecating it.
This change aims to put the file back, with a deprecation message, so that we can safely remove it in the next version.
## Changelog
[General][Fixed] - Restore Geometry.h to avoid breaking change
Reviewed By: cortinico
Differential Revision: D43621983
fbshipit-source-id: 96b976901f7ec337f2ec64c592e4b4d19d89ab11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36258
This fixes a few instances where YogaLayoutableShadowNode (or general shadownode casting) could offer better memory safety.
1. The reference form of traitCast() now terminates on invalid cast, instead of debug assert, since it is better to crash in production than to corrupt memory (which will crash somewhere later, in a much more confusing way).
2. We use traitCast() in more places where we previously would static_cast. This means needing to formally add a mutable version.
3. We bounds-check yoga children access in a single place by using `std::vector` `at()` instead of `[]`.
4. Removed `Trait::UnreservedTrait1` API, since multiple libraries using it can collide and we lose the memory safety benefits of `traitCast`.
This change is in response to a bug where `YogaLayoutableShadowNode` may perform an invalid `static_cast` of `RawTextShadowNode` if a text or number is rendered directly inside of a `<View>` (instead of a `<Text>` element).
This does not yet fix the underlying logic of YogaLayoutableShadowNode to act gracefully when a RawTextShadowNode makes its way into children. We just terminate, instead of corrupting memory.
Changelog:
[General][Breaking] - Better Fabric ShadowNode Memory Safety (Removes `Trait::UnreservedTrait` API)
Reviewed By: javache
Differential Revision: D43271779
fbshipit-source-id: 727c1230f72664bf4d261871c66ca61ddf0d5ffa
Summary:
add print yoga node AllEdge value when debug mode, the old logic just print four edgeValue including top left bottom and right
but when we set the same value to these edge, we use YGAllEdge, this will be more convenient debug code
so I open this pull request to add it
X-link: https://github.com/facebook/yoga/pull/948
Reviewed By: cortinico
Differential Revision: D43525328
Pulled By: NickGerleman
fbshipit-source-id: 59dde363e6ee8433d10ecf27e440ea7d54000bc1
Summary:
Original commit changeset: 43c4e4f1ae6b
Original Phabricator Diff: D43275024 (c5bc3f1373)
D43587488 reverted D43275024 (c5bc3f1373), but it was only committed to the fbobjc/releases/release-fbios-2023.03.01 branch (v404).
We still aren't seeing successful fbios-pika-iphoneos-release builds for v405 (https://fburl.com/mobile/7zac3b5w). This is preventing QA and employee dogfooding of v405 (S325502).
(Note: this ignores all push blocking failures!)
Reviewed By: abashyam
Differential Revision: D43609260
fbshipit-source-id: d411294ad8cdb22ff9e812bf0689d9b7bdff8d2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36177
react_native_assert calls C `assert()`, where XCode does not have a built-in breakpoint navigator to hook to assertion failures (though you can add a symbolic breakpoint to "abort()" to get the effect). This changes the Apple implemented of `react_native_assert()` to use `NSCAssert` under the hood. This is safe to use in C functions, but will be trapped by the default XCode exceptions breakpoint navigator.
Changelog:
[iOS][Fixed] - Use NSCAssert() in react_native_assert instead of C assert()
Reviewed By: cipolleschi
Differential Revision: D43275024
fbshipit-source-id: 43c4e4f1ae6b99f32634d4b1880bce712c3ae8f6
Summary:
[Changelog][Internal]
This adds a method, `emitDeviceEvent` to the C++ API of TurboModules, which allows to make calls to JS's `RCTDeviceEventEmitter.emit` from a C++ TurboModules.
This is a very common pattern, specifically for the VR apps, but not only for them - e.g. Desktop fork also has a [custom implementation for this](https://www.internalfb.com/code/fbsource/third-party/microsoft-fork-of-react-native/react-native-utils/RCTEventEmitter.cpp).
Note that my original intent was to actually backport the latter, however there are some complications with wiring things in a robust way, without exposing too much stuff and relying on singletons or folly::dynamic.
So I ended up adding it to the TurboModule API itself and use the scheduler/JSI facilities instead.
This approach is arguably well self-contained, uses high level APIs, and shouldn't be abusable much.
Since I was trying to avoid usage of folly::dynamic in this case, I used a kind of "value factory" pattern instead in order to send the arguments to the JS thread in a thread safe way (see [the discussion here](https://fb.workplace.com/groups/rn.fabric/permalink/1398711453593610/)).
Reviewed By: christophpurrer
Differential Revision: D43466326
fbshipit-source-id: a3cb8359d08a46421559edd0f854772863cb5c39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36210
One of the circular dependencies we have in OSS was between React-Codegen and React-Fabric.
React-Codegen generates component which has to depends on React-Fabric because they need to use the files contained in the `react/renderer/view` folder.
React-Fabric contains some components that depends on RNCore, which was generated inside the React-Codegen folder.
This change generates the RNCore components inside the `ReactCommon/react/renderer/components/rncore` folder, breaking the dependency as `rncore` folder is now contained by React-Fabric itself.
**Fun Fact:** That's how it always should have been. There was already a line in the `.gitignore` to exclude the content of `ReactCommon/react/renderer/components/rncore` folder. I guess that with some of the refactoring/previous projects on Codegen, this requirements has slipped.
## Changelog:
[iOS][Breaking] - generates RNCore components inside the ReactCommon folder and create a new pod for platform-specific ImageManager classes
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43304641
fbshipit-source-id: ebb5033ce73dbcd03f880c3e204511fdce04b816
Summary:
Update podspecs with the right search paths to include the required framework by every module.
## Changelog:
[iOS][Changed] - Update search paths to support `use_frameworks!` with Fabric
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089372
fbshipit-source-id: 4bbfc4b98bd289d66ce4015429d581856d9c05b3
Summary:
changelog: [internal]
Making a copy of shared_ptr is order of magnitude more expensive than moving it. This diff avoids two redundant copies in commit phase.
Reviewed By: rubennorte, cipolleschi
Differential Revision: D43306245
fbshipit-source-id: cfa942cc67b1e5c91be47803b80f7c8cda2e32d8
Summary:
Changelog:
[General][Fixed] - Reduce use of assertions when parsing accessibility props passed from JS
Fixes some more cases along the same lines as D43184380 (d16c1a04d8) and D43184994 (ee4714e369).
Reviewed By: jacdebug
Differential Revision: D43324899
fbshipit-source-id: fb343203f16464009931f07592e663b06dcf20e7
Summary:
changelog: [internal]
C++17 has implementation of shared_mutex in standard library. Let's use it instead of folly.
Reviewed By: cipolleschi
Differential Revision: D43275493
fbshipit-source-id: d766251226aa230110011aca94b4e697fe0d31a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36164
Changelog:
[General][Fixed] - Invalid prop values no longer trigger assertion failures in Fabric
## Context
Fabric has historically been very strict about prop parsing. It originally `abort()`ed on any prop value that failed to parse according to the expected type; this was replaced with dev-only assertions in D27540903 (cb37562f83). We've received feedback that C++ assertions (and other similar mechanisms in the legacy renderer) are still too aggressive and disruptive as a diagnostic for developers working on JS code.
We are changing React Native to behave more like a browser in this regard, reflecting a new principle that **bad style values are not runtime errors**. (See e.g. D43159284 (d6e9891577).) The recommended way for developers to ensure they are passing correct style values is to use a typechecker (TypeScript or Flow) in conjunction with E2E tests and manual spot checks.
More broadly, values passed from JS product code should not be able to crash the app, which is why we're not strictly limiting this change to style props. From now on, if a JS developer can trigger an internal assertion in React Native simply by writing normal application code, that is a bug.
## This diff
This diff introduces a new macro called `react_native_expect` which serves as a drop-in replacement for `react_native_assert`, but logs (to glog / logcat / stdout) instead of asserting. This way we don't need to fully delete the existing call sites. This will be helpful if we decide that we want to repurpose these checks for a new, more visible diagnostic.
I'm *intentionally* opting for the simplest possible improvement here, which is to silence the assertions - not to print them to the JS console, not to convert them to LogBox warnings, etc. The hypothesis is that this is already strictly an improvement over the previous behaviour, will help us get to feature parity between renderers faster, and allow us to design improved diagnostics that are consistent and helpful.
## Next steps
1. There are still places where Fabric can hit an unguarded assertion in prop conversion code (e.g. unchecked casts from `RawValue` with no fallback code path). I will fix those in a separate diff.
2. Paper on iOS needs a similar treatment as it calls `RCTLogError` liberally during prop parsing (resulting in a native redbox experience that is nearly as bad as an outright crash). I will fix that in a separate diff.
3. I'll add some manual test cases to RNTester to cover these scenarios.
4. We will eventually need to take a clear stance on PropTypes, but since they provide reasonable, non-breaking diagnostics (recoverable JS LogBox + component stack) it is less urgent to do so.
Reviewed By: sammy-SC
Differential Revision: D43184380
fbshipit-source-id: 0c921efef297d935a2ae5acc57ff23171356014b
Summary:
`setComponentDescriptorProviderRequest` is only used on iOS for dynamic registration of additional components. This variable is not default initialized, so will point to invalid memory when a component is missing and thus crash.
Changelog: [Internal] Fix Android crash when component is missing
Reviewed By: rubennorte
Differential Revision: D43305656
fbshipit-source-id: 70dd2973d50abbfcc19e051bd24c1deb90883941
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36158
To properly setup the Header Search Paths for `use_frameworks!`, we need to move the files that are in the `.../textlayoutmanager/platform/ios` folder into the `.../textlayoutmanager/platform/ios/react/renderer/textlayoutmanager` folder.
This mimic the same folder structure we have also `android`
## Changelog
[iOS][Changed] Moved the files from `.../textlayoutmanager/platform/ios` to `.../textlayoutmanager/platform/ios/react/renderer/textlayoutmanager`
Reviewed By: cortinico
Differential Revision: D43088586
fbshipit-source-id: 9589fe62f36fbff2744fdfbf3475e95954424232
Summary:
To properly setup the Header Search Paths for `use_frameworks!`, we need to move the files that are in the `.../imagemanager/platform/ios` folder into the `.../imagemanager/platform/ios/react/renderer/imagemanager` folder.
This mimic the same folder structure we have also `android`
## Changelog
[iOS][Changed] Moved the files from `.../imagemanager/platform/ios` to `.../imagemanager/platform/ios/react/renderer/imagemanager`
Reviewed By: cortinico
Differential Revision: D43088421
fbshipit-source-id: c3b86a95e67cc1ab9531997bb1bfbf011b7f730f
Summary:
To properly setup the Header Search Paths for `use_frameworks!`, we need to move the files that are in the `.../textinput/iostextinput` folder into the `.../textinput/iostextinput/react/renderer/components/iostextinput` folder.
This mimic the same folder structure we have also `android`
## Changelog
[iOS][Changed] Moved the files from `.../textinput/iostextinput` to `.../textinput/iostextinput/react/renderer/components/iostextinput`
Reviewed By: cortinico
Differential Revision: D43084639
fbshipit-source-id: fe0f55d9f372bda0fbd59c6c567ac747ca308a69
Summary:
To properly setup the Header Search Paths for `use_frameworks!`, we need to move the files that are in the `.../nativemodule/xxx/platform/ios` folder into the `.../nativemodule/xxx/platform/ios/ReactCommon` folder.
We have two folders to migrate: `core` and `sample`.
As a cleanup, `sample` should be extracted from the codebase and moved to RNTester or a library as it can be used as an example to add more examples in the codebase that we ship to our users.
This mimic the same folder structure we have also in `cxx` and `android`
## Changelog
[iOS][Changed] Moved the files from `.../nativemodule/xxx/platform/ios` to `.../nativemodule/xxx/platform/ios/ReactCommon`
Reviewed By: cortinico
Differential Revision: D43082851
fbshipit-source-id: 414426274d9a5ab20cc0e76cdada0c2977264b5f
Summary:
To Properly setup the Header Search Paths for `use_frameworks!`, we need to move the files that are in the `react/renderer/graphics/platform/ios` folder into the `react/renderer/graphics/platform/ios/react/renderer/graphics` folder.
This mimic the same folder structure we have also in `cxx` and `android`
## Changelog:
[iOS][Changed] - Moved the files from `.../platform/ios` to `.../platform/ios/react/renderer/graphics`
Reviewed By: sshic
Differential Revision: D43082032
fbshipit-source-id: 519d2e12eb7edd50b5f71bac5b1c618c6bf89919
Summary:
This removes the null-check on Yoga config added (we think we root-caused the issue), and adds an assertion to the public API accepting a config that it is non-null.
There are more changes to config setting that will come later.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D43273456
fbshipit-source-id: cba498352d114a3fa2694f3a144f5f01a83d3190
Ian Childs
Ramanpreet Nara
David Vacca
Riccardo Cipolleschi
Xin Chen
Samuel Susla
Genki Kondo
Pieter De Baets
Ryan Schoppmeyer
Janic Duplessis
Ruslan Shestopalyuk
Nick Gerleman
Wei Han
Nicola Corti
Simeng Pang
fabriziobertoglio1987
Tomek Zawadzki
acton393
Jeffrey Beauchamp
Joshua Selbo
Moti Zilberman