Returning from a WebView: handing off data and navigation intent
Separate page visibility, data synchronization and workflow advancement to reason about delayed messages, duplicate callbacks and stale actions in Mini Programs.
Exploration · Principles and possible approaches inspired by a project context.
- uni-app
- Mini Programs
- WebView
- Lifecycle
Related project: Custom furniture design and quotation system. Local code already synchronizes WebView data and consumes a pending action when the parent page resumes. Identity and deduplication below are further design analysis.
A visible page does not prove a completed handoff
Returning to a Mini Program does not automatically establish that its data is current or that the next step is valid. Advancing on every page-show event confuses ordinary back navigation with an explicit continue action.
Check when messages are delivered
Mini Program WebView messaging is not equivalent to an iframe callback. The uni-app web-view documentation describes delivery at particular lifecycle moments; behavior needs checking for the target platform.
Observe page restoration, message receipt and data application as separate events before choosing an execution point.
Identify the handoff
An extended contract could identify the draft, the particular WebView opening, the requested action and the data revision. This distinguishes a current handoff from an old page’s message or a duplicate notification.
These fields are proposed protocol work. A consumer cannot reliably deduplicate by an action ID that the existing sender never provides.
Synchronize, validate and consume
Validate message structure and ownership, apply allowed data, check the requested transition, then handle the action and update its pending state.
Clearing an action before navigation needs recovery if navigation fails. Clearing afterward needs protection against duplicate execution. Choosing an order alone does not guarantee exactly-once effects.
Back and continue mean different things
Ordinary system back, explicit previous and explicit next require distinct behavior. Without a valid action, use normal return behavior. With incomplete data, stop somewhere the user can correct it.
Process restart can erase in-memory pending state. Persistence, expiry and ownership checks depend on the desired recovery behavior.
Verify in the target host
Exercise delayed and duplicate messages, an old WebView instance, navigation failure, ordinary back and process reentry. Inspect data, workflow position and action consumption separately.
H5 tests can validate handlers but cannot establish Mini Program WebView delivery order.