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/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 (https://github.com/facebook/react-native/commit/d3e836245b5fab2e0299dd06901de74dff767b63) 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:
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:
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:
changelog: [internal]
`useLayoutEffect` has two guarantees which React Native breaks:
- Layout metrics are ready.
- Updates triggered inside `useLayoutEffect` are applied before paint. State between first commit and update is not shown on the screen.
React Native breaks the first guarantee because it uses Background Executor. Background executor moves Yoga layout to another thread. If user core reads layout metrics in `useLayoutEffect` hook, it is a race. The information might be there, or it might not. They can even read partially update information. This diff does not affect this. We already have a way to turn off Background Executor. We haven't done this because it introduces regressions on one screen but we have a solution for that.
React Native breaks the second guarantee. After Fabric's commit phase, Fabric moves to mounting the changes right away. In this diff, we queue the mounting phase and give React a chance to change what is committed to the screen. To do that, we schedule a task with user blocking priority in `RuntimeScheduler`. React, if there is an update in `useLayoutEffect`, schedules a task in the scheduler with higher priority and stops the mounting phase.
We are not delaying mounting, this just gives React a chance to interrupt it.
Fabric commit phase may be triggered by different mechanisms. C++ state update, surface tear down, template update (not used atm), setNativeProps, to name a few. Fabric only needs to block paint if commit originates from React. Otherwise the scheduling is wrong and we will get into undefined behaviour land.
Rollout:
This change is gated behind `react_fabric:block_paint_for_use_layout_effect` and will be rolled out incrementally.
Reviewed By: javache
Differential Revision: D43083051
fbshipit-source-id: bb494cf56a11763e38dce7ba0093c4dafdd8bf43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36051
[Changelog][Internal]
This has been on my backlog for some time, submitting the diff to get it out of the way.
It makes the macro-based code in the "iterator-based property parsing" branch somewhat less horrible and less error prone (by removing duplication vs the default values in the class declaration).
Reviewed By: sammy-SC
Differential Revision: D42990595
fbshipit-source-id: e4b91160c6e09d3d1eab2ba70a58d390243bb335
Summary:
This PR implements logical border-radius as requested on https://github.com/facebook/react-native/issues/34425. This implementation includes the addition of the following style properties
- `borderEndEndRadius`, equivalent to `borderBottomEndRadius`.
- `borderEndStartRadius`, equivalent to `borderBottomStartRadius`.
- `borderStartEndRadius`, equivalent to `borderTopEndRadius`.
- `borderStartStartRadius`, equivalent to `borderTopStartRadius`.
## Changelog
[GENERAL] [ADDED] - Add logical border-radius implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/35572
Test Plan:
1. Open the RNTester app and navigate to the `RTLExample` page
2. Test the new style properties through the `Logical Border Radii Start/End` section
https://user-images.githubusercontent.com/11707729/206623732-6d542347-93f9-40da-be97-f7dcd5f66ca9.mov
Reviewed By: necolas
Differential Revision: D42002043
Pulled By: NickGerleman
fbshipit-source-id: a0aa9783c280398b437aeb7a00c6eb3f767657a5
Summary:
[Changelog][Internal]
The diff changes underlying storage types used by different enums that are used in ViewProps data structure, together with some eventual field rearranging to reduce padding overhead.
This **shaves off 128 bytes** from each `ViewProps` instance, which is **a ~10% improvement**.
Given that an average RN app may have thousands of shadow tree nodes, and correspondingly `ViewProps` instances in flight (e.g. Oculus Store has 2-3K of them nominally), the overall memory win is about **300K+** for this change only. Plus slightly better cache locality, which never a bad thing either.
Reviewed By: mdvacca
Differential Revision: D42372127
fbshipit-source-id: d3a832af2b2e89f50a5b8e04d24d0df92869ea4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35768
Changelog: [Internal]
This implements native side mechanics for reporting user events timing to JS (PerformanceObserver API).
See the standard for more details: https://www.w3.org/TR/event-timing/
The events are only logged when there are any active subscriptions (via `PerformanceObserver.observe`), also we only log "discrete events" (i.e. no likes of mouse move), so the overhead is non-existing.
There are two main metrics of interest for an event lifecycle:
* Time the event is spent in the queue, i.e. the time between it's created and dispatched
* Time that is spend in the event handler on the JS side (event dispatch), or processing time
Both of these are measured, and the corresponding fields are populated.
Reviewed By: sammy-SC
Differential Revision: D42294947
fbshipit-source-id: 4fd7938c04b942400befa4057d4929fb2763cee1
Summary:
changelog: [internal]
This is experimental implementation of `setNativeProps` in Fabric.
This diff brings `setNativeProps` to Fabric to make migration easier. I tried to stay as close as possible to Paper's behaviour, with all of its flaws (ready CAUTION section on https://reactnative.dev/docs/direct-manipulation)
State can't be stored in views because on iOS, eventually on Android, views are not the source of truth, shadow tree is. Fabric's implementation keeps state from setNativeProps in shadow node family in very inefficient data structure folly::dynamic. It is always reconciled with new prop updates. The performance cost is only paid in case node has used `setNativeProps` before.
Reviewed By: mdvacca
Differential Revision: D41875413
fbshipit-source-id: 453a5f7612a6f86a4cece269b13bd2ffd0c0e2d1
Summary:
changelog: Introduce setNativeProps to Fabric
Add support for `setNativeProps` in Fabric for backwards compatibility. It is still recommended to move away from `setNativeProps` because the API will not work with future features.
We can make step [Migrating off setNativeProps](https://reactnative.dev/docs/new-architecture-library-intro#migrating-off-setnativeprops) in migration guide optional.
Reviewed By: yungsters, mdvacca
Differential Revision: D41521523
fbshipit-source-id: 4d9bbd6304b8c5ee24a36b33039ed33ae1fc21f8
Summary:
a lot of files were depending on Geometry even though they didn't use Vector, this will help with future modularity
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D41127194
fbshipit-source-id: 024519c638a1f0df3fdbfbdd937eac84b9adee6e
Summary:
react-native-windows builds treat a lot of c++ compiler warnings as errors. Including ones that cause value truncation when assigning `size_t` values to an `int`.
This fixes the compiler warning, by using `size_t` as the type for `i`, which matches `size`. I then modified the loop to avoid the value underflow that occurs when decrementing an unsigned zero value.
## Changelog
[Internal] [Changed] - Fix compiler warnings around mixing int and size_t usage in unsafe ways
Pull Request resolved: https://github.com/facebook/react-native/pull/34889
Test Plan: This code change was made in react-native-windows when integrating latest react-native changes. -- our fabric implementation was able to run through this code without any issues.
Reviewed By: mdvacca
Differential Revision: D40158306
Pulled By: rozele
fbshipit-source-id: b6858cb953635b37fd63a88ed1a372eb3dc394f7
Summary:
A follow up to D38708718 (https://github.com/facebook/react-native/commit/403fea25f65a38f4b4d8e0edcf89741b29e62059) review, this factors feature flags for Fabric core code into a separate file, `CoreFeatures`.
Keeping them together is arguably better for maintenance and makes code easier to reason about.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D40007784
fbshipit-source-id: 1885d5d6200575c6015f063d8b05813b18b47ffb
Summary:
Previously, ViewPropsMapBuffer conversions were hardcoded deep in Android infrastructrue. I've generalized this into a different mechanism to allow any Props struct to support MapBuffer props.
There are still some things that need to be cleaned up and this should be treated as experimental. One thing we likely want to do is remove the hardcoded IDs (fine for codegen'd code; less so for handwritten) and use compile-time-hashed IDs instead with human-readable string names.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708719
fbshipit-source-id: 64603dee7f21828be31346c555d99862dab304ea
Summary:
Instead of having a special flag just for View MapBuffer props, we now use one flag to indicate that MapBuffer should be used for all props; each XShadowNode must set a special trait indicating if that ShadowNode supports MapBuffer props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708718
fbshipit-source-id: b398ec62a0db9c0ff23c0007c5503cf2838c4173
Summary:
changelog: [internal]
Add more clang tidy rules to prevent common class of bugs.
Reviewed By: javache
Differential Revision: D39245194
fbshipit-source-id: 5521c5c4653d7005b96ebba494e810ba5075afbc
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Differential Revision: D39052812
fbshipit-source-id: 9692633930555e64a3769116fc484a19e534aa3f
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D38938632
fbshipit-source-id: 1dc9a544ca679463a8aad5cc632bd918f42b15d1
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of `convertRawProp` for `std::optional` since we can handle that in a `fromRawValue` specialization instead.
To make this work, we need to remove `noexcept` from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D37055069
fbshipit-source-id: 8ce121a9b187f068d3ab790c6fae66d53e6338d2
Summary:
Currently the PropSetter parser parses all border{TopLeft,TopRight,...}Radius props except for `borderRadius`.
This is the fix.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38678226
fbshipit-source-id: 8c5d67a652c2b327aa50a997e8e886630fe139c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34403
This change mirrors D38457812 (https://github.com/facebook/react-native/commit/063c2b4668b279ccbca639f98f7a0a5c4d7c5690) which added -Wpedantic to ReactCommon targets, but for the Android build used by OSS. This should ensure contributors see the same warnings locally as the internal build would produce.
Changelog:
[Android][Changed] - Enable -Wpedantic in OSS Android Targets
Reviewed By: cortinico
Differential Revision: D38632454
fbshipit-source-id: 19a036ee3f902eb9d47c568aef448af9d8562358
Summary:
Folly's molly target combines a number of targets that are supposed to be useable on mobile. Since we're trying to move away from folly, we should instead list explicitly which parts of folly we're using so we can remove them over time, and track which targets no longer have any folly dependencies.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38352060
fbshipit-source-id: 09d0d84793692f97f4d49390c99c38b23441df54
Summary:
React Native is compiled downstream with MSVC, meaning the introduction of code depending on language extensions specific to gcc/clang may cause breakage.
We can enable `-Wpedantic` to flag any behavior not officially supported by the specified C++ standard. This will includes rules beyond what MSVC has trouble with, but seems to not have too many "noisy warnings".
This change enables -Wpedantic in BUCK targets within ReactCommon.
This makes the OSS C++ build for Android/iOS slightly more permissive than the internal build, A followup is to add the changes to OSS build logic as well, to avoid contributors seeing more errors upon internal submission. (checking with cortinico on how to do this for Android).
react-native-windows uses a higher warning level than `-Wall`, which is an additional cause of compilation failures, but is not addressed as part of this change.
Changelog:
[Internal][Changed] - Enable -Wpedantic for targets inside ReactCommon
Reviewed By: rshest
Differential Revision: D38457812
fbshipit-source-id: 014da1ac0b7ad8f78154e6e447ed58def6bd0d47
Summary:
Changelog:
[Android][Fixed] - Fix regression when setting shadow node properties.
Also simplified the corresponding macros to avoid using lambdas altogether, as they are not required.
Note that this **does not** modify any constexpr-related semantics of the existing code, as the main constexpr macro, `CONSTEXPR_RAW_PROPS_KEY_HASH` evaluation result is still contstexpr value, and the other ones already involved non-const parts (see my comments).
Reviewed By: NickGerleman
Differential Revision: D38356411
fbshipit-source-id: 22c330d3425c8aed36693f4652f1b257d2dc96be
Summary:
Fix macro errors for Windows. Current syntax breaks the build of the React Common project on Windows because the ({...}) syntax is not supported; must be replaced with lambda expressions.
Resolves https://github.com/facebook/react-native/issues/34090
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Fixed] - Fix macro errors for Windows.
lyahdav JoshuaGross
Pull Request resolved: https://github.com/facebook/react-native/pull/34299
Test Plan: Build on react-native-windows repo. Tested in RNW app.
Reviewed By: javache
Differential Revision: D38272966
Pulled By: NickGerleman
fbshipit-source-id: e76eac11cde173ef49465d01d793c593017f2ab7
Summary:
This diff fixes the bug T127619309 by exit early during calculateTransformedFrames if currentShadowNode cannot be casted
This is a bug that fired in fb4a but we didn't have a way to reproduce locally.
We are going to release this and enable feature flag with a MC
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38280674
fbshipit-source-id: 1c42c17678d8473564e4075a78d3c688efed1a23
Summary:
Calculation of TransformedFrames was a method introduced by D37994809 (https://github.com/facebook/react-native/commit/64528e5faa445907b8287b412c344f30c20fca61) to fix rendering of inverted flat lists.
We found that this operation is crashing in fb4a causing the UBN T127619309
This diff creates a feature flag to disable the calculation of TransformedFrames in Layoutable ShadowNodes. **The goal of this diff is to revert the behavior introduced by D37994809 (https://github.com/facebook/react-native/commit/64528e5faa445907b8287b412c344f30c20fca61)**
The featureFlag is disabled in fb4a and enabled in react AR (because ReactAr apps relies on the calculation of TransformedFrames and these apps are not affected)
The root cause of the bug will be fixed by D38280674 (which still requires more testing and investigation)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D38286857
fbshipit-source-id: 721cd0554ae6a6b369b3f8dbb584160a270d0f18
Summary:
changelog: [internal]
Vertical and horizontal inversion was not taken into account in `computeRelativeLayoutMetrics`. To fix it, we precompute frames to include inversions.
Reviewed By: mdvacca
Differential Revision: D37994809
fbshipit-source-id: 043e6f19b6fa577f61fa3c739ce2d751ef973cc3
Summary:
Fix todo and inconsistency across codebase. It's better to have just one way to refer to these types.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D37653146
fbshipit-source-id: e82f09caa6cd6eec5512b78f413708d9c04a7a83
Summary:
MSVC doesn't like Clang macros. Oops!
Constraints with this bit of code:
1. I'm trying to enforce constexpr in the most obvious, intuitive way possible. Macros are ugly but a "proper" solution would result in 10x as much code that is, totally subjectively, less readable to me.
2. This is evaluating at compile-time a hash of a string which is usually used in the `case` line of a switch statement.
For now I'm just hoping that MSVC will allow us to shadow `hash` which Xcode doesn't like. We might need to add a special pragma(s) for MSVC if it still doesn't like this.
Changelog: [Internal]
Reviewed By: lyahdav
Differential Revision: D37529949
fbshipit-source-id: 9aa605a9786bf5d194819ef8dade778875ae744e
Summary:
Perf numbers for this stack are given in terms of before-stack and after-stack, but the changes are split up for ease of review, and also to show that this migration CAN happen per-component and is 100% opt-in. Most existing C++ components do not /need/ to change at all.
# Problem Statement
During certain renders (select critical scenarios in specific products), UIManagerBinding::createNode time takes over 50% of JS thread CPU time. This could be higher or lower depending on the specific product and interaction, but overall createNode takes a lot of CPU time. The question is: can we improve this? What is the minimal overhead needed?
The vast, vast majority of time is taken up by prop parsing (specifically, converting JS values across the JSI into concrete values on the C++ props structs). Other methods like appendChild, etc, do not take up a significant amount of time; so we conclude that createNode is special, and the JSI itself, or calling into C++, is not the problem. Props parsing is the perf problem.
Can we improve it? (Spoiler: yes)
# How does props parsing work today?
Today, props parsing works as follows:
1. The ConcreteComponentDescriptor will construct a RawPropsParser (one per component /type/, per application: so one for View, one for Image, one for Text... etc)
2. Once per component type per application, ConcreteComponentDescriptor will call "prepare" on the RawPropsParser with an empty, default-constructed ConcreteProps struct. This ConcreteProps struct will cause RawProps.at(field) for every single field.
3. Based on the RawProps::at calls in part 2, RawPropsParser constructs a Map from props string names (width, height, position, etc) to a position within a "value index" array.
4. The above is what happens before any actual props are parsed; and the RawPropsParser is now ready to parse actual Props.
5. When props are actually being parsed from a JSI dictionary, we now have two phases:
1. The RawPropsParser `preparse`s the RawProps, by iterating over the JSI map and filling in two additional data structures: a linear list of RawValues, and a mapping from the ValueIndex array (`keyIndexToValueIndex_`; see step 3) to a value's position in the values list (`value_` in RawPropsParser/RawProps);
2. The ConcretePropT constructor is called, which is the same as in step 2/3, which calls `fieldValue = rawProps.at("fieldName")` repeatedly.
3. For each `at` call, the RawProps will look up a prop name in the Map constructed in step 3, and either return an empty value, or map the key name to the `keyIndexToValueIndex_` array, which maps to a value in `values_`, which is then returned and further parsed.
So, a few things that become clear with the current architecture:
1. Complexity is a property of the number of /possible/ props that /can/ be parsed, not what is actually used in product code. This violates the "only pay for what you use" principal. If you have `<View opacity={0.5} />`, the ViewProps constructor will request ~170 properties, not 1!
2. There's a lot of pre-parsing which isn't free
3. The levels of indirection aren't free, and make cache misses more likely and pipelining is more challenging
4. The levels of indirection also require more memory - minor, but not free
# How can we improve it?
The goal is to improve props parsing with minimal or zero impact on backwards-compability. We should be able to migrate over components when it's clear there's a performance issue, without requiring everything gets migrated over at once. This both (1) helps us prove out the new architecture, (2) derisks the project, (3) gives us time, internally and externally, to perfect the APIs and gradually migrate everything over before deleting the old infrastructure code entirely.
Thus, the goal is to do something that introduces a zero-cost abstraction. This isn't entirely possible in practice, and in fact this method slightly regresses components that do not use the new architecture /at all/, while dramatically improving migrated components and causing the impact of the /old/ architecture to be minimal.
# Solution
1. We still keep the existing system in place entirely.
2. After Props are constructed (see ConcreteComponentDescriptor changes) we iterate over all the /values/ set from JS, and call PropsT::setProp. Incidentally, this allows us to easily reuse the same prop for multiple values for "free", which was expensive in the old system.
3. It's worth noting that this makes a Props struct "less immutable" than it was before, and essentially now we have a "builder pattern" for Props. (If we really wanted to, we could still require a single constructor for Props, and then actually use an intermediate PropsBuilder to accumulate values - but I don't think this overhead would be worth for the conceptual "immutability" win, and instead a "Construct/Set/Seal" model works fine, and we still have all the same guarantees of immutability after the parsing phase)
# Implementation Details
# How to properly construct a single Prop value
Minor detail: parsing a single prop is a 3-step process. We imagine two scenarios: (1) Creating a new ShadowNode/Props A from nothing/void, so the previous Props value is just the default constructor. (2) Cloning a ShadowNode A->B and therefore Props A must be copied to Props B before parsing.
We will denote this as a clone from A->B, where A may or may not be a previous node or a default-constructed Props node; and imagine in particular that we're setting the "opacity" value for PropsB.
We must first (1) copy a value over from the previous version of the Props struct, so B.opacity = A.opacity; (2) Determine if opacity has been set from JS. If so, and there is a value, B.opacity = parse(JSValue). (3) If JS has passed in a value for the prop, BUT the value is `null`, it means that JS is resetting or deleting the prop, so we must set it BACK to the default. In this case we set PropsB.opacity = DefaultConstructedProps.opacity.
We must take care in general to ensure that the correct behavior is achieved here, which should help to explain some of the code below.
## String comparisons vs hash comparisons
In the previous system, a RawPropsKey is three `const char*` strings, concatenated together repeatedly /at runtime/. In practice, the ONLY reason we have the prefix, name, suffix Key structure is for the templated prop parsing in ViewProps and YogaStyableProps - that's it. It's not used anywhere else. Further, the key {"margin", "Left", "Width"} is identical to the key {"marginLeftWidth", null, null} and we don't do anything fancy with matching prefixes before comparing the whole string, or similar. Before comparison, keys are concatenated into a single string and then we use `strcmp`. The performance of this isn't terrible, but it's nonzero overhead.
I think we can do better and it's sufficient to compare hashed string values; even better, we can construct most of these /at compile time/ using constexpr, and using `switch` statements guarantee no hash collisions within a single Props struct (it's possible there's a collision between Props.cpp and ViewProps.cpp, for example, since they're different switch statements). We may eventually want to be more robust against has collisions; I personally don't find the risk to be too great, hash collisions with these keys are exceedingly unlikely (or maybe I just like to live dangerously). Thus, at runtime, each setProp requires computing a single hash for the value coming from JS, and then int comparisons with a bunch of pre-compiled values.
If we want to be really paranoid, we could be robust to hash collisions by doing `switch COMPILED_HASH("opacity"): if (strcmp(strFromJs, "opacity") == 0)`. I'm happy to do this if there's enough concern.
## Macros
Yuck! I'm using lots of C preprocessor macros. In general I found this way, way easier in reducing code and (essentially) doing codegen for me vs templated code for the switch cases and hashing prop names at compile-time. Maybe there's a better way.
Changelog: [Added][Fabric] New API for efficient props construction
Reviewed By: javache
Differential Revision: D37050215
fbshipit-source-id: d2dcd351a93b9715cfeb5197eb0d6f9194ec6eb9
Summary:
This target is not a good idea for a number of reasons:
1. It groups up multiple targets which breaks the dependency graph
2. It does not handle dependency remapping correctly
3. It has no mirror into fbcode
We should warn people this is a bad idea
Reviewed By: alexmalyshev
Differential Revision: D36519357
fbshipit-source-id: d60ca3237c7710118732578fecd1b2fc8903321b
Summary:
This diff cleans up several Android Makefiles which we're not using anymore
as they've been replaced by CMake files.
There are still 3 Makefiles left, which I'm aiming to remove in the near future.
Changelog:
[Internal] [Changed] - Remove unused Makefiles from React Native core
Reviewed By: javache
Differential Revision: D36660902
fbshipit-source-id: 8afffac74d493616b0f9414567821cd69f4ef803
Summary:
Cherry picking https://github.com/facebook/react-native/pull/33707 to main branch
This change is extending the changes made by alespergl to reduce the file paths and command lengths of ndk build commands
Essentially we are shortening the length of the source files by using relative paths instead of absolute paths as enumerated by the wildcard expression
This commit is extending the fix by including all the new modules introduced into RN for the new architecture, including the generated modules.
We are also reverting the ndk bump as ndk23 is crashing frequently when building RN with new arch. The reduced file paths lengths ensures the ndk bump is not required for relatively short application paths.
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
## Changelog
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33784
Test Plan: Verified building on windows box
Reviewed By: javache
Differential Revision: D36241928
Pulled By: cortinico
fbshipit-source-id: 1ce428a271724cbd3b00a24fe03e7d69253f169b
Summary:
Minimal set of changes to intercept events in external modules. Current intended use-case is for Reanimated to handle events for the Animated properties.
Changelog: [Added] Add listeners to allow intercepting events in C++ core.
Reviewed By: cipolleschi
Differential Revision: D35312534
fbshipit-source-id: ec924b57fd0c0dabf7be7b886dbef23bf3170d6c
Pieter De Baets
Nick Gerleman
Joshua Selbo
Samuel Susla
Rubén Norte
Ruslan Shestopalyuk
gabrieldonadel
Phillip Pan
David Vacca
Paige Sun
Jonathan Keljo
Andrew Coates
Samuel Susla
Pieter De Baets
Shawn Shihang Wei
Ravi Shah
Joshua Gross
Nick Gerleman
Ruslan Shestopalyuk
Dark Knight
Chiara Mooney
David Vacca
Michael Lee (Engineering)
Nicola Corti
Anandraj Govindan