[Due for payment 2026-10-15] [Refactor] MoneyRequestConfirmationList follow-up: stabilize controller props, dedupe variant shell, single-path context #102283

Follow-up to Split MoneyRequestConfirmationList. It covers points 1–3 of this review comment. They were left out of that PR to keep it scoped. Do them in order, because point 3 is easier after points 1 and 2.

Code links point to the PR head at 793bf07.

1. Stop passing the whole context bag to the controllers

hooks/useConfirmationListData.ts:277-354 returns one large object. Every variant passes it to ConfirmationDataContext.Provider value={data}. A change to any key gives data a new identity, for example formError on a keystroke, formattedAmount, or isConfirming. Then every consumer re-renders. On main, FieldAutoSelector and SplitBillController could skip those renders.

• Return a prop bundle for each controller from the hook, the way it already returns layoutProps, errorState, and visibilityFlags. For example, add taxControllerProps and fieldAutoSelectProps. Pass the bundles as props so the compiler memoizes each controller separately.
• ConfirmationListLayout.tsx:46 reads the whole context just to get isReadOnly. Move isReadOnly into layoutProps and drop that context read. This is the smallest useful version of the change.

Caveat: The usePrevious values at TaxController.tsx:28 and DistanceRequestController.tsx:78 depend on how often those controllers re-render. Recheck them after the change.

2. Remove the duplicated shell from the six variants

The variants are 75–85% identical. Each one builds the same shell by hand:

• the provider
• the controller mount list
• ConfirmationFieldsProvider
• the <View> wrapper
• a 7–9 line footer prop bundle

Only the set of mounted controllers really differs. Move the shared shell into one place, for example ConfirmationListLayout taking {data, listFooterContent, children}. Each variant would then only choose its controllers.

Caveat: The controllers render before ConfirmationListLayout on purpose, so their effects run before the footer fields' effects. For example, TaxController seeds taxCode and taxAmount before TaxFields reads them. Any restructure must keep that effect order, and it needs testing across all expense types.

3. Give each value one path on the context object

About a dozen values are reachable through two or three paths. For example, transactionID is available as data.transactionID, layoutProps.transactionID, and confirmationFieldsProviderProps.transactionID. The same is true of these values:

• formattedAmount
• setFormError
• clearFormErrors
• shouldShowTax
• shouldShowCategories
• isCategoryRequired
• isReadOnly
• policyID
• reportID
• iouType
• isPolicyExpenseChat

Call sites already mix these paths. For example, ScanConfirmationList.tsx:30 reads data.layoutProps.transactionID, even though data.transactionID exists. Pick one shape.

Also, declare ConfirmationData explicitly. Today ConfirmationDataContext.ts:6 types it as ReturnType<typeof useConfirmationListData>, so nothing defines the contract.

Testing

Run the expense-type matrix from the Tests section of Split MoneyRequestConfirmationList: Manual, Scan, Multi-scan, Distance (map, manual, and odometer), Per diem, Time, Split, Invoice, Pay, Track → Submit, split details, and Share.

Parent issue: [Refactor] Split IOURequestStepConfirmation, MoneyRequestConfirmationList, and useExpenseSubmission per expense type