Skip to content

Skip RawPropsParser::prepare<T>() when the iterator-setter path is active (#57329)#57329

Open
javache wants to merge 3 commits into
react:mainfrom
javache:export-D109569571
Open

Skip RawPropsParser::prepare<T>() when the iterator-setter path is active (#57329)#57329
javache wants to merge 3 commits into
react:mainfrom
javache:export-D109569571

Conversation

@javache

@javache javache commented Jun 24, 2026 •
edited by meta-codesync Bot
Loading

Copy link
Copy Markdown
Contributor

Summary:

RawPropsParser::prepare<ConcreteProps>() runs in ConcreteComponentDescriptor's constructor and builds the parser's keys_ vector + nameToIndex_ length-bucketed map by walking every convertRawProp call in a probe construction of ConcreteProps. The cost is O(n²) in the number of props (the comment in RawPropsParser::at notes 4950 lookups for a 100-prop class) and is paid once per component class at app startup.

Those data structures are consumed only by RawProps::at(), which is reached exclusively through the classic per-field convertRawProp path. The iterator-setter path skips parse() entirely (see the prior diff in the stack), so the prepared parser is dead weight when both:

  1. HasIteratorSetterCtor<ConcreteProps> is satisfied (i.e. the type opts into the iterator-setter path), AND
  2. enableCppPropsIteratorSetter() is on at runtime.

Guard the call accordingly. Classes that don't satisfy the concept always run prepare<T>() (they can only use the classic path); when the runtime flag is off, all classes run it (since they all fall back to classic).

Changelog:
[Internal]

Reviewed By: christophpurrer, lenaic

Differential Revision: D109569571

@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jun 24, 2026
@meta-codesync

meta-codesync Bot commented Jun 24, 2026

Copy link
Copy Markdown

@javache has exported this pull request. If you are a Meta employee, you can view the originating Diff in D109569571.

javache added a commit to javache/react-native that referenced this pull request Jun 25, 2026
@javache @meta-codesync
Skip RawPropsParser::prepare<T>() when the iterator-setter path is …
2ec5eb4 
…active (react#57329)

Summary:
Pull Request resolved: react#57329

`RawPropsParser::prepare<ConcreteProps>()` runs in `ConcreteComponentDescriptor`'s constructor and builds the parser's `keys_` vector + `nameToIndex_` length-bucketed map by walking every `convertRawProp` call in a probe construction of `ConcreteProps`. The cost is O(n²) in the number of props (the comment in `RawPropsParser::at` notes 4950 lookups for a 100-prop class) and is paid once per component class at app startup.

Those data structures are consumed **only** by `RawProps::at()`, which is reached exclusively through the classic per-field `convertRawProp` path. The iterator-setter path skips `parse()` entirely (see the prior diff in the stack), so the prepared parser is dead weight when both:

1. `HasIteratorSetterCtor<ConcreteProps>` is satisfied (i.e. the type opts into the iterator-setter path), AND
2. `enableCppPropsIteratorSetter()` is on at runtime.

Guard the call accordingly. Classes that don't satisfy the concept always run `prepare<T>()` (they can only use the classic path); when the runtime flag is off, all classes run it (since they all fall back to classic).

Changelog:
[Internal]

Differential Revision: D109569571
@meta-codesync meta-codesync Bot changed the title Skip RawPropsParser::prepare<T>() when the iterator-setter path is active Skip RawPropsParser::prepare<T>() when the iterator-setter path is active (#57329) Jun 25, 2026
@javache javache force-pushed the export-D109569571 branch from 3f22899 to 2ec5eb4 Compare June 25, 2026 07:34
javache added a commit to javache/react-native that referenced this pull request Jun 25, 2026
@javache @facebook-github-bot
Skip RawPropsParser::prepare<T>() when the iterator-setter path is …
0955e94 
…active (react#57329)

Summary:

`RawPropsParser::prepare<ConcreteProps>()` runs in `ConcreteComponentDescriptor`'s constructor and builds the parser's `keys_` vector + `nameToIndex_` length-bucketed map by walking every `convertRawProp` call in a probe construction of `ConcreteProps`. The cost is O(n²) in the number of props (the comment in `RawPropsParser::at` notes 4950 lookups for a 100-prop class) and is paid once per component class at app startup.

Those data structures are consumed **only** by `RawProps::at()`, which is reached exclusively through the classic per-field `convertRawProp` path. The iterator-setter path skips `parse()` entirely (see the prior diff in the stack), so the prepared parser is dead weight when both:

1. `HasIteratorSetterCtor<ConcreteProps>` is satisfied (i.e. the type opts into the iterator-setter path), AND
2. `enableCppPropsIteratorSetter()` is on at runtime.

Guard the call accordingly. Classes that don't satisfy the concept always run `prepare<T>()` (they can only use the classic path); when the runtime flag is off, all classes run it (since they all fall back to classic).

Changelog:
[Internal]

Differential Revision: D109569571
@javache javache force-pushed the export-D109569571 branch from 2ec5eb4 to 0955e94 Compare June 25, 2026 11:28
javache added a commit to javache/react-native that referenced this pull request Jun 25, 2026
@javache @meta-codesync
Skip RawPropsParser::prepare<T>() when the iterator-setter path is …
dd2087f 
…active (react#57329)

Summary:
Pull Request resolved: react#57329

`RawPropsParser::prepare<ConcreteProps>()` runs in `ConcreteComponentDescriptor`'s constructor and builds the parser's `keys_` vector + `nameToIndex_` length-bucketed map by walking every `convertRawProp` call in a probe construction of `ConcreteProps`. The cost is O(n²) in the number of props (the comment in `RawPropsParser::at` notes 4950 lookups for a 100-prop class) and is paid once per component class at app startup.

Those data structures are consumed **only** by `RawProps::at()`, which is reached exclusively through the classic per-field `convertRawProp` path. The iterator-setter path skips `parse()` entirely (see the prior diff in the stack), so the prepared parser is dead weight when both:

1. `HasIteratorSetterCtor<ConcreteProps>` is satisfied (i.e. the type opts into the iterator-setter path), AND
2. `enableCppPropsIteratorSetter()` is on at runtime.

Guard the call accordingly. Classes that don't satisfy the concept always run `prepare<T>()` (they can only use the classic path); when the runtime flag is off, all classes run it (since they all fall back to classic).

Changelog:
[Internal]

Differential Revision: D109569571
@javache javache force-pushed the export-D109569571 branch 2 times, most recently from dd2087f to f4f2eae Compare June 26, 2026 16:54
javache added a commit to javache/react-native that referenced this pull request Jun 26, 2026
@javache @facebook-github-bot
Skip RawPropsParser::prepare<T>() when the iterator-setter path is …
f4f2eae 
…active (react#57329)

Summary:

`RawPropsParser::prepare<ConcreteProps>()` runs in `ConcreteComponentDescriptor`'s constructor and builds the parser's `keys_` vector + `nameToIndex_` length-bucketed map by walking every `convertRawProp` call in a probe construction of `ConcreteProps`. The cost is O(n²) in the number of props (the comment in `RawPropsParser::at` notes 4950 lookups for a 100-prop class) and is paid once per component class at app startup.

Those data structures are consumed **only** by `RawProps::at()`, which is reached exclusively through the classic per-field `convertRawProp` path. The iterator-setter path skips `parse()` entirely (see the prior diff in the stack), so the prepared parser is dead weight when both:

1. `HasIteratorSetterCtor<ConcreteProps>` is satisfied (i.e. the type opts into the iterator-setter path), AND
2. `enableCppPropsIteratorSetter()` is on at runtime.

Guard the call accordingly. Classes that don't satisfy the concept always run `prepare<T>()` (they can only use the classic path); when the runtime flag is off, all classes run it (since they all fall back to classic).

Changelog:
[Internal]

Reviewed By: christophpurrer, lenaic

Differential Revision: D109569571
javache added a commit to javache/react-native that referenced this pull request Jun 26, 2026
@javache @facebook-github-bot
Skip RawPropsParser::prepare<T>() when the iterator-setter path is …
27fa8d9 
…active (react#57329)

Summary:

`RawPropsParser::prepare<ConcreteProps>()` runs in `ConcreteComponentDescriptor`'s constructor and builds the parser's `keys_` vector + `nameToIndex_` length-bucketed map by walking every `convertRawProp` call in a probe construction of `ConcreteProps`. The cost is O(n²) in the number of props (the comment in `RawPropsParser::at` notes 4950 lookups for a 100-prop class) and is paid once per component class at app startup.

Those data structures are consumed **only** by `RawProps::at()`, which is reached exclusively through the classic per-field `convertRawProp` path. The iterator-setter path skips `parse()` entirely (see the prior diff in the stack), so the prepared parser is dead weight when both:

1. `HasIteratorSetterCtor<ConcreteProps>` is satisfied (i.e. the type opts into the iterator-setter path), AND
2. `enableCppPropsIteratorSetter()` is on at runtime.

Guard the call accordingly. Classes that don't satisfy the concept always run `prepare<T>()` (they can only use the classic path); when the runtime flag is off, all classes run it (since they all fall back to classic).

Changelog:
[Internal]

Reviewed By: christophpurrer, lenaic

Differential Revision: D109569571
@javache javache force-pushed the export-D109569571 branch 2 times, most recently from 27fa8d9 to 2a3a59f Compare June 29, 2026 20:48
javache added a commit to javache/react-native that referenced this pull request Jun 29, 2026
@javache @meta-codesync
Skip RawPropsParser::prepare<T>() when the iterator-setter path is …
2a3a59f 
…active (react#57329)

Summary:
Pull Request resolved: react#57329

`RawPropsParser::prepare<ConcreteProps>()` runs in `ConcreteComponentDescriptor`'s constructor and builds the parser's `keys_` vector + `nameToIndex_` length-bucketed map by walking every `convertRawProp` call in a probe construction of `ConcreteProps`. The cost is O(n²) in the number of props (the comment in `RawPropsParser::at` notes 4950 lookups for a 100-prop class) and is paid once per component class at app startup.

Those data structures are consumed **only** by `RawProps::at()`, which is reached exclusively through the classic per-field `convertRawProp` path. The iterator-setter path skips `parse()` entirely (see the prior diff in the stack), so the prepared parser is dead weight when both:

1. `HasIteratorSetterCtor<ConcreteProps>` is satisfied (i.e. the type opts into the iterator-setter path), AND
2. `enableCppPropsIteratorSetter()` is on at runtime.

Guard the call accordingly. Classes that don't satisfy the concept always run `prepare<T>()` (they can only use the classic path); when the runtime flag is off, all classes run it (since they all fall back to classic).

Changelog:
[Internal]

Reviewed By: christophpurrer, lenaic

Differential Revision: D109569571
javache and others added 3 commits June 30, 2026 02:57
@javache @meta-codesync
Remove unused ViewShadowNodeProps subclass
2bf2c97 
Summary:
ViewShadowNodeProps was a thin subclass of ViewProps that only forwarded its constructor. After the feature flag propagation logic was removed, the subclass serves no purpose.

This change:
- Removes the ViewShadowNodeProps class and replaces it with a type alias to ViewProps
- Updates ViewShadowNode to use ViewProps directly in its ConcreteViewShadowNode base
- Updates YogaLayoutableShadowNode::swapLeftAndRightInViewProps to cast to ViewProps
- Updates all test files that instantiated ViewShadowNodeProps to use ViewProps instead
- Fixes AvatarFranzPreviewViewComponentView to initialize _props with defaultSharedProps() to avoid null oldProps in updateProps

This simplifies the View component type hierarchy and removes dead code.

Changelog:
[Internal]

Differential Revision: D110095190
@javache @meta-codesync
Route enableCppPropsIteratorSetter through a copy ctor + `RawProps:…
0d77d93 
…:forEachItem` (react#57328)

Summary:
Pull Request resolved: react#57328

Today the iterator-setter path in `ConcreteComponentDescriptor::cloneProps` runs three sequential walks over the input — `RawProps::parse(parser)` (builds `keyIndexToValueIndex_` for `convertRawProp`), `static_cast<folly::dynamic>(rawProps)` (materializes a `folly::dynamic` via `jsi::dynamicFromValue` in JSI mode), and then `dynamic.items()` to dispatch `setProp`. Only the third is actually used: `convertRawProp` is never called on the iterator-setter branch, and the `folly::dynamic` materialization exists only as iteration scaffolding.

Restructure so the runtime flag picks one of two construction paths up front:

- **Iterator-setter** — copy-construct from `sourceProps` via the (re-enabled) `Props` copy ctor, then walk `rawProps` in-place via the new `RawProps::forEachItem` helper and route each entry through `setProp`. `parse()` is skipped entirely; the `folly::dynamic` materialization is skipped in `Mode::JSI`.
- **Classic** — unchanged: `parse()` + 3-arg `convertRawProp`-driven ctor.

`forEachItem` switches on `RawProps::Mode`:
- `Mode::JSI` — walks `value_.asObject(*runtime_).getPropertyNames(...)` and constructs `RawValue` from each `jsi::Value` directly, no `folly::dynamic` in between.
- `Mode::Dynamic` — iterates `dynamic_.items()` (same as today).
- `Mode::Empty` — no-op.

A new `HasIteratorSetterCtor<T>` concept (`std::copy_constructible<T>`) documents the contract and feeds a `static_assert` in `cloneProps`, so a future Props type that deletes its copy ctor fails at compile time rather than silently diverging at runtime between the two flag states.

The `RN_SERIALIZABLE_STATE` Props 2.0 accumulation branch keeps its existing dynamic-iteration shape — when `fallbackToDynamicRawPropsAccumulation` is true, `initializeDynamicProps` has already merged the source's rawProps with the input onto `shadowNodeProps->rawProps`, so we iterate that merged dynamic rather than the raw input.

The per-field `flag ? sourceProps.X : convertRawProp(...)` ternaries across every Props .cpp file become dead in the flag-on path (the copy ctor handles those fields) but are still functional in the flag-off path. They get removed in a follow-up cleanup; this diff is structurally non-breaking on either flag state.

Changelog:
[Internal]

Differential Revision: D109568749
@javache @meta-codesync
Skip RawPropsParser::prepare<T>() when the iterator-setter path is …
ad40a52 
…active (react#57329)

Summary:
Pull Request resolved: react#57329

`RawPropsParser::prepare<ConcreteProps>()` runs in `ConcreteComponentDescriptor`'s constructor and builds the parser's `keys_` vector + `nameToIndex_` length-bucketed map by walking every `convertRawProp` call in a probe construction of `ConcreteProps`. The cost is O(n²) in the number of props (the comment in `RawPropsParser::at` notes 4950 lookups for a 100-prop class) and is paid once per component class at app startup.

Those data structures are consumed **only** by `RawProps::at()`, which is reached exclusively through the classic per-field `convertRawProp` path. The iterator-setter path skips `parse()` entirely (see the prior diff in the stack), so the prepared parser is dead weight when both:

1. `HasIteratorSetterCtor<ConcreteProps>` is satisfied (i.e. the type opts into the iterator-setter path), AND
2. `enableCppPropsIteratorSetter()` is on at runtime.

Guard the call accordingly. Classes that don't satisfy the concept always run `prepare<T>()` (they can only use the classic path); when the runtime flag is off, all classes run it (since they all fall back to classic).

Changelog:
[Internal]

Reviewed By: christophpurrer, lenaic

Differential Revision: D109569571
@javache javache force-pushed the export-D109569571 branch from 2a3a59f to ad40a52 Compare June 30, 2026 17:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. meta-exported p: Facebook Partner: Facebook Partner

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@javache