Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42871
Minor improvements:
* Removed unused imports
* No longer need to use `static const *` because now we don't rely on pointer equality (we specify the index of the array where to write now).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D53416934
fbshipit-source-id: 9ea12b8398688666e6b76768d3f8fb4e1aad5d1c
Summary:
`react-native/community-cli-plugin` is unable to resolve out-of-tree platforms in monorepos because the package may not be hoisted to the same location. For example, if `react-native/community-cli-plugin` was hoisted:
```
/~/node_modules/react-native/community-cli-plugin/dist/utils
```
It may never find `react-native-macos` if it wasn't hoisted:
```
/~/packages/my-app/node_modules/react-native-macos
```
## Changelog:
[GENERAL] [FIXED] - Fix `react-native/community-cli-plugin` is unable to resolve out-of-tree platforms in monorepos
Pull Request resolved: https://github.com/facebook/react-native/pull/42875
Test Plan: Tested in an internal project.
Reviewed By: cipolleschi
Differential Revision: D53426607
Pulled By: robhogan
fbshipit-source-id: 29b9fe92d5773d0160bba375d2e92ec688652e3e
Summary:
Original commit changeset: 32898e1ba30b
Original Phabricator Diff: D52998256
[General][Removed] - Back out: Gradle plugin for resolving node_modules packages.
Backing this (my own diff) out as it breaks CI - I'm not sure why it landed.
Reviewed By: cipolleschi
Differential Revision: D53427912
fbshipit-source-id: baec254a463e3f7827d6a8675499aab34069ddd1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42823
This is a tiny new Gradle plugin intended to be published to the Gradle Plugin Portal independently of React Native. It's only function is to resolve `node_modules` package roots using a sufficient subset of the Node JS resolution algorithm - e.g, we can use it to find `react-native` itself from a user's project, whatever package manager or workspace setup they're using, in a Gradle-friendly, cacheable manner.
The plugin is both a `Settings` plugin and a `Project` plugin, so that it may be used from both `settings.gradle` (where we need it to resolve `react-native`) and `app/build.gradle` (which currently applies from `cli-platform-android`).
The setup is mostly `gradle init` with a few modifications (eg, Kotlin JVM version) to stay close to the setup for `react-native-gradle-plugin`. I think it's easier to reason about this currently as an entirely separate Gradle project, but we may be able to merge the two and reduce some duplication once it's proven.
Changelog:
[General][Added] - Gradle plugin for resolving node_modules packages.
Reviewed By: cortinico
Differential Revision: D52998256
fbshipit-source-id: 32898e1ba30bccabca11b623f03959a51898afe8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42870
This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety:
* It makes all cached feature flags atomic to prevent data corruption when writing them concurrently.
* It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector.
Performance-wise, this is lock-free so it would still be fast enough for our use cases.
Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D53406924
fbshipit-source-id: 1023673c40f9da43a51c5f96354d4c458c9d14d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42869
`DefaultReactNativeHost` builds a `ViewManagerRegistry` based on a list of ViewManagers, which is inefficient, as we have to allocate them all ahead of time (defeating the purpose of `ViewManagerOnDemandReactPackage`). Instead provide a `ViewManagerResolver`which lazily resolves them.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53406841
fbshipit-source-id: be8437e2127fb6741d1948cecbcf5c3d9f8de268
Summary:
This PR fixes a specific case pointed out by dmytrorykun, where there might be no platform or `deployment_target` specified at all and in that case we assume that this library supports every platform (same as Cocoapods).
## Changelog:
[IOS] [FIXED] - Don't add compiler conditionals when no platforms are specified
Pull Request resolved: https://github.com/facebook/react-native/pull/42867
Test Plan:
Test running codegen when library doesn't specify a `platform`:
```
require 'json'
package = JSON.parse(File.read(File.join(__dir__, 'package.json')))
Pod::Spec.new do |s|
s.name = 'OSSLibraryExample'
s.version = package['version']
s.summary = package['description']
s.description = package['description']
s.homepage = package['homepage']
s.license = package['license']
s.author = 'Meta Platforms, Inc. and its affiliates'
s.source = { :git => package['repository'], :tag => '#{s.version}' }
s.source_files = 'ios/**/*.{h,m,mm,cpp}'
install_modules_dependencies(s)
end
```
Check generated `RCTThirdPartyFabricComponentsProvider`
Reviewed By: cortinico
Differential Revision: D53405625
Pulled By: dmytrorykun
fbshipit-source-id: 0f6917c56b84f0fa29807f516acdbd8d15aa5b46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42822
The conversion to string was introduced in D45043929. It was supposed to fix command execution for `MyLegacyNativeComponent` in RNTester on Android/Old Architecture.
At the same time it introduced a regression on iOS, since we have [different code path](https://www.internalfb.com/code/fbsource/[ffee789cab9514c0a15b8a63869cbfdf4e534a56]/xplat/js/react-native-github/packages/react-native/React/Modules/RCTUIManager.m?lines=1088-1092) for string commands in iOS, where we expect command name, and not command number converted to string.
I tried to remove that conversion, did local tests, and saw no issues with executing commands on Android.
Looks like the underlying issue has been fixed in some other way.
So let's just remove those conversions.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53123956
fbshipit-source-id: 968e35277e01215bd6fc1282c78f04666453317d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42811
changelog: [internal]
Attempt to fixing a crash in ReactViewGroup when removeClippedSubviews is enabled.
The implementation of removeClippedSubviews in ReactViewGroup is stateful and must be in sync between children of view and [member variables in ReactViewGroup](https://fburl.com/code/l22wewzc) that keep reference to all children. When it gets out of sync, it manifests itself as `java.lang.IndexOutOfBoundsException` crash.
The mounting layer counts on the fact that view hierarchy will never be directly mutated and all mutations will go through [ReactClippingViewManager](https://fburl.com/code/esl3vqhh). ReactClippingViewManager, if clipping is enabled, calls appropriate methods on ReactViewGroup to make sure member variables to manage clipping are in sync with view hierarchy.
This is true, except for a retry mechanism in SurfaceMountingManager. The retry mechanism tries to manually reconciliation the state with android view hierarchy. It bypasses ReactClippingViewManager in the process.
Reviewed By: javache, mdvacca
Differential Revision: D53348831
fbshipit-source-id: b6b190781a7c85ee4dfd7cb9bc74fd3a55466e45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42688
X-link: https://github.com/facebook/yoga/pull/1567
We are planning on overhauling NodeToString to output JSON instead of HTML for the purposes of better benchmarking and capturing trees in JSON format to benchmark later. This gives us a bit of a headache as we have to revise several build files to ensure this new library works, ensure that it is only included in certain debug builds, and deal with the benchmark <-> internal cross boundary that arises as the benchmark code (which is a separate binary) tries to interact with it.
On top of it all this is really not used at all.
The plan is to rip out this functionality and just put it in a separate binary that one can include if they really want to debug. That means that it cannot exist in the public API, so I am removing it here.
Private internals come next
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D53137544
fbshipit-source-id: 7571d243b914cd9bf09ac2418d9a1b86d1bee64a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42828
Updates to toJSON:
- return object tree instead of formatted snapshot string. Applying the `'react.test.json'` symbol lets Jest do the formatting work for us
- Source props from `pendingProps` on `instanceHandle`. This adds props such as `pointerEvents` and `style` which were present on RTR's snapshots but don't get included in the node's `props` collection
- Render text node as text value, instead of RCTRawText like `<RCTRawText text="Hello" />`
Changelog: [internal]
Reviewed By: kassens
Differential Revision: D53321821
fbshipit-source-id: 033637b9152441c318c9c797aa9223ff15768873
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42827
This is a simple snapshot test using ReactTestRender's toJSON. We have almost the same functionality in RNTR already, so let's see if we can support tests like this.
Merging the new setup and environment with the existing configuration (https://fburl.com/code/s85sma77) still causes issues so here we add unmocking and new setup inline. Added task T177114228 to track following up on this
Note that some formatting is changed and props are dropped on the snapshot. This is resolved with refactor in next diff
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D53321823
fbshipit-source-id: a20f77c29fefb9172f8a8189bd821dd202b2ff02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42826
yungsters debugged the failing test library import and found that we don't yet support package exports. Switching this to main with an index file allows us to import the library in other places.
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D53240712
fbshipit-source-id: 046a7d1678cbca181e4a4de607a9c0e7490ef047
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42790
A tiny bit of refactoring to unify the setup
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53313332
fbshipit-source-id: 4642f7d1dee8adf821b06c2ed25be09fd5dce098
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42747
Changelog: [Internal]
Implements a `RuntimeAgent` (D51231326) for Hermes for the modern CDP backend, based on the `CDPHandler` API that Hermes exposes currently.
## A note on `console`
We unfortunately have to disable `console` interception (D51234334 / equivalently D52971652) because `CDPHandler`'s current implementation is not aligned with the Agent concept:
* Agents are only created once a session has started, but the `console` interceptor needs to be injected at VM startup.
* Agents should not clobber each other's shared state (nor consume excessive resources per Agent), but each `CDPHandler` would install its own independent `console` interceptor if enabled.
We will enable CDP `console` support in the modern backend in future work. This will require either some additional plumbing in RN (e.g. to safely access JSI from an Agent/Target) or some additional work in Hermes.
## Conditional compilation based on `HERMES_ENABLE_DEBUGGER`
`HermesRuntimeAgent.cpp` compiles both with and without `-DHERMES_ENABLE_DEBUGGER`, which is the flag Hermes uses to control the availability of `CDPHandler` (and its containing Buck library).
If the debugger is not enabled, `HermesRuntimeAgent` reduces to a `FallbackRuntimeAgent`. In either case, no Hermes debugger headers leak into `HermesRuntimeAgent.h`, so callers don't need to check `#ifdef HERMES_ENABLE_DEBUGGER`, and the overall CDP backend infra is not gated on whether the Hermes debugger is compiled in.
Reviewed By: huntie
Differential Revision: D51234333
fbshipit-source-id: ccbca443560308c5edba4b9689501d01059fdd94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42725
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53200097
fbshipit-source-id: dad54f5bf03967b5d4126757ab0d5424534af888
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42723
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53200099
fbshipit-source-id: a5b244da401fb23c9579728c7261312ab200d623
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42724
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53200100
fbshipit-source-id: e6355af332c601e0d61e698d2fa0506c6a293989
Summary:
This PR removes the TypeScript entry for `UIManager.takeSnapshot()`. This function does not appear to be implemented anywhere, and calling it throws `TypeError: _reactNative.UIManager.takeSnapshot is not a function (it is undefined)`.
I think this functionality is still supported by [react-native-view-shot](https://github.com/gre/react-native-view-shot) for anyone who needs it!
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Removed] - Removed type definition `UIManager.takeSnapshot()`
Pull Request resolved: https://github.com/facebook/react-native/pull/42779
Test Plan: Ran TypeScript checks.
Reviewed By: cipolleschi
Differential Revision: D53307137
Pulled By: NickGerleman
fbshipit-source-id: 2e65c58c77bcde4f36f5065295d15757c519239d
Summary:
The previous typing of FlatList and VirtualizedList did not convey any information on the type of the items passed in to `onViewableItemsChanged`, but instead the type was set to `any`. This PR adds the type information.
I set a default type `any` for thy ViewToken, because the type is exported and not having it would be a breaking change if that type is used. Like this it gracefully falls back to the default behavior of the `any` type.
Notice: I don't know how typing in "flow" works, but the same "issue" seems to be in there as well. Maybe someone with more flow experience can fix that as well:
https://github.com/facebook/react-native/blob/ae42e0202de2c3db489caf63839fced7b52efc5d/packages/virtualized-lists/Lists/ViewabilityHelper.js#L19-L20
## Changelog:
[GENERAL] [FIXED] - Add type information for items of VirtualizedList in `onViewableItemsChanged` signature
[GENERAL] [FIXED] - Add type information for items of FlatList in `onViewableItemsChanged` signature
Pull Request resolved: https://github.com/facebook/react-native/pull/42773
Test Plan:
Without the changes, typecheck of the project was fine, but with the changes applied to the node_modules/react-native copy a type error was found:
```
$ npm run typecheck
> my-project@1.0.0 typecheck
> tsc --skipLibCheck
src/MyComponent.tsx:385:29 - error TS2345: Argument of type '(string | number)[]' is not assignable to parameter of type 'number[]'.
Type 'string | number' is not assignable to type 'number'.
Type 'string' is not assignable to type 'number'.
385 viewableItems
~~~~~~~~~~~~~
386 .filter(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Reviewed By: rozele
Differential Revision: D53276749
Pulled By: NickGerleman
fbshipit-source-id: 3fa5c65b388a59942c106286ac502a85c583da50
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42745
Changelog: [Internal]
Creates the `FallbackRuntimeAgent` class and uses it (as the name would suggest) as a fallback in cases where no other suitable `RuntimeAgent` implementation is available.
`FallbackRuntimeAgent`'s only feature is logging a message explaining that the runtime isn't debuggable. In the final product, users shouldn't get this far into launching the debugger if they're not using a compatible engine like Hermes, but this is a nice touch in case they do. (It's also useful for testing while we're working on landing the actual Hermes integration.)
Reviewed By: huntie
Differential Revision: D51449229
fbshipit-source-id: 3b3455a8b482b33bccbb6cc90083aad15052a3e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42746
Changelog: [Internal]
Formally introduces the concept of "session state" to the modern CDP backend, with the simplest possible implementation:
* `PageTargetSession` has a mutable `SessionState` member.
* All agents receive the same `SessionState&` in their constructor (with `SessionState`'s lifetime being the caller's responsibility).
* It's only legal to read/write to `SessionState` on the thread where requests are handled and Agents are created (the "main" thread).
* Agents are expected to play nice and not clobber each other's state in `SessionState`; this is *not* protected with visibility or `const`ness, however.
* We'll probably want to come up with some API-level mechanism to control this as the complexity of our agents grows.
## Current use case: `<Domain>.enable`
The first use case for session state is to let `PageAgent` manage the `Log.enable` and `Runtime.enable` state for the session. This will allow agents created later in the session (or recreated as part of a reload) to emit Log and Runtime notifications without waiting for additional `enable` messages (that the client is not required to send).
We'll likely want to generalise this design to arbitrary domains in some way (e.g. add a top-level domain router that agents register with explicitly?) but I went with the simplest implementation for our current needs.
NOTE: The CDP spec doesn't state this explicitly, but it's clear from Chrome's behaviour that a `<Domain>.enable` command is intended to be session-scoped and survive reloads.
## Future use case: Instance/Runtime state persistence
The `<Domain>.enable` use case could have been solved with passing *immutable* state to Agents (`const SessionState&`). We make the state mutable in anticipation of `HermesRuntimeAgent` needing to store its own state in the session down the line, which we know is going to be needed in order for breakpoints to survive reloads.
Agents that never need to mutate state SHOULD only store this as a const reference.
Reviewed By: huntie
Differential Revision: D53006916
fbshipit-source-id: a0443c507294faa94efdf25b2f1670129774dc78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42635
Changelog: [Internal]
Adds a RuntimeAgent interface to the modern CDP backend, plus an `InstanceTargetDelegate::createRuntimeAgent()` method. This allows the RN integration to provide an engine-specific CDP implementation.
This diff includes all the plumbing in Bridge and Bridgeless to route `createRuntimeAgent()` calls to the right place - ending up at `JSExecutor::createRuntimeAgent()` and `JSIRuntimeHolder::createInspectorAgent` respectively - at which point we currently return `nullptr` to signify that JS debugging isn't supported.
## Next steps
In upcoming diffs we'll add concrete implementations of `RuntimeAgent`, and teach both Bridge and Bridgeless to create them as appropriate:
* `HermesRuntimeAgent` for Hermes
* `FallbackRuntimeAgent` for all other JS engines (JSI or not)
We'll also (likely) add assertions to ensure that any JSI runtime that reports itself as "inspectable" (a flag used to control some of the in-app debugging UI) comes with a non-default `createRuntimeAgent()` implementation. We avoid this for now to prevent crashing the modern backend on Hermes.
NOTE: Like the rest of the modern CDP backend, the `RuntimeAgent` API is 100% experimental and subject to change without notice. A *future* version of this API will allow out-of-tree JSI engines to integrate with the modern CDP backend. Either way, it is intended strictly for the use case of integrating with a JS engine, not for adding any other framework-level CDP functionality.
Reviewed By: huntie
Differential Revision: D51231326
fbshipit-source-id: 81e87c5134df73cc4aac0f9d5793a5236b5720d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42783
This change will fix the publishing of Nightlies for React Native with the right version
## Changelog:
[Internal] - Update the package.json of react native correctly.
Reviewed By: cortinico, huntie
Differential Revision: D53309082
fbshipit-source-id: 2fa4d4fdf4f984603c6b3d3690fa3c464ee6d030
Summary:
On latest `main`, RN Tester was crashing for me just after loading the JS bundle with `java.lang.UnsatisfiedLinkError: dlopen failed: library "libreactfeatureflagsjni.so" not found`
It seems to be named `featureflagsjni` instead in [here](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/jni/react/featureflags/CMakeLists.txt#L11)
## Changelog:
No changelog needed
Pull Request resolved: https://github.com/facebook/react-native/pull/42770
Test Plan:
```bash
./gradlew :packages:rn-tester:android:app:installHermesDebug -PreactNativeArchitectures=arm64-v8a
```
Then run the app, the app was crashing before the fix, not crashing now
Reviewed By: javache
Differential Revision: D53268873
Pulled By: cortinico
fbshipit-source-id: f098ca12baadab358f72b1c9d5720123248b8e1a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42774
Reorganise release scripts so that command entry points are grouped based on execution context, which also reflects dependencies between scripts.
Also:
- Document the current behaviours of these scripts.
- Relocate utils out of the root contents.
- Replace `exec` call to `set-rn-version` script with function import.
NOTE: `yarn trigger-react-native-release` (documented command in release process) is unchanged, since this is aliased from `package.json`.
```
├── releases
│ ├── templates/
│ ├── utils/
│ ├── remove-new-arch-flags.js
│ ├── set-rn-version.js
│ └── update-template-package.js
├── releases-ci
│ ├── prepare-package-for-release.js
│ └── publish-npm.js
└── releases-local
└── trigger-react-native-release.js
```
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53274341
fbshipit-source-id: eec2befc43e7a47fd821b2e2bcc818ddffbb6cf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42781
Change in [31cf4c4ead](https://github.com/facebook/react-native/commit/31cf4c4eada59bde62f30e14024719779fc23a91) broke the template for bridgeless as we changed the signature of a method in the header of `RCTAppDelegate`.
This change aligns the API between RCTAppDelegate and the template's AppDelegate
## Changelog:
[iOS][Fixed] - Align the the bundleURL API from `RCTAppDelegate` to template's `AppDelegate`
Reviewed By: cortinico, dmytrorykun
Differential Revision: D53274434
fbshipit-source-id: 25bad702ba05db2e3a6a9449abbda7d8e2fdb8a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42771
This feature was first introduced here https://github.com/facebook/react-native/pull/34580
And then removed here https://github.com/facebook/react-native/pull/41654
The motivation for its removing was that Node resolver should handle all those cases for which `react-native.config.js` was used. But it turns out that it fails for the setup that `react-native-builder-bob` has.
This diff brings back support for defining external libraries in `react-native.config.js`.
Changelog: [iOS][Fixed] - Bring back support for defining external libraries in react-native.config.js
Reviewed By: cipolleschi
Differential Revision: D53267857
fbshipit-source-id: 7625dfe7b4a4651eb60eaec725f94f222a244e30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42777
During view preallocation eventEmitter information is not being passed to the platform. This causes bugs with emision of events during initial rendering when using the new Fabric Event dispatching system.
e.g. Rendering a TextInput that has 'onFocus' event and also has autoFocus enabled.
The new Fabric Event dispatching system dispatch events earlier (this is expected)
In this diff I'm fixing this issue by ensuring that all preallocated views have an eventEmitter (when its shadowNode has an eventEmitter)
This was actually implemented in the past, but in order to optimize, we run an experiment (D29117957) and it was later deleted.
(D40356386). I didn't find details of the results of the experiment.
We could run another experiment to understand potential negative perf impact of this change, although I believe it's the right thing to do here.
Changelog: [Android][Fixed] Fix delivery of events during initial rendering in new architecture
Reviewed By: sammy-SC
Differential Revision: D53108114
fbshipit-source-id: 0b56b7495db63e4a478f4b34e91f4bcbf452ef92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42748
React Native has globally enabled RTTI within `rn_xplat_cxx_library`, ahead of RTTI being forced on (regardless of flag) in Android apps (it was previously enabled everywhere but Android, which has caused us no small share of headaches, with public JSI APIs designed around clients using RTTI).
This diff:
1. Mechanically replaces usages of `traitCast` with equivalent calls to `dynamic_cast` or `dynamic_pointer_cast`
1. These have similar semantics as current iteration of `traitCast`, where we return `nullptr` for pointer form, or throw on invalid cast for reference form.
2. Removes `IdentifierTrait` as a requirement to cast to a ShadowNode
3. Removes the ShadowNode traits used solely as cast identities
This enables consistent usage of `dynamic_cast` (including for user defined ShadowNodes), and also exposes some places where `traitCast` allowed implicit const conversion.
The OSS builds should already have RTTI on, and will be able to use `dynamic_cast` on RN provided types (`traitCast` is not extendable).
Changelog:
[General][Breaking] - Delete traitCast and identifier traits
Reviewed By: sammy-SC
Differential Revision: D53215009
fbshipit-source-id: d20cbf66b725f5565fa5d03332010d87f2b08b61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42721
If left and right are swapped, this code assumes every yoga layoutable shadownode is a view, and mutates its props as if they were ViewProps. This is not safe, and could lead to memory corruption.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D53213652
fbshipit-source-id: c43e0f80fdd5889761317c1243ccc0ab392e3443
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42719
The task T175989432 started firing on October 30 2020, which correspond to the landing of D24512203. I believe disabling CustomDrawOrder could be a potential cause of T175989432, that's why in this diff I'm creating an experiment to understand what is the impact (negative or positive) of re-enabling CustomDrawOrder in RN Android
Original diff: D24512203
Changelog: [Internal] internal
Reviewed By: javache
Differential Revision: D53150292
fbshipit-source-id: f0abbc7d175c2cd717ce87bbe69aeaf3db0b0e5c
Rubén Norte
Tommy Nguyen
Rob Hogan
Samuel Susla
Pieter De Baets
Oskar Kwaśniewski
Dmitry Rykun
Ramanpreet Nara
Joe Vilches
Alex Taylor (alta)
Jack Pope
Christoph Purrer
Moti Zilberman
David Vacca
Fabrizio Bertoglio
Fabrizio Cucci
Pieter De Baets
Max Phillips
Michael Lohmann
Nicola Corti
Wojciech Dróżdż
zhongwuzw
Riccardo Cipolleschi
almouro
Alex Hunt
Nick Gerleman
