Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43035
Changelog: [Internal] - We early-exited because of poor copy-pasta and the fact that our tests don't properly emulate the behavior of mock `exit`
Will try and clean this up in next diff but want to quickly fix so it unbreaks nightlies
Reviewed By: yungsters
Differential Revision: D53779109
fbshipit-source-id: ff56e498344fcb4851729d98625b6c7010c73795
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43027
Changelog: [Internal]
Adds a test suite for the integration between the modern RN CDP backend and Hermes (plus potentially other JS engines), mocking out the rest of RN.
For simplicity, everything is single-threaded and "async" work is actually done through a queued immediate executor ( = run immediately and finish all queued sub-tasks before returning).
The main limitation of the simpler threading model is that we can't cover breakpoints etc - since pausing during JS execution would prevent the test from making progress. Such functionality is better suited for a full RN+CDP integration test (using RN's own thread management) as well as for each engine's unit tests.
## Types of tests in this diff
* `TEST_F(JsiIntegrationHermesTest, ...)` - tests specific to the Hermes integration.
* `TYPED_TEST(JsiIntegrationPortableTest, ...)` - tests that should pass on all engines.
* These use gtest's [typed tests](https://google.github.io/googletest/advanced.html#typed-tests) feature.
* This is a good fit for testing CDP features that have no strict dependency on Hermes (like the upcoming `Runtime.addBinding` support). **Long term**, aspirationally, all tests should be in this category, covering a consistent baseline of CDP features needed for debugging with any supported engine.
* The first "non-Hermes" engine we test against (`GenericEngineAdapter`) is actually Hermes in disguise, minus any Hermes-specific CDP handling. We could conceivably add more engines here, as long as we have the ability to build them (and their JSI bindings) as part of building the tests.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D53756996
fbshipit-source-id: fbafb088abd4263ec841bf848185637ec126c6d1
Summary:
Changelog: [Internal]
Update tests to be more resilient against prod changes; and make it easier to read the actual vs expected values upon failure.
Reviewed By: motiz88
Differential Revision: D53762409
fbshipit-source-id: d627d5041295f645ed00aa5d0645419a9ac4a7f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42687
Changelog: [Internal]
adding an example for if you want to use `getInitialNotification`.
Reviewed By: ingridwang
Differential Revision: D52931618
fbshipit-source-id: 7552c358e5bc98228b7ae74ea1adf450f7b075e6
Summary:
Changelog: [Internal]
I'm updating this API to match the semantics of the other new APIs, namely that they're static methods that don't depend on the instance of the native module. This should help streamline our documentation. Instead of capturing the launch notification as an ivar, we capture it in a static variable that we clear out when the object gets cleared or is invalidated, which is similar to an ivar / property.
Reviewed By: ingridwang
Differential Revision: D53743761
fbshipit-source-id: b6ff048ef8d653e8f4be19194a2211792a542252
Summary:
Changelog: [Internal]
In the past, local notifications were stored in the launch options as UILocalNotification, whereas remote notifications were stored as NSDict. This means that we had different handling in PushNotificationIOS.js. This condition was not handling the differences in local and remote notifications that JS expected, which I'm fixing here.
Reviewed By: ingridwang
Differential Revision: D53734086
fbshipit-source-id: 73ef436a232c16de3b72f7236db94012aafdc434
Summary:
Changelog: [Internal]
Required for landing D53543159.
2 reasons for landing this:
1. Inspector is technically deprecated and will be removed once React DevTools are shipped with Chrome DevTools for RN debugging.
2. Long-term solution for source fetching is lazy loading based on component stacks - https://github.com/facebook/react/pull/28265
Reviewed By: kassens
Differential Revision: D53757524
fbshipit-source-id: cbb2aab79ba40ea66da5c1ddde95d3fe374b6006
Summary:
Changelog: [Internal]
Replaces the copypasta'd `PageTarget::forEachSession`, `InstanceTarget::forEachAgent` and `RuntimeTarget::forEachAgent` with a shared utility class for managing a list of `weak_ptr`s.
In a `WeakList`, elements can only be added (`insert`), iterated over (`forEach`), and counted (`size`, `empty`). Conceptually, elements are automatically removed from the list as soon as they're destroyed, but internally, space is reclaimed *lazily*: the next time we have a reason to iterate over the underlying list, we delete any pointers that are found to be null.
## Naming
This is almost a WeakSet, but we don't bother checking for duplicates, hence "WeakList".
Reviewed By: hoxyq
Differential Revision: D53671483
fbshipit-source-id: 460bfbaa2b8e821281dc352fed0946f99352c9fc
Summary:
Changelog: [Internal]
# This diff
1. Provides all Targets with an `executorFromThis()` method, which can be used from within a Target to access a *`this`-scoped main thread executor* = a `std::function` that will execute a callback asynchronously iff the current Target isn't destroyed first.
2. Refactors how (all) Target objects are constructed and retained, from a plain constructor to `static shared_ptr create()`. This is because `executorFromThis()` relies internally on `enable_shared_from_this` plus two-phase construction to populate the executor.
3. Creates utilities for deriving scoped executors from other executors and `shared_ptr`s.
The concept is very much like `RuntimeExecutor` in reverse: the #1 use case is moving from the JS thread back to the main thread - where "main thread" is defined loosely as "anywhere it's legal to call methods on Target/Agent objects, access session state, etc". The actual dispatching mechanism is left up to the owner of each `PageTarget` object; for now we only have an iOS integration, where we use `RCTExecuteOnMainQueue`.
Coupling the ownership/lifetime semantics with task scheduling is helpful, because it avoids the footgun of accidentally/nondeterministically moving `shared_ptr`s (and destructors!) to a different thread/queue .
# This stack
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack:
* ~~Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`. ~~
* ~~Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`). ~~
* ~~Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`.~~
* ~~Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`.~~
* ~~Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.~~
* Provide RuntimeTarget with mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event. *← This diff*
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: hoxyq
Differential Revision: D53356953
fbshipit-source-id: 152c784eb64e9b217fc2966743b33f61bd8fd97e
Summary:
Changelog: [Internal]
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack will:
* ~~Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`. ~~
* ~~Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`). ~~
* ~~Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`.~~
* ~~Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`.~~
* Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread. *← This diff*
* We'll likely develop a similar mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event.
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: hoxyq
Differential Revision: D53266710
fbshipit-source-id: df3a181fcc8e033c37a7f4f430f23a29b326b56a
Summary:
Changelog: [Internal]
Fixed double-encoding for the websocket url.
`URLSearchParams` already encode the values, passing a pre-encoded `encodeUriComponent` string will cause it to double-encode, making the value unreadable when decoding once.
Missed these lines while splitting the initial diff stack.
Added tests now.
Reviewed By: motiz88
Differential Revision: D53721568
fbshipit-source-id: cfaaa7eb50c40364c904e9ffc5698201df8ab22b
Summary:
Changelog: [Internal]
Applies to RuntimeTarget → RuntimeAgent the same pattern we use for InstanceTarget → InstanceAgent (D53266708) and PageTarget → PageTargetSession: the target has `weak_ptr`s to its agents/sessions so it can (1) dispatch events to them and (2) assert that they are destroyed before the target itself is destroyed.
In RuntimeTarget this will primarily serve as an event dispatching mechanism from JS (single target) to CDP (multiple sessions), with the addition of threading abstractions in upcoming diffs.
Reviewed By: hoxyq
Differential Revision: D53266706
fbshipit-source-id: 64d7226a1aebf00e0ad178f28101a568e9bc6c53
Summary:
This is a resubmission of D53266707 with a fix in the OSS version of `HermesExecutorFactory` (it was incorrectly referencing `HermesRuntimeAgent.h` which doesn't exist anymore). The original diff summary follows.
---
Changelog: [Internal]
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack will:
* ~~Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`.~~ (D53233914)
* ~~Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`).~~ (D53233914)
* Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`. *← This diff*
* Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`. *← Also in this diff*
* Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.
* We'll likely develop a similar mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event.
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: EdmondChuiHW
Differential Revision: D53748590
fbshipit-source-id: bd0cf9f74b95abc52b4903f8a7afddcefa303d8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42769
Changelog: [internal]
These APIs are not currently enabled in OSS, so moving the modules should be safe and not considered a breaking change.
Reviewed By: NickGerleman
Differential Revision: D53267565
fbshipit-source-id: edd3daa7c5043e44e5fd4b1af074093ed3ef4152
Summary:
The `.addUIBlock` and `.prependUIBlock` APIs on UiManagerModule are missing on Fabric.
Here I'm re-implementing them to make migration to Fabric easier.
Set of changes:
- Moved `NativeViewHierarchyManager` to `NativeViewHierarchyManagerImpl` and extracted an interface
- Moved `addUIBlock` and `prependUIBlock` to the shared `UIManager` interface
- Added a `InteropUIBlockListener` class that takes care of executing the UI Blocks, implemented as a `UIManagerListener`
Changelog:
[Android] [Changed] - Changed the API of addUIBlock and prependUIBlock to implement it also in Fabric.
Reviewed By: mdvacca
Differential Revision: D53612514
fbshipit-source-id: 1cddbc391477318064f15c733a380983c3737373
Summary:
Removes the OSS build logic I added in D53377527, to turn Android build green (target not yet used outside tests).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D53746020
fbshipit-source-id: 6e8a8e111a307b955b838c0522d3d0802e3865c3
Summary:
This one snuck in with new OSS buid failures after when we had another change cause a failure. Back it out, to get CI passing.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D53745683
fbshipit-source-id: f889bf7541e6f664053d5c0e4851cb448cdbb615
Summary:
Adds a sparse `CSSDeclaredStyle` structure to represent the collection of declarations from the user, before being further processed/computed. This will later be procssed into computed style.
Also fixes up some bad naming wrt specified value and declared value.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53696422
fbshipit-source-id: 4258c86a29a0b2251c969b299b5b4703c06696db
Summary:
I originally marked most of this as constexpr, since the code around the variant, and parsing, were already header only and avoiding allocations, and was pretty leaf node.
`reinterpret_cast` and similar is not allowed under constexpr until C++ 26, which `CSSValue` was using. We change our method of storage to a recursively defined union, which is the same underlying implementation of `std::variant` (and is how it is constexpr).
`std::pow` is also not constexpr until C++ 26 which means we can't assign a CSSValue which tokenizes a decimal number... But... constexpr here is more a bonus, and not worth pulling in constexpr math library to do it.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53696265
fbshipit-source-id: 01442ab9222b3f3ef8ccb01383648fb2e1f747dd
Summary: Didn't have a test for this before. Add one.
Reviewed By: joevilches
Differential Revision: D53537840
fbshipit-source-id: 30872e2dd5b4c35eab7ee66b6f6f322ff0b7735c
Summary:
1. Add "initial" values, and whether the prop should be inherited (currently only applies to direction).
2. Add some more border properties that we can replicate with the current data types we support, that are part of valid CSS. These are in ViewProps today instead of YogaStylableProps, but style computation can read both at once.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D53537101
fbshipit-source-id: cce926ba0caba0467493611e3000d1ba396de19e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42913
This structures properties into a `CSSProp` enum (so that we can have a runtime-key per style prop), associated with a `CSSPropDefinition` structure which groups the supported types and keywords. This has some niceness of removing the macro bits, but more importantly, means we can query parse related information without a field of the value yet existing (need for sparse storage of CSS values). In the future, it will serve as where we define "initial" values, and likely, the processes for interpolation and inheritance.
We restructure `CSSValueVariant` to not always support keywords, as it may not be a valid possibility for computed values (which do not have CSS wide keywords). Computed values themselves may also reduce more keywords than the global ones (e.g. border width computed value absolutizes keywords).
We also flesh out more of the prop definitions, and parsing. All the properties here relay back to YogaStylableProps of today, but I intentionally filled out the prop definitions a bit more than we do anything with right now (will design higher level to ignore unknown props).
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D53518450
fbshipit-source-id: 1b48ae2513a258d15c5e7fd16ef06f1b6be8dab2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42879
Adds support for parsing and storing a component value of the <ratio> CSS basic data type. This would allow removing `processAspectRatio` from viewconfigs later, which we would need for correct substitution of functions/expressions resulting in the ratio numerator/denominator.
This also fleshes out the parser a bit more, and does some renaming, and convention setting.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D53457930
fbshipit-source-id: bed79e05978ed4152c865cdf90701dea779c8622
Summary:
This adds:
1. `CSSValueVariant`: A union-y type, mapping to a collection of CSS basic data types, and a set of allowed keywords. The aim here is to more closely model the data types after the CSS spec, to allow RN to store them correctly, while not taking up too much space. These types will form the foundation of Yoga prop storage (and probably some other props down the line), so compactness is a priority.
2. `parseCSSValue()`: This uses the previously added Tokenizer, along with parsing rules, to be able to parse a single component value, into a literal keyword, `<length>`, `<length-percentage>`, `<percentage>`, or `<number>`. This will be wired to the props parsing infrastructure.
See D53461299 for an example of what this will look like in props storage.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D53342595
fbshipit-source-id: 3f00dfd7c0ead3dbef4605a61e9859cf69945fe5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42832
Various analogs to CSS types and utilities currently exist between `core` and `components/view`. These don't really belong well with either, so this adds a top-level "css" library, and moves `CSSTokenizer` there.
This is statically linked into Fabric binary on Android OSS.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D53377527
fbshipit-source-id: e2d3091ecb3533ecde4d0a08084369b4909532c3
Summary:
Changelog: [Internal]
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack will:
* ~~Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`.~~ (D53233914)
* ~~Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`).~~ (D53233914)
* Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`. *← This diff*
* Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`. *← Also in this diff*
* Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.
* We'll likely develop a similar mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event.
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: hoxyq
Differential Revision: D53266707
fbshipit-source-id: e14867931d10e1739e6dab6dbd7d3386c685c3c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42432
Changelog: [internal]
This feature flag is accessed through `CoreFeatures` but it's initialized a few different ways:
* Android: assigned via `ReactFeatureFlags`, which is overridden by apps.
* iOS: `ReactNativeConfig` that's mapped to a dynamic configuration.
This migrates the flag to the new feature flag system.
Reviewed By: mdvacca, RSNara
Differential Revision: D52810065
fbshipit-source-id: d6fd1e819abbc4c3dee9e6221d8f99384f5197f5
Summary:
Changelog: [Internal] - `get-and-update-packages` was deleted in D53487874 also actually published the monorepo packages.
Update publish-npm to publish the updated nightly monorepo packages
Reviewed By: cipolleschi
Differential Revision: D53697621
fbshipit-source-id: 21facb49739ba64c43b921117356715be3d8868a
Summary:
Autolinking local app fabric component requires user to manipulate the C++ code.
This removes this requirement by generating the code necessary to register all the discovered Fabric Components.
I've updated the RN-Tester Android setup to use this mechanism also.
Changelog:
[Android] [Fixed] - Fix autolinking for local app Fabric components
Reviewed By: cipolleschi
Differential Revision: D53710676
fbshipit-source-id: 667af4bcf7fa99563081330aa64d072faf50863b
Summary:
The recent change to make onDismiss work on Fabric broke the Modal on Paper (see [this comment](https://www.internalfb.com/diff/D52959996?dst_version_fbid=236415652884499&transaction_fbid=896066412296150)).
This change will fix that behavior.
The problem was that we were resetting the `isRendered` state only when the Modal receives the event from the Event emitter AND if it has the `onDismiss` callback set.
However, we should hide the component in any case if the ids match, and invoke the onDismiss if it is set.
## Changelog
[iOS][Fixed] - Make sure that Modal is dismissed correctly in Paper
Reviewed By: janeli-100005636499545
Differential Revision: D53686165
fbshipit-source-id: a1de0b29dca7c099e9fa0282ec80cae9a8fd6bc3
Summary:
RNGP now supports parsing the cxxModule field in codegenConfig and passes it over to codegen.
Changelog:
[Internal] [Changed] - Update RNGP to handle cxxModule in codegenConfig
Reviewed By: cipolleschi
Differential Revision: D53669912
fbshipit-source-id: 702f09ccf793f9205f0c8b54346c5d809695c35d
Summary:
This introduces the `cxxModule` field for RNTester where the local TM-CXX modules
are specified.
Changelog:
[Internal] [Changed] - Add cxxModule to RN-Tester's codegenConfig
Reviewed By: cipolleschi
Differential Revision: D53669913
fbshipit-source-id: 97b9985b94efe79566d2d06f6081e65fb66478ff
Summary:
Changelog: [Internal]
`getInitialNotification` only expect the user info dictionary of the dictionary, not the complete formatted notification.
Reviewed By: cipolleschi
Differential Revision: D53691569
fbshipit-source-id: 9a24629d2e50544c55ea5cd16097bd88dad950ec
Summary:
Changelog: [Internal]
In D53233914 we copied PageTarget's approach for keeping track of its sessions into InstanceTarget (for keeping track of InstanceAgents). Here we complete that pattern by asserting that the agents are destroyed before their respective targets.
NOTE: We might want to encapsulate this pattern in a helper/template class at some point. For now I'm going with the explicit approach.
Reviewed By: hoxyq
Differential Revision: D53266708
fbshipit-source-id: 4a90fde6c68e87d4667c44f81f8578a7a9072474
Summary:
Changelog: [Internal]
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack will:
* Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`. *← This diff*
* Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`). *← Also in this diff*
* Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`.
* Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`.
* Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.
* We'll likely develop a similar mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event.
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: hoxyq
Differential Revision: D53233914
fbshipit-source-id: 166ae3e25059bd9c9c051a0a3312a3ba78a3935a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42923
This Diff implement the logic to:
- Read some lists of class names provided by libraries that conforms to some protocols we defined as extension points.
- Generate a provider in the React-Codegen podspec, whose code lives alongside the app code.
- Glue the app and the generated code together, allowing to link custom protocols
## Changelog
[iOS][Added] - Allow libraries to provide module which conforms to protocols meant to be extension points.
Reviewed By: RSNara
Differential Revision: D53441411
fbshipit-source-id: f53bc6ea0417e6122d8918df2614bcb9937a515a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42962
Autolinking local app fabric component requires user to manipulate the C++ code.
This removes this requirement by generating the code necessary to register all the discovered Fabric Components.
I've updated the RN-Tester Android setup to use this mechanism also.
Changelog:
[Android] [Fixed] - Fix autolinking for local app Fabric components
Reviewed By: RSNara
Differential Revision: D53661231
fbshipit-source-id: 28c376fbd08c326f117f8d420485d63e2b4b1241
Summary:
Those files are stale from Buck OSS. I'm removing them.
I'm also updating the RN-Tester instructions to be up-to-date.
## Changelog:
[INTERNAL] - Cleanup BUCK artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/42990
Test Plan: Nothing to test
Reviewed By: NickGerleman
Differential Revision: D53705337
Pulled By: cortinico
fbshipit-source-id: 685fc346870c5f123660cb5af2e30fb64842127a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42812
There is a way of defining events where you specify additional string type parameter in the EventHandler in the spec. This additional type parameter is an overridden top level event name, that can be completely unrelated to the event handler name.
More context here D16042065.
Let's say we have
```
onLegacyStyleEvent?: ?BubblingEventHandler<LegacyStyleEvent, 'alternativeLegacyName'>
```
This will produce the following entry in the view config:
```
topAlternativeLegacyName: {
phasedRegistrationNames: {
captured: 'onLegacyStyleEventCapture',
bubbled: 'onLegacyStyleEvent'
}
}
```
This means that React expects `topAlternativeLegacyName`.
But the generated EventEmitter looks like this:
```
void RNTMyNativeViewEventEmitter::onLegacyStyleEvent(OnLegacyStyleEvent $event) const {
dispatchEvent("legacyStyleEvent", [$event=std::move($event)](jsi::Runtime &runtime) {
auto $payload = jsi::Object(runtime);
$payload.setProperty(runtime, "string", $event.string);
return $payload;
});
}
```
The native component will emit `legacyStyleEvent` (`topLegacyStyleEvent` after normalization) that React will not be able to handle.
This issue only happens on iOS because Android doesn't use EventEmitter currently.
To address this issue we'll use `paperTopLevelNameDeprecated` for the generated EventEmitters if it is defined.
Changelog: [iOS][Fixed] - Fixed support for event name override in component specs.
Reviewed By: cortinico, mdvacca, cipolleschi
Differential Revision: D53310654
fbshipit-source-id: 018d5b11d8d36e2ecf900b9d8d6fe3e2ed71f80b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42809
This diff adds a legacy style event to `MyNativeViewNativeComponent`.
This is a way of defining events where you specify additional string type parameter in the EventHandler in the spec. This additional type parameter is an overridden top level event name, that can be completely unrelated to the event handler name.
In this example it is `onLegacyStyleEvent` and `alternativeLegacyName`.
More context here D16042065.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53310318
fbshipit-source-id: 4dec08c872acdfd09b9939f690fb7bc777149580
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42665
- Replace the internals of `InspectorFlags` to use the new `ReactNativeFeatureFlags` setup.
- Remove call sites to `InspectorFlags::initFromConfig`.
After this diff, all `InspectorFlags` are configured from `ReactNativeFeatureFlags.json`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D53049790
fbshipit-source-id: 90c2b128a9c316546c3f8f8f88e2c08a9f55ae72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42642
Removes call to `InspectorFlags::initFromConfig`, since this approach is being replaced with `ReactNativeFeatureFlags`. This change is separated out as it originally made a public API deprecation.
Changelog:
[iOS][Deprecated] - **Un-deprecates** `RCTAppSetupPrepareApp` (reverts #41976)
Reviewed By: motiz88
Differential Revision: D53048207
fbshipit-source-id: 8624020f1e9e19f9f1ee75af9b177e922e36c5d9
Luna Wei
Moti Zilberman
Edmond Chui
Phillip Pan
Ruslan Lesiutin
Samuel Susla
Rubén Norte
Alex Hunt
Nicola Corti
David Vacca
Nick Gerleman
Riccardo Cipolleschi
Dmitry Rykun