In React Navigation 7, how do you stop a user leaving a product-review screen with unsaved text, and what can still bypass that guard?

## Which event means "leaving" In **React Navigation 7**, a screen can lose the user's attention in two different ways: - it can **blur**, because another screen was pushed on top or another tab was selected, while staying mounted; - it can be **removed**, because a navigation action is about to take its route out of the navigator's state, after which it unmounts. Unsaved input is lost only in the second case, so the guard hangs off the **`beforeRemove`** event. React Navigation emits it, with the pending action in `e.data.action`, before any action that would remove the route: `goBack`, `pop`, `popTo`, `replace`, `reset` and their gesture and button equivalents. Calling `e.preventDefault()` cancels the action. ## usePreventRemove The hook wraps that event in a declarative API: ```tsx usePreventRemove(hasUnsavedText, ({ data }) => { Alert.alert('Discard your review?', 'Your text will be lost.', [ { text: 'Keep editing', style: 'cancel' }, { text: 'Discard', style: 'destructive', onPress: () => navigation.dispatch(data.action) }, ]); }); ``` What it does, step by step: 1. It registers the route as **prevented** with the navigator while the first argument is `true`. 2. It adds a `beforeRemove` listener that, when the flag is `true`, calls `preventDefault()` and passes `data.action` to the callback. 3. The callback decides; dispatching `data.action` replays the user's original intent, whether that was going back one screen or a reset to the home screen. The registration step matters on the **native stack**. The native stack reads the prevented routes and sets the iOS screen's native dismiss prevention, so the swipe-back gesture cannot finish natively, and it forces the header back button's long-press history menu off for that screen; setting `headerBackButtonMenuEnabled: true` on a prevented screen logs an error. A bare `beforeRemove` listener does not register the route, so on the native stack prefer the hook. ## Using the raw event The hook is built on a listener anyone can add directly: ```tsx useEffect(() => navigation.addListener('beforeRemove', (e) => { if (!hasUnsavedText) return; e.preventDefault(); confirmDiscard(() => navigation.dispatch(e.data.action)); }), [navigation, hasUnsavedText]); ``` That works on the JavaScript stack, but it does not register the route as prevented, so the native stack cannot block its iOS swipe or disable the back-button history menu ahead of time. The hook also keeps its listener pointing at the latest callback without re-subscribing on every render. Prefer the hook, and reach for the raw event only when you need the event object itself, for example to inspect `e.data.action.type` and allow some actions through. ## What the guard does not cover | Situation | Removal action? | Guard fires? | |---|---|---| | Header back button, swipe back, `goBack()` | yes | yes | | `reset` to the home screen after sign-out | yes | yes | | Pushing a photo picker screen on top | no | no | | Switching to another tab | no | no | | App sent to background or killed by the system | no | no | The screen stays mounted in the first two "no" rows, so the text survives. The last row is where users actually lose work: a review typed on a phone that is then locked for an hour may be gone when the process is killed. A robust screen therefore combines the guard with a **saved draft**, written as the user types or when the app goes to the background. ## The same-handler bug A frequent defect: after a successful submit, the handler clears the flag and navigates in one go. ```tsx const submit = async () => { await postReview(text); setText(''); navigation.goBack(); }; ``` The guard still blocks the `goBack()`, because the hook reads `preventRemove` from the **last render**, and the state update has not rendered yet. Fixes that work: - keep a `submitted` state and navigate in an effect after it turns `true`, when the guard is already off; - or derive the flag from data that is updated before navigation, so the render that removes the guard happens first. ## Good practice - Keep the condition precise: prevent removal only while there is text that differs from what was saved, otherwise users meet a pointless dialog. - Always offer both a way to stay and a way to leave; the leave path must dispatch `data.action`, not a hard-coded `goBack()`, or a blocked reset turns into a wrong navigation. - Do not use the guard to trap users; platform expectations are that back works.