refactor(tabs): split native nav state into state and update request

[kkafar]

Description

Note

This PR stacks on top of #3949 — please review/land that one first. The base branch here is @kkafar/rename-is-native-action, not main.

The native tabs JS-driven nav state update path was using a single type — RNSTabsNavigationState on iOS and TabsNavState on Android — to represent two distinct concepts:

1. Authoritative state held by the native container: (selectedScreenKey, provenance).
2. A JS request to change that state delivered via the navStateRequest prop: (selectedScreenKey, baseProvenance).

This conflation was tolerable while we only had one origin (ProgrammaticJs / PROGRAMMATIC_JS), but with the new public actionOrigin enum and the need to support more origins in the future (notably native-programmatic), the request needs to carry its own origin alongside its base provenance. The state type is the wrong place for that field — it describes a result, not a request.

This PR introduces a sibling …UpdateRequest type on both platforms and threads it through the JS-driven update path. The architectural consequence is that the native container becomes origin-agnostic on its success path: instead of hardcoding actionOrigin = ProgrammaticJs when the update succeeds, it forwards whatever the incoming request carried. The view manager / component view (which knows the origin is ProgrammaticJs for prop-driven updates) is now the place that decides.

The runtime value of actionOrigin on the public event is unchanged today — JS-driven updates still surface 'programmatic-js'. This is purely an internal architectural shift.

Changes

iOS

• New RNSTabsNavigationStateUpdateRequest type in RNSTabsNavigationState.h/.mm with selectedScreenKey, baseProvenance, actionOrigin. Mirrors RNSTabsNavigationState's utility surface (designated init, cloneRequest, static factory).
• RNSTabsHostComponentView:
  • navStateRequest property retyped to RNSTabsNavigationStateUpdateRequest *.
  • updateProps:oldProps: constructs the request directly from C++ props with actionOrigin = RNSTabsActionOriginProgrammaticJs and forwards a cloneRequest to the controller.
  • The rejectedStateUpdateTo: delegate impl reads request.selectedScreenKey / request.baseProvenance for the rejection event payload.
• RNSTabBarController:
  • setPendingNavigationStateUpdate: retyped to take the request.
  • Ivar renamed _pendingOperation → _pendingStateUpdate and retyped.
  • Success-path RNSTabsNavigationStateUpdateContext now uses _pendingStateUpdate.actionOrigin instead of hardcoded ProgrammaticJs.
  • isNavigationStateUpdateStale: retyped; reads .baseProvenance.
  • Delegate rejectedStateUpdateTo: parameter retyped to the request.
• OnTabSelectionRejectedPayload.rejectedNavState (in RNSTabsHostEventEmitter.h) renamed/retyped to rejectedRequest: RNSTabsNavigationStateUpdateRequest *. The JSI emit reads selectedScreenKey / baseProvenance from the request.

Android

• New TabsNavStateUpdateRequest data class in TabsNavState.kt with selectedScreenKey, baseProvenance, actionOrigin.
• TabsHostViewManager.setNavStateRequest constructs the request with actionOrigin = TabsActionOrigin.PROGRAMMATIC_JS baked in (instead of just a TabsNavState).
• TabsHost.jsNavStateRequest retyped to TabsNavStateUpdateRequest?. updateJSNavStateRequest retyped.
• TabSelectOp retyped to wrap a TabsNavStateUpdateRequest (field navState → request).
• TabsContainer:
  • onMenuItemSelected no longer hardcodes PROGRAMMATIC_JS in the external-context branch — it reads (pendingOperation as TabSelectOp).request.actionOrigin. The isInExternalOperationContext flag stays (it still suppresses the prevent-native-selection check and the lastUINavState capture).
  • isNavStateStale retyped; reads request.baseProvenance.
  • All performOperation reads updated to tabSelectOp.request.….
• TabsContainerDelegate.onNavStateUpdateRejected parameter rejectedNavState: TabsNavState retyped to rejectedRequest: TabsNavStateUpdateRequest. TabsHostEventEmitter and TabsHostTabSelectionRejectedEvent follow.
• Bundles a TabsNavState.selectedKey → selectedScreenKey rename for cross-platform consistency with the JS contract and the new request type. JS-facing WritableMap keys (selectedScreenKey, rejectedScreenKey) were already named correctly — only the Kotlin-internal field name moves.

No JS, codegen-spec, or conversion-helper changes — public contract untouched.

Test plan

No new automated tests; this is an internal architectural refactor with no behavioral change on the user/JS-driven paths. Manual verification via FabricExample:

iOS

• Tab bar tap → actionOrigin === 'user' (unchanged path).
• JS-driven navStateRequest update → actionOrigin === 'programmatic-js' (now sourced from the request, not hardcoded in the controller).
• iPad horizontal size-class transition forcing UIKit reshuffle → actionOrigin === 'implicit' (unchanged path).
• Stale JS update (rejectStaleNavStateUpdates: true, mid-flight tap) → onTabSelectionRejected fires with rejectedScreenKey and rejectedProvenance matching the request's selectedScreenKey and baseProvenance.

Android

• Tab bar tap → actionOrigin === 'user' (unchanged path).
• JS-driven navStateRequest update → actionOrigin === 'programmatic-js' (now sourced from the request, not hardcoded in the container).
• Stale JS update (rejectStaleNavStateUpdates: true, mid-flight tap) → onTabSelectionRejected fires with rejectedScreenKey and rejectedProvenance matching the request's selectedScreenKey and baseProvenance.

Reproduction lives in the FabricExample Tabs test screens; log e.nativeEvent.actionOrigin from onTabSelected and e.nativeEvent.rejectedScreenKey / rejectedProvenance from onTabSelectionRejected.

Checklist

• Included code example that can be used to test this change.
• For visual changes, included screenshots / GIFs / recordings documenting the change.
• For API changes, updated relevant public types.
• Ensured that CI passes

[Copilot]

Pull request overview

Refactors the iOS tabs JS-driven navigation update flow by introducing a dedicated “state update request” type so the controller can propagate the request’s actionOrigin rather than hardcoding it.

Changes:

• Introduces RNSTabsNavigationStateUpdateRequest (selected key, base provenance, action origin) and threads it through the JS-driven update pipeline.
• Retypes pending updates and rejection plumbing (controller ↔ component view ↔ event emitter) to use the new request type, including rejection payload fields.
• Minor formatting-only changes in RNSScreenStackHeaderConfig.mm.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
ios/tabs/host/RNSTabsNavigationState.h	Adds the new request type and organizes related enums/types.
ios/tabs/host/RNSTabsNavigationState.mm	Implements RNSTabsNavigationStateUpdateRequest utilities (init, cloneRequest, factory).
ios/tabs/host/RNSTabBarController.h	Retypes delegate + pending-update API to accept the request type.
ios/tabs/host/RNSTabBarController.mm	Stores pending updates as requests; forwards request actionOrigin on success; uses baseProvenance for staleness checks and rejection callbacks.
ios/tabs/host/RNSTabsHostComponentView.h	Retypes navStateRequest to the request type.
ios/tabs/host/RNSTabsHostComponentView.mm	Constructs requests from props (ProgrammaticJs) and forwards cloned requests; updates rejection delegate signature/payload.
ios/tabs/host/RNSTabsHostEventEmitter.h	Renames/retypes rejected payload field to rejectedRequest.
ios/tabs/host/RNSTabsHostEventEmitter.mm	Emits rejection payload using rejectedRequest.selectedScreenKey / baseProvenance.
ios/RNSScreenStackHeaderConfig.mm	Formatting-only line wrapping/indentation changes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.