react-router 8.4.0 → 8.5.1

package/dist/production/vendor/turbo-stream-v2/unflatten.js

@@ -1,5 +1,5 @@
 /**
- * react-router v8.4.0
+ * react-router v8.5.1
  *
  * Copyright (c) Remix Software Inc.
  *
@@ -50,6 +50,7 @@ function hydrate(index) {
 				set(-0);
 				continue;
 		}
+		validateIndex(index, values.length);
 		if (hydrated[index]) {
 			set(hydrated[index]);
 			continue;
@@ -121,11 +122,21 @@ function hydrate(index) {
 					set(obj);
 					continue;
 				case "P":
+					validateIndex(b, values.length);
 					if (hydrated[b]) set(hydrated[index] = hydrated[b]);
 					else {
 						const d = new Deferred();
+						const promise = d.promise;
+						promise.status = "pending";
+						promise.then((value) => {
+							promise.status = "fulfilled";
+							promise.value = value;
+						}, (reason) => {
+							promise.status = "rejected";
+							promise.reason = reason;
+						});
 						deferred[b] = d;
-						set(hydrated[index] = d.promise);
+						set(hydrated[index] = promise);
 					}
 					continue;
 				case "E":
@@ -135,6 +146,7 @@ function hydrate(index) {
 					set(error);
 					continue;
 				case "Z":
+					validateIndex(b, values.length);
 					set(hydrated[index] = hydrated[b]);
 					continue;
 				default:
@@ -185,7 +197,12 @@ function hydrate(index) {
 					r[0] = k;
 				}]);
 				postRun.push(() => {
-					object[r[0]] = r[1];
+					Object.defineProperty(object, r[0], {
+						value: r[1],
+						enumerable: true,
+						configurable: true,
+						writable: true
+					});
 				});
 			}
 			set(object);
@@ -195,5 +212,8 @@ function hydrate(index) {
 	while (postRun.length > 0) postRun.pop()();
 	return result;
 }
+function validateIndex(index, length) {
+	if (!Number.isSafeInteger(index) || index < 0 || index >= length) throw new SyntaxError();
+}
 //#endregion
 export { unflatten };

package/dist/production/vendor/turbo-stream-v2/utils.js

@@ -1,5 +1,5 @@
 /**
- * react-router v8.4.0
+ * react-router v8.5.1
  *
  * Copyright (c) Remix Software Inc.
  *

package/docs/explanation/backend-for-frontend.md

@@ -6,9 +6,6 @@ title: Backend For Frontend
 
 [MODES: framework]
 
-<br/>
-<br/>
-
 While React Router can serve as your fullstack application, it also fits perfectly into the "Backend for Frontend" architecture.
 
 The BFF strategy employs a web server with a job scoped to serving the frontend web app and connecting it to the services it needs: your database, mailer, job queues, existing backend APIs (REST, GraphQL), etc. Instead of your UI integrating directly from the browser to these services, it connects to the BFF, and the BFF connects to your services.

package/docs/explanation/code-splitting.md

@@ -6,9 +6,6 @@ title: Automatic Code Splitting
 
 [MODES: framework]
 
-<br/>
-<br/>
-
 When using React Router's framework features, your application is automatically code split to improve the performance of initial load times when users visit your application.
 
 ## Code Splitting by Route

package/docs/explanation/concurrency.md

@@ -6,9 +6,6 @@ title: Network Concurrency Management
 
 [MODES: framework, data]
 
-<br/>
-<br/>
-
 When building web applications, managing network requests can be a daunting task. The challenges of ensuring up-to-date data and handling simultaneous requests often lead to complex logic in the application to deal with interruptions and race conditions. React Router simplifies this process by automating network management while mirroring and expanding upon the intuitive behavior of web browsers.
 
 To help understand how React Router handles concurrency, it's important to remember that after `form` submissions, React Router will fetch fresh data from the `loader`s. This is called revalidation.

package/docs/explanation/hot-module-replacement.md

@@ -6,9 +6,6 @@ title: Hot Module Replacement
 
 [MODES: framework]
 
-<br/>
-<br/>
-
 Hot Module Replacement is a technique for updating modules in your app without needing to reload the page.
 It's a great developer experience, and React Router supports it when using Vite.
 

package/docs/explanation/lazy-route-discovery.md

@@ -6,9 +6,6 @@ title: Lazy Route Discovery
 
 [MODES: framework]
 
-<br/>
-<br/>
-
 Lazy Route Discovery is a performance optimization that loads route information progressively as users navigate through your application, rather than loading the complete route manifest upfront.
 
 With Lazy Route Discovery enabled (the default), React Router sends only the routes needed for the initial server-side render in the manifest. As users navigate to new parts of your application, additional route information is fetched dynamically and added to the client-side manifest.
@@ -76,3 +73,7 @@ When using lazy route discovery, ensure your deployment setup handles manifest r
 - **Route Handling** - Ensure `/__manifest` requests reach your React Router handler
 - **CDN Caching** - If using CDN/edge caching, include `version` and `paths` query parameters in your cache key for the manifest endpoint
 - **Multiple Applications** - Use a custom `manifestPath` if running multiple React Router applications on the same domain
+
+## Application-Controlled Discovery
+
+Use the experimental `unstable_useRouteDiscovery` hook to discover selected destinations, complete the route tree after startup, or control manifest-mismatch recovery. See [Application-Controlled Route Discovery](../how-to/route-discovery).

package/docs/explanation/progressive-enhancement.md

@@ -6,9 +6,6 @@ title: Progressive Enhancement
 
 [MODES: framework]
 
-<br/>
-<br/>
-
 > Progressive enhancement is a strategy in web design that puts emphasis on web content first, allowing everyone to access the basic content and functionality of a web page, whilst users with additional browser features or faster Internet access receive the enhanced version instead.
 >
 > <cite>- [Wikipedia][wikipedia]</cite>

package/docs/explanation/race-conditions.md

@@ -6,9 +6,6 @@ title: Race Conditions
 
 [MODES: framework, data]
 
-<br/>
-<br/>
-
 While impossible to eliminate every possible race condition in your application, React Router automatically handles the most common race conditions found in web user interfaces.
 
 ## Browser Behavior

package/docs/explanation/react-transitions.md

@@ -6,9 +6,6 @@ title: React Transitions
 
 [MODES: framework, data, declarative]
 
-<br/>
-<br/>
-
 [React 18][react-18] introduced the concept of "transitions" which allow you to differentiate urgent from non-urgent UI updates. To learn more about React Transitions and "concurrent rendering" Please refer to React's official documentation:
 
 - [What is Concurrent React][concurrent]

package/docs/explanation/sessions-and-cookies.md

@@ -59,28 +59,130 @@ The input/output to a session storage object are HTTP cookies. `getSession()` re
 
 You'll use methods to get access to sessions in your `loader` and `action` functions.
 
-After retrieving a session with `getSession`, the returned session object has a handful of methods and properties:
+### Session API
+
+After retrieving a session with `getSession()`, the returned session object has a handful of methods and properties:
 
 ```tsx
 export async function action({
   request,
-}: ActionFunctionArgs) {
+}: Route.ActionArgs) {
   const session = await getSession(
     request.headers.get("Cookie"),
   );
+
   session.get("foo");
   session.has("bar");
   // etc.
+
+  return redirect("/", {
+    headers: {
+      "Set-Cookie": await commitSession(session),
+    },
+  });
 }
 ```
 
-See the [Session API][session-api] for all methods available on the session object.
+<docs-warning>Every time you modify session data, you must `commitSession()` or your changes will be lost. When using cookie session storage, you must also send the `Set-Cookie` header it returns in your response.</docs-warning>
+
+See the [Session API][session-api] for all methods and properties available on the session object.
+
+#### `session.has(key)`
+
+Returns `true` if the session has a value (or an unread flash value) for the given `key`. This does not consume flash values.
+
+```ts
+session.has("userId");
+```
+
+#### `session.set(key, value)`
+
+Sets a session value for use in subsequent requests:
+
+```ts
+session.set("userId", "1234");
+```
+
+#### `session.flash(key, value)`
+
+Sets a session value that is only valid until the next `session.get()` for that key. After that, it's gone. Most useful for "flash messages" and server-side form validation messages:
+
+```ts
+session.flash(
+  "globalMessage",
+  "Project successfully archived",
+);
+```
+
+A flash value is typically set in an `action` before a redirect, then read in the `loader` of the page being redirected to:
+
+```tsx filename=app/routes/projects.tsx
+export async function action({
+  request,
+}: Route.ActionArgs) {
+  const session = await getSession(
+    request.headers.get("Cookie"),
+  );
+  // ...archive the project
+  session.flash(
+    "globalMessage",
+    "Project successfully archived",
+  );
+  return redirect("/projects", {
+    headers: {
+      "Set-Cookie": await commitSession(session),
+    },
+  });
+}
+
+export async function loader({
+  request,
+}: Route.LoaderArgs) {
+  const session = await getSession(
+    request.headers.get("Cookie"),
+  );
+  // Reading a flash value removes it from the session
+  const message = session.get("globalMessage");
+
+  return data(
+    { message },
+    {
+      headers: {
+        // Commit the session so the flash value is removed
+        "Set-Cookie": await commitSession(session),
+      },
+    },
+  );
+}
+```
+
+Flash values are read with `session.get()` using the same key they were set with. Reading a flash value removes it from the session, so you must still `commitSession()` after reading it; otherwise the flash value will be read again on the next request.
+
+Avoid using the same key for both `session.set()` and `session.flash()`. `session.get()` returns the regular value first, so the flash value would never be read or removed.
+
+You can type flash values separately from regular session values with the second generic on your session storage, like the `SessionFlashData` type in [Using Sessions](#using-sessions).
+
+#### `session.get(key)`
+
+Accesses a session value from a previous request:
+
+```ts
+session.get("name");
+```
+
+#### `session.unset(key)`
+
+Removes a value from the session. This does not remove pending flash values; those are only removed when read with `session.get()`.
+
+```ts
+session.unset("name");
+```
 
 ### Login form example
 
 A login form might look something like this:
 
-```tsx filename=app/routes/login.tsx lines=[4-7,12-14,16,22,25,33-35,46,51,56,61]
+```tsx filename=app/routes/login.tsx lines=[4-7,12-14,16,22-23,26,35-37,48-49,54,59,64]
 import { data, redirect } from "react-router";
 import type { Route } from "./+types/login";
 
@@ -102,6 +204,7 @@ export async function loader({
   }
 
   return data(
+    // Read and unset the flash message set by the route action.
     { error: session.get("error") },
     {
       headers: {
@@ -127,6 +230,7 @@ export async function action({
   );
 
   if (userId == null) {
+    // Set a single-use flash message to be read by the route loader.
     session.flash("error", "Invalid username/password");
 
     // Redirect back to the login page with errors.
@@ -220,7 +324,7 @@ React Router makes it easy to store sessions in your own database if needed. The
 - `createData` will be called from `commitSession` on the initial session creation when no session ID exists in the cookie
 - `readData` will be called from `getSession` when a session ID exists in the cookie
 - `updateData` will be called from `commitSession` when a session ID already exists in the cookie
-- `deleteData` is called from `destroySession`
+- `deleteData` is called from `destroySession` when the session has an ID
 
 The following example shows how you could do this using a generic database client:
 

package/docs/explanation/state-management.md

@@ -6,9 +6,6 @@ title: State Management
 
 [MODES: framework, data]
 
-<br/>
-<br/>
-
 State management in React typically involves maintaining a synchronized cache of server data on the client side. However, when using React Router as your framework, most of the traditional caching solutions become redundant because of how it inherently handles data synchronization.
 
 ## Understanding State Management in React

package/docs/explanation/styling.md

@@ -6,9 +6,6 @@ title: Styling
 
 [MODES: framework]
 
-<br/>
-<br/>
-
 Framework mode uses the React Router Vite plugin, so the styling story is mostly just Vite's styling story.
 
 React Router does not have a separate CSS pipeline for Framework mode. In practice, there are three patterns that matter:

package/docs/explanation/type-safety.md

@@ -6,9 +6,6 @@ title: Type Safety
 
 [MODES: framework]
 
-<br/>
-<br/>
-
 If you haven't done so already, check out our guide for [setting up type safety][route-module-type-safety] in a new project.
 
 React Router generates types for each route in your app to provide type safety for the route module exports.

package/docs/how-to/accessibility.md

@@ -12,9 +12,6 @@ React Router makes certain accessibility practices the default where possible an
 
 [MODES: framework, data, declarative]
 
-<br/>
-<br/>
-
 The [`<Link>` component][link] renders a standard anchor tag, meaning that you get its accessibility behaviors from the browser for free!
 
 React Router also provides the [`<NavLink/>`][navlink] which behaves the same as `<Link>`, but it also provides context for assistive technology when the link points to the current page. This is useful for building navigation menus or breadcrumbs.
@@ -23,9 +20,6 @@ React Router also provides the [`<NavLink/>`][navlink] which behaves the same as
 
 [MODES: framework]
 
-<br/>
-<br/>
-
 If you are rendering [`<Scripts>`][scripts] in your app, there are some important things to consider to make client-side routing more accessible for your users.
 
 With a traditional multi-page website we don't have to think about route changes too much. Your app renders an anchor tag, and the browser handles the rest. If your users disable JavaScript, your React Router app should already work this way by default!

package/docs/how-to/client-data.md

@@ -6,9 +6,6 @@ title: Client Data
 
 [MODES: framework]
 
-<br/>
-<br/>
-
 You can fetch and mutate data directly in the browser using `clientLoader` and `clientAction` functions.
 
 These functions are the primary mechanism for data handling when using [SPA mode][spa]. This guide demonstrates common use cases for leveraging client data in Server-Side Rendering (SSR).

package/docs/how-to/custom-fetch.md

@@ -0,0 +1,218 @@
+---
+title: Custom Fetch
+unstable: true
+---
+
+# Custom Fetch
+
+[MODES: framework]
+
+<docs-warning>This feature is experimental and may change in minor or patch releases. It is not supported in RSC Framework Mode.</docs-warning>
+
+The `unstable_fetch` prop on [`HydratedRouter`](../api/framework-routers/HydratedRouter) lets you customize the JavaScript-issued requests React Router makes for server loader/action data and lazy route discovery. Use it to add headers, customize fetch options, or apply a request policy based on the operation that initiated the request.
+
+This is a Framework Mode API. In Data Mode, you control fetching in your loaders/actions or through a [`dataStrategy`](./data-strategy#request-metadata-unstable).
+
+## Setup
+
+If you don't have an [`app/entry.client.tsx`](../api/framework-conventions/entry.client.tsx), reveal the default entry:
+
+```shellscript nonumber
+npx react-router reveal entry.client
+```
+
+Pass a custom implementation to `HydratedRouter`:
+
+```tsx filename=app/entry.client.tsx
+import { startTransition, StrictMode } from "react";
+import { hydrateRoot } from "react-dom/client";
+import {
+  HydratedRouter,
+  type unstable_RouterFetch,
+} from "react-router/dom";
+
+const customFetch: unstable_RouterFetch = (
+  request,
+  context,
+) => {
+  console.log(context.type, request.method, request.url);
+  return fetch(request);
+};
+
+startTransition(() => {
+  hydrateRoot(
+    document,
+    <StrictMode>
+      <HydratedRouter unstable_fetch={customFetch} />
+    </StrictMode>,
+  );
+});
+```
+
+The callback receives a constructed `Request`, including its URL, headers, body, and abort signal, and must return a `Promise<Response>`. Pass that request to the browser's `fetch` to preserve those settings, including cancellation.
+
+`HydratedRouter` creates a singleton router and reads `unstable_fetch` only during initialization. Changing the prop later has no effect. If your implementation needs changing values such as authentication tokens, read current application state inside the callback instead of capturing values from a component render.
+
+## Request Context
+
+The [`unstable_RouterFetchContext`](https://api.reactrouter.com/v8/types/react-router.dom.unstable_RouterFetchContext.html) type is exported from `react-router/dom` and has the following shape:
+
+```ts
+import type { NavigationType } from "react-router";
+
+type unstable_RouterFetchContext =
+  | { type: "manifest" }
+  | {
+      type: "navigation";
+      fetcherKey: string | null;
+      navigationType: NavigationType;
+    }
+  | {
+      type: "initialization" | "fetcher" | "revalidation";
+      fetcherKey: string | null;
+      navigationType: null;
+    };
+```
+
+`type` identifies the operation that initiated the request:
+
+- `"manifest"`: Lazy route discovery requests. These have no `fetcherKey` or `navigationType`.
+- `"initialization"`: Data loading during router initialization, such as initial loader requests in API-only Mode.
+- `"navigation"`: Data requests initiated by a navigation, including action submissions and the subsequent loader revalidation.
+- `"fetcher"`: Requests initiated by a fetcher, including the loader revalidation after a fetcher action.
+- `"revalidation"`: Requests initiated by an explicit revalidation, such as `useRevalidator().revalidate()`.
+
+`fetcherKey` identifies the fetcher targeted by a data request, or is `null` for route loader/action requests. A fetcher reloaded as part of a navigation or explicit revalidation retains that initiating `type` and also includes its fetcher key. Fetchers reloaded after an initialization redirect likewise retain the `"initialization"` type and include their fetcher key.
+
+`navigationType` is `"PUSH"`, `"REPLACE"`, or `"POP"` for navigation-initiated data requests, including fetchers reloaded by that navigation. It is `null` for initialization, standalone fetcher operations, and explicit revalidation. This is the history action for the in-flight navigation, not the previously committed location.
+
+## Examples
+
+Each example below can be passed to `HydratedRouter` as its `unstable_fetch` prop.
+
+### Authentication and Custom Headers
+
+Read the current token at request time so token changes don't require replacing the callback:
+
+```ts
+import type { unstable_RouterFetch } from "react-router/dom";
+import { authStore } from "./auth";
+
+const customFetch: unstable_RouterFetch = (request) => {
+  let headers = new Headers(request.headers);
+  let token = authStore.getAccessToken();
+
+  if (token) {
+    headers.set("Authorization", `Bearer ${token}`);
+  }
+
+  headers.set("X-App-Version", "1.0");
+  return fetch(request, { headers });
+};
+```
+
+Here, `authStore` is your application's authentication store. Only send credentials to trusted origins. Adding custom headers to cross-origin requests may require a CORS preflight and corresponding server configuration.
+
+### Cross-Origin Credentials
+
+In [API-only Mode](../start/framework/rendering#using-a-separate-api-origin), use `unstable_apiServerOrigin` to configure a separate API origin. React Router applies that origin before calling your custom fetch, and also uses it for native data prefetches.
+
+The origin setting does not enable cross-origin cookies. If you need them, customize the credential policy for the trusted API origin:
+
+```ts
+import type { unstable_RouterFetch } from "react-router/dom";
+
+const customFetch: unstable_RouterFetch = (request) => {
+  let isApiRequest =
+    new URL(request.url).origin ===
+    "https://api.example.com";
+
+  return fetch(request, {
+    credentials: isApiRequest
+      ? "include"
+      : request.credentials,
+  });
+};
+```
+
+The API server must allow credentialed CORS requests from your client origin. Browser cookie policies still apply. Native data prefetches do not use this callback, so don't rely on it to configure their credentials.
+
+### Back/Forward Traversal Cache
+
+Use `navigationType` to prefer the browser's HTTP cache when navigating back or forward, while retaining the normal cache policy for other requests:
+
+```ts
+import type { unstable_RouterFetch } from "react-router/dom";
+
+const customFetch: unstable_RouterFetch = (
+  request,
+  context,
+) => {
+  let isTraversal =
+    import.meta.env.PROD &&
+    request.method === "GET" &&
+    context.type === "navigation" &&
+    context.navigationType === "POP";
+
+  return fetch(request, {
+    cache: isTraversal ? "force-cache" : "default",
+  });
+};
+```
+
+This example enables the policy in production only. It includes GET requests for fetchers reloaded by a back/forward navigation, but not standalone fetcher loads or explicit revalidations.
+
+The [`force-cache` policy](https://fetch.spec.whatwg.org/#concept-request-cache-mode) uses a matching HTTP cache entry even if it is stale, falling back to the network when no entry exists. Your server's responses must be cacheable; `Cache-Control: no-store` responses aren't stored.
+
+This is not a router-managed data cache. React Router still performs its request and response decoding, and this policy adds no mutation or authentication invalidation guarantees. Only use it when serving potentially stale data is appropriate for your application.
+
+### Retrying Safe Requests
+
+You can retry a safe GET after a network failure without retrying action submissions or canceled requests:
+
+```ts
+import type { unstable_RouterFetch } from "react-router/dom";
+
+const customFetch: unstable_RouterFetch = async (
+  request,
+) => {
+  if (request.method !== "GET") {
+    return fetch(request);
+  }
+
+  try {
+    return await fetch(request.clone());
+  } catch (error) {
+    if (
+      request.signal.aborted ||
+      (error instanceof Error &&
+        error.name === "AbortError")
+    ) {
+      throw error;
+    }
+
+    // Retry once, retaining the original abort signal.
+    return fetch(request);
+  }
+};
+```
+
+This assumes your GET endpoints are safe to repeat. It retries a rejected fetch, not HTTP error responses such as `500`. Don't automatically retry mutations: the server may have processed an action even when the client didn't receive its response.
+
+## Limitations
+
+### Requests Outside Custom Fetch
+
+Custom fetch does not intercept the initial document request, server-side loader execution, static assets, or fetches you write in your own application code, including in `clientLoader`/`clientAction`. Calls to their `serverLoader`/`serverAction` helpers do use custom fetch when they issue server data requests.
+
+Data prefetches from `<Link prefetch>`, `<NavLink prefetch>`, and [`PrefetchPageLinks`](../api/components/PrefetchPageLinks) use native `<link rel="prefetch">` elements and bypass custom fetch. If a request requires custom headers or other transformations, use `prefetch="none"` on links and avoid rendering `PrefetchPageLinks` for those routes.
+
+### Inspecting Request Bodies
+
+If you need a form field such as `intent` to choose request headers, read it from `await request.clone().formData()` for form-encoded submissions, then send the original request. Reading `request.formData()` directly consumes the body so it can't subsequently be sent unchanged.
+
+Only parse bodies with a compatible encoding. Cloning and reading a body can buffer data, so avoid doing this unnecessarily, especially for large file uploads. Adding headers or changing fetch options does not require reading the body.
+
+### Response Compatibility
+
+Return the response from `fetch` unchanged. You can inspect its status and headers, but you should not consume its body or try to decode, modify, or re-encode it. React Router handles response decoding and expects its manifest/data protocol, including Turbo Stream-encoded loader/action data.

package/docs/how-to/data-strategy.md

@@ -6,9 +6,6 @@ title: Data Strategy
 
 [MODES: data]
 
-<br />
-<br />
-
 <docs-warning>This is a low-level API intended for advanced use-cases. This overrides React Router's internal handling of `action`/`loader` execution, and if done incorrectly will break your app code. Please use with caution and perform the appropriate testing.</docs-warning>
 
 ## Overview
@@ -23,7 +20,9 @@ A custom `dataStrategy` receives the `loader`/`action` arguments (`request`, `pa
 
 - `matches`: An array of `DataStrategyMatch` instances for the routes matched by the current `request`
 - `runClientMiddleware`: A helper function to run the middleware for the matched routes
-- `fetcherKey`: The fetcher key if this is for a fetcher request and not a navigation
+- `fetcherKey`: The key of the fetcher targeted by this execution, or `null` for route loader/action executions. Fetchers reloaded by a navigation or explicit revalidation also provide their key.
+- `unstable_initiator`: The operation that initiated this execution (see [Request Metadata](#request-metadata-unstable))
+- `unstable_navigationType`: The history action for a navigation-initiated execution, or `null` for other executions
 
 A `DataStrategyMatch` is a normal route match plus a few additional fields:
 
@@ -77,6 +76,26 @@ interface DataStrategyResult {
 }
 ```
 
+### Request Metadata (unstable)
+
+<docs-warning>`unstable_initiator` and `unstable_navigationType` are experimental and may change in minor or patch releases.</docs-warning>
+
+`unstable_initiator` identifies why the data strategy is running:
+
+- `"initialization"`: Initial router data loading
+- `"navigation"`: A navigation, including action submissions and subsequent loader revalidation
+- `"fetcher"`: A fetcher operation, including loader revalidation after a fetcher action
+- `"revalidation"`: Explicit revalidation, such as `useRevalidator().revalidate()`
+- `"static"`: Execution by `createStaticHandler` on the server
+
+Requests that reload fetchers during a navigation or explicit revalidation retain that initiator while providing the targeted `fetcherKey`. Don't use `fetcherKey` alone to determine what initiated the execution.
+
+`unstable_navigationType` is `"PUSH"`, `"REPLACE"`, or `"POP"` for navigation-initiated executions, including fetchers reloaded by that navigation. It is `null` for initialization, standalone fetcher operations, explicit revalidation, and static handler executions. It describes the in-flight navigation rather than the previously committed location.
+
+You can use this metadata to choose a loading or caching policy. For example, a Data Mode `dataStrategy` can distinguish back/forward navigations with `unstable_initiator === "navigation" && unstable_navigationType === "POP"`. Your strategy remains responsible for executing the appropriate handlers and returning their results.
+
+Framework Mode exposes equivalent request metadata through [`unstable_fetch`](./custom-fetch#request-context), which customizes server requests without replacing loader/action execution.
+
 ### Calling Route Middleware
 
 If you are using `middleware` on your routes, you need to leverage the `callClientMiddleware` helper function to execute `middleware` around your handlers:

package/docs/how-to/error-boundary.md

@@ -6,9 +6,6 @@ title: Error Boundaries
 
 [MODES: framework, data]
 
-<br/>
-<br/>
-
 To avoid rendering an empty page to users, route modules will automatically catch errors in your code and render the closest `ErrorBoundary`.
 
 Error boundaries are not intended for rendering form validation errors or error reporting. Please see [Form Validation](./form-validation) and [Error Reporting](./error-reporting) instead.