In a React Router v7 settings area, a Back button and the post-save redirect both call navigate(-1); what breaks for deep-linked users, and how do you fix it?

## The scenario A nested settings area has a read-only profile page at `/settings/profile` and an edit form at `/settings/profile/edit`. The form has a **Back** button, and after a successful save the form also returns the user. Both were implemented as: ```tsx const navigate = useNavigate(); <button onClick={() => navigate(-1)}>Back</button> // ...after save: await saveProfile(values); navigate(-1); ``` In testing this works, because testers always arrive at the form by clicking **Edit** on the profile page. ## What breaks `navigate(-1)` delegates to the browser's history (`history.go(-1)`). It does not know where "back" should be inside the app; it goes to whatever entry precedes the current one. That fails in three common situations: 1. **Deep link or bookmark**: the user opens `/settings/profile/edit` directly. The previous entry is the page they came from, possibly another site, or there is none. Back leaves the app or does nothing. 2. **New tab**: the form was opened with Cmd-click from the profile page. The new tab's history starts at the form, so Back does nothing. 3. **Arrival from elsewhere in the app**: the user reached the form from a notification link on the dashboard. Back after save returns them to the dashboard rather than the profile they just edited, which may be acceptable or not, depending on the product. The React Router docs say it directly: be cautious with `navigate(number)`, because there may be no entry to go back to, or it may go somewhere unexpected; only use it when you are sure the entry exists. ## Detecting "no in-app history" Every React Router location has a `key`. The first location of a fresh page load gets the key `"default"`; every entry the router pushes or replaces gets a generated key stored in `history.state`. That gives a practical test: - `location.key !== "default"`: this entry was created by in-app navigation, so the previous entry is very likely in the app; - `location.key === "default"`: the user landed here from outside, so going back would leave. It is a heuristic. For example, a user who lands on the profile page and moves to the form through a `replace` navigation gets a generated key on the form entry, yet the entry before it is still outside the app. It is still the signal React Router itself provides for this, and it covers bookmarks, shared links and new tabs. ## The fix Wrap the decision in one hook and use it for both buttons: ```tsx function useGoBack(fallback: string) { const navigate = useNavigate(); const location = useLocation(); return () => location.key !== "default" ? navigate(-1) : navigate(fallback, { replace: true }); } ``` - **Back button**: `const goBack = useGoBack("/settings/profile")`. In-app users get a true browser Back; deep-linked users land on the profile page instead of leaving. - **Post-save**: call the same `goBack()` after `await saveProfile(...)`. Popping back returns to the entry the user came from, leaving the form only as a Forward entry that disappears on their next navigation; the fallback **replaces** the form entry, so pressing Back from the profile page does not reopen a form that was already submitted. Why not always `navigate("/settings/profile")` after saving? A **push** leaves the history as profile → edit → profile, so Back from the fresh profile page reopens the edit form showing the pre-save values. Using `{ replace: true }` on the fallback avoids that. ## Checklist for review - No `navigate(-1)` without a fallback on any screen that can be deep-linked. - Post-mutation navigations either pop back or **replace** the form entry. - The fallback is a real in-app route, preferably the logical parent. - Test by opening the form URL in a fresh tab, not only by clicking through. ## Approaches that look simpler and fail - **`window.history.length > 1`.** The length counts entries from other sites in the same tab, so it is above 1 for a user who arrived from a search engine; it cannot tell in-app history from outside history. - **`document.referrer`.** It is empty for bookmarks and typed URLs, often stripped by referrer policies, and does not change on client-side navigations, so it describes the first document load rather than the in-app path. - **Always navigating to a fixed parent.** Correct for deep links, but it discards the real in-app Back for users who came from somewhere else, such as a dashboard notification. - **Storing a custom back stack in a global store.** It duplicates what browser history already records and drifts from it as soon as the user presses the browser's own Back or Forward buttons. ## Summary - `navigate(-1)` follows browser history, which may point outside the app. - `location.key === "default"` marks a fresh landing. - Go back when the key says you can; otherwise navigate to a parent route with `replace`.