Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43065
Changelog: [Internal]
Implements support for [`Runtime.addBinding`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#method-addBinding) in the new RN CDP backend.
This implementation is mostly complete and matches Chrome's behaviour, but does not include the ability to target bindings by execution context (the optional `executionContextId` and `executionContextName` params) - that will come in a separate diff for ease of review/landing.
Incidentally, this diff also introduces the `JsiIntegrationPortableTest::expectMessageFromPage` helper, which allows us to "asynchronously" extract the contents of an expected message. For consistency and clarity, we refactor all the other `EXPECT_CALL(this->fromPage(), onMessage(JsonEq(...)))` assertions to use it as well.
Reviewed By: huntie
Differential Revision: D53266709
fbshipit-source-id: 046326acdf5dacc18e179e43589cdd2d012f353a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43064
Changelog: [Internal]
Aligns React Native's CDP backend with V8's behaviour of assigning a sequential ID (here unique within a given PageTarget) to each execution context.
Reviewed By: huntie
Differential Revision: D53776531
fbshipit-source-id: 950599c323f416e8180e42281d94ae9c00f15fb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43063
Changelog: [Internal]
Moves the responsibility for managing CDP execution contexts out of the Runtime and into the Instance.
This includes the responsibilities to:
1. Assign execution context IDs/names
2. Emit events when execution contexts are created/destroyed
3. Route CDP messages to the correct Runtime
**Re 1:** We currently assign a *constant* execution context ID, which diverges from V8's implementation but is in line with what Hermes has done so far. I'll follow up separately to assign (locally) unique IDs, since this diff is long enough already.
**Re 3:** Right now, the message routing responsibility is mostly theoretical: only one Runtime exists at a time and "routing" can be done by RuntimeAgent simply deciding whether or not to act on a message (since it receives all messages by default and knows its own `ExecutionContextDescription`). True multi-Runtime / multi-context support is firmly a future concern, and we can revisit this ( = probably hoist more logic into Instance) when we get there.
In the `ExecutionContextNotifications` integration test we can see that a few minor bugs in the current Hermes-based implementation are fixed, and also that execution context management is now engine-agnostic (so we can use `JsiIntegrationPortableTest` instead of `JsiIntegrationHermesTest`).
Reviewed By: huntie
Differential Revision: D53759776
fbshipit-source-id: 50ac126789c95b25f845780df2c3346ec345d5d5
Summary:
While looking at another issue, I realized that in some cases the script was adding the same flags twice and it was leaving the RCT_NEW_ARCH_ENABLED behind.
## Changelog:
[iOS][Fixed] - Pass the right flags to libraries
Pull Request resolved: https://github.com/facebook/react-native/pull/43071
Test Plan: Fixed Unit tests
Reviewed By: huntie
Differential Revision: D53860576
Pulled By: cipolleschi
fbshipit-source-id: 1f6f4852df8d316293b93d7c5fbef09a249893a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43060
When inestigating the reason why [`react-native-view-shot`]() ws not working, we realized that there are many libraries that follows this pattern:
```objc
[self.bridge.uiManager addUIBlock:^(RCTUIManager *uiManager, NSDictionary<NSNumber *, UIView *> *viewRegistry) {
if (UIView *view = viewRegistry[reactTag]) {
//do something with the View
}
}];
```
The problem is that, with the New Architecture, that view registry is usually empty, because the components are registered and tracked in another place.
This make many libraries stop working when used with the New Architecture.
This change introduces a class that behaves like a dictionary but that forward the calls to retrieve the view to the right place, in order to get the view that is needed.
Noticably, this approach allow us also to remove some shenanigans we were applying to make sure that the interop layer could access the views wrapped in it, so the current solution is more general and should work in multiple situations.
## Changelog
[iOS][Fixed] - Make sure that `addUIBlock` provides a Dictionary-look-alike object that returns the right views when queried.
Reviewed By: sammy-SC
Differential Revision: D53826203
fbshipit-source-id: 08d359676d69777b88fa9b18dc141187ac42dbce
Summary:
This is a preliminary change which converts RCTConvert to an objectiveC++ file. This is required by the next diffs in the stack.
## Changelog
[iOS][Changed] - Make RCTConvert an Objective-C++ (`.mm`) file in prep for DisplayP3 changes
Reviewed By: javache
Differential Revision: D53520228
fbshipit-source-id: cf45c42955401b4e14fe68221129077817b2598e
Summary:
This PR makes `__gitignore` file universal for Apple OOT platforms.
## Changelog:
[GENERAL] [CHANGED] - Make template's .gitignore file universal for OOT platforms
Pull Request resolved: https://github.com/facebook/react-native/pull/42963
Test Plan: CI Green
Reviewed By: NickGerleman
Differential Revision: D53674632
Pulled By: yungsters
fbshipit-source-id: cb510d9bd2ee6f1c39b77a842e7947b67def552a
Summary:
This PR fixes PerfMonitor option not showing on iOS when running bridgeless. The `initialize` method is not called in bridgeless which causes this option to not be added. I've converted this approach to work for both bridgeless and non-bridgeless.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Perf Monitor option not showing in Bridgeless
Pull Request resolved: https://github.com/facebook/react-native/pull/42891
Test Plan: Run RNTester, open Perf monitor
Reviewed By: RSNara
Differential Revision: D53518507
Pulled By: cipolleschi
fbshipit-source-id: c16d41006c5a3f96d53d4f76fd317941a1eb839f
Summary:
When analyzing the `hitTest:withEvent` function, I realized that we were not forwarding the touches to the legacy view.
The previous algorithm was returning the InteropLegacyWrapper view itself when the touches were happening in the legacy view, preventing the handlers attached to the legacy view to fire.
With this change, if the legacy view receives a touch, it can handle it.
## Changelog
[iOS][Fixed] - Make sure to forward touches to the wrapped component in the InteropLayer.
Reviewed By: sammy-SC
Differential Revision: D53806218
fbshipit-source-id: 87b0aa6e900935092e6f5e1533b871c1d224b718
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43018
Assuming that if View is a ViewGroup, its ViewManager is a ViewGroupManager is incorrect. Custom ViewManagers may use ViewGroups internally to represent complex views exposed to JS.
Type-check the ViewManager instead to avoid the crash seen in T178300877
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53586565
fbshipit-source-id: 49408098cebc7f76d8be0e585187ba9b6ca52049
Summary:
This was introduced to support MapBuffer-based view managers (D33735245), but that experiment has been removed from the codebase (D53072714).
This indirection is preventing a proper fix for a crash we're seeing with RemoveDeleteTree (T178300877)
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53586567
fbshipit-source-id: d391ca56b23fc3dd57429c5ad8a7a405e97a81f2
Summary:
Changelog: [Internal]
Fixes a small omission in D53756996 that will come into play in future diffs.
bypass-github-export-checks
Reviewed By: robhogan
Differential Revision: D53771004
fbshipit-source-id: 4c94db37ef51793420e126a81c5d6c0543493ec7
Summary:
Changelog: [Internal]
Along with all the places using it like the `_debugSource` on Fiber.
This still lets them be passed into `createElement` (and JSX dev
runtime) since those can still be used in existing already compiled code
and we don't want that to start spreading to DOM attributes.
We used to have a DEV mode that compiles the source location of JSX into
the compiled output. This was nice because we could get the actual call
site of the JSX (instead of just somewhere in the component). It had a
bunch of issues though:
- It only works with JSX.
- The way this source location is compiled is different in all the
pipelines along the way. It relies on this transform being first and the
source location we want to extract but it doesn't get preserved along
source maps and don't have a way to be connected to the source hosted by
the source maps. Ideally it should just use the mechanism other source
maps use.
- Since it's expensive it only works in DEV so if it's used for
component stacks it would vary between dev and prod.
- It only captures the callsite of the JSX and not the stack between the
component and that callsite. In the happy case it's in the component but
not always.
Instead, we have another zero-cost trick to extract the call site of
each component lazily only if it's needed. This ensures that component
stacks are the same in DEV and PROD. At the cost of worse line number
information.
The better way to get the JSX call site would be to get it from `new
Error()` or `console.createTask()` inside the JSX runtime which can
capture the whole stack in a consistent way with other source mappings.
We might explore that in the future.
This removes source location info from React DevTools and React Native
Inspector. The "jump to source code" feature or inspection can be made
lazy instead by invoking the lazy component stack frame generation. That
way it can be made to work in prod too. The filtering based on file path
is a bit trickier.
When redesigned this UI should ideally also account for more than one
stack frame.
With this change the DEV only Babel transforms are effectively
deprecated since they're not necessary for anything.
DiffTrain build for commit https://github.com/facebook/react/commit/37d901e2b81e12d40df7012c6f8681b8272d2555.
Reviewed By: kassens
Differential Revision: D53543159
Pulled By: tyao1
fbshipit-source-id: 8e5509a16ea8d3234881e2305149326fb31e3845
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43012
Changelog: [iOS][Added]
This implements the functionality to give access to the jsi::Runtime in iOS in bridgeless. In bridge, this value is a private selector on RCTBridge that is exposed via category. We build this into the backwards compatible RCTBridgeProxy here.
This should work out of the box in bridgeless if you are already retrieveing the pointer via the bridge. However, we recommend users to eventually migrate towards C++ TurboModule or the RuntimeExecutor if possible. This will be removed in the future.
Reviewed By: RSNara
Differential Revision: D53646413
fbshipit-source-id: a5584f22d433a580d537b8780a3bcd503680acb8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43013
Changelog: [Android][Added]
This is a pre-deprecated API to give access to the jsi::Runtime in Android in bridgeless. In bridge, this value is exposed via the ReactContext, but is not implemented in the BridgelessReactContext. We do that here.
This should work out of the box in bridgeless if you are already retrieveing the pointer via ReactContext. However, we recommend users to eventually migrate towards C++ TurboModule or the RuntimeExecutor if possible. This will be removed in the future.
Reviewed By: RSNara
Differential Revision: D53645247
fbshipit-source-id: b98657560c43a625bdf947d19d186952c9b44364
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
Ingrid Wang
Moti Zilberman
Riccardo Cipolleschi
Riccardo Cipolleschi
Nicola Corti
David Vacca
Oskar Kwaśniewski
Samuel Susla
Pieter De Baets
sebmarkbage
Phillip Pan
Zhengwei Liu
Thomas Nardone
Edmond Chui
Ruslan Lesiutin
Rubén Norte
Nick Gerleman