What performance issue do we need to solve?
Expense submission from QAB/FAB across all IOU types (PAY, SPLIT, TRACK, SUBMIT/REQUEST, INVOICE) lacks dismiss-first navigation, causing users to see a blank transition between tapping submit and the destination page appearing. Skip-confirmation paths (scan, distance, split+receipt) also lack telemetry instrumentation for the ManualSubmitToDestinationVisible span.
What is the impact of this on end-users?
After submitting an expense, users experience a visible delay where the RHP modal closes before the destination page appears. Dismiss-first navigation makes the destination page render underneath the closing animation, eliminating this perceived lag. Deferred API writes further ensure the transition is not blocked by write operations.
Proposed solution
- Add dismiss-first navigation to all remaining QAB/FAB IOU submission paths: PAY, SPLIT, TRACK, SUBMIT/REQUEST, INVOICE
- Defer API writes until after the navigation transition completes
- Add full telemetry instrumentation (
startTracking, setFastPath, setPendingSubmitFollowUpAction) to skip-confirmation paths that currently lack it (scan, distance, split+receipt) to enable ManualSubmitToDestinationVisible span measurement
- Add a new
DISMISS_TO_REPORT submit handler for destination-report flows (SPLIT/TRACK)
- Refactor Search optimistic tracking into dedicated hooks (
useOptimisticSearchTracking, useStableOptimisticSortedData) for maintainability
Related issues
Part of ManualSubmitToDestinationVisible - Measure end-to-end time from expense creation submit to destination page render
Related code
src/libs/actions/IOU/index.ts — IOU action orchestrationsrc/libs/actions/IOU/MoneyRequest.ts — skip-confirmation paths for scan/distancesrc/libs/actions/IOU/Split.ts — split bill flowssrc/libs/actions/IOU/SendMoney.ts — send money flowssrc/libs/actions/IOU/TrackExpense.ts — track expense flowssrc/pages/iou/request/step/IOURequestStepAmount.tsx — QAB submission entry pointsrc/pages/iou/request/step/IOURequestStepConfirmation.tsx — confirmation step submitsrc/components/Search/index.tsx — Search optimistic trackingsrc/libs/telemetry/activeSpans.ts — span management
Platforms:
Issue Owner
Current Issue Owner: @mallenexpensify
What performance issue do we need to solve?
Expense submission from QAB/FAB across all IOU types (PAY, SPLIT, TRACK, SUBMIT/REQUEST, INVOICE) lacks dismiss-first navigation, causing users to see a blank transition between tapping submit and the destination page appearing. Skip-confirmation paths (scan, distance, split+receipt) also lack telemetry instrumentation for the
ManualSubmitToDestinationVisiblespan.What is the impact of this on end-users?
After submitting an expense, users experience a visible delay where the RHP modal closes before the destination page appears. Dismiss-first navigation makes the destination page render underneath the closing animation, eliminating this perceived lag. Deferred API writes further ensure the transition is not blocked by write operations.
Proposed solution
startTracking,setFastPath,setPendingSubmitFollowUpAction) to skip-confirmation paths that currently lack it (scan, distance, split+receipt) to enableManualSubmitToDestinationVisiblespan measurementDISMISS_TO_REPORTsubmit handler for destination-report flows (SPLIT/TRACK)useOptimisticSearchTracking,useStableOptimisticSortedData) for maintainabilityRelated issues
Part of ManualSubmitToDestinationVisible - Measure end-to-end time from expense creation submit to destination page render
Related code
src/libs/actions/IOU/index.ts— IOU action orchestrationsrc/libs/actions/IOU/MoneyRequest.ts— skip-confirmation paths for scan/distancesrc/libs/actions/IOU/Split.ts— split bill flowssrc/libs/actions/IOU/SendMoney.ts— send money flowssrc/libs/actions/IOU/TrackExpense.ts— track expense flowssrc/pages/iou/request/step/IOURequestStepAmount.tsx— QAB submission entry pointsrc/pages/iou/request/step/IOURequestStepConfirmation.tsx— confirmation step submitsrc/components/Search/index.tsx— Search optimistic trackingsrc/libs/telemetry/activeSpans.ts— span managementPlatforms:
Issue Owner
Current Issue Owner: @mallenexpensify