react-router 8.3.1 → 8.5.0

package/docs/how-to/optimize-revalidation.md

@@ -1,12 +1,185 @@
 ---
 title: Revalidation Optimization
-hidden: true
 ---
 
-[copy pasted]
+# Revalidation Optimization
 
-During client-side transitions, React Router will optimize reloading of routes that are already rendering, like not reloading layout routes that aren't changing. In other cases, like form submissions or search param changes, React Router doesn't know which routes need to be reloaded, so it reloads them all to be safe. This ensures your UI always stays in sync with the state on your server.
+[MODES: framework, data]
 
-This function lets apps further optimize by returning `false` when React Router is about to reload a route. If you define this function on a route module, React Router will defer to your function on every navigation and every revalidation after an action is called. Again, this makes it possible for your UI to get out of sync with your server if you do it wrong, so be careful.
+<br/>
+<br/>
 
-`fetcher.load` calls also revalidate, but because they load a specific URL, they don't have to worry about route param or URL search param revalidations. `fetcher.load`'s only revalidate by default after action submissions and explicit revalidation requests via [`useRevalidator`][use-revalidator].
+After a mutation or some navigations, React Router re-runs loaders so
+the UI stays in sync with the server. That default is the right
+starting point. When a loader is expensive, or a mutation cannot
+affect that route's data, you can skip the reload.
+
+<docs-warning>
+Skipping revalidation can leave the UI out of sync with the server.
+Prefer targeting a specific action or navigation, and fall back to
+`defaultShouldRevalidate` instead of always returning `false`.
+</docs-warning>
+
+## Default behavior
+
+The default behavior differs between Framework and Data Modes:
+
+- **Framework Mode with SSR**
+  - Defaults to opt-out behavior - active loaders are revalidated on navigations and successful submissions ([`Link`][link], [`Form`][form], [`fetcher.submit`][use-fetcher])
+  - Failed submissions returning a 4xx/5xx status do not trigger revalidations by default
+- **Framework "SPA Mode" and Data Mode**
+  - Defaults to opt-out behavior on successful submissions - active loaders are revalidated on successful submissions ([`Form`][form], [`fetcher.submit`][use-fetcher])
+    - Failed submissions returning a 4xx/5xx status do not trigger revalidations by default
+  - Defaults to opt-in behavior for GET navigations ([`Link`][link]) - active loaders are only revalidated if their dynamic params changed, or if any search params changed
+    - A GET navigation to the _exact_ same URL is treated like a page refresh and all loaders are revalidated.
+
+Matched matched routes are handled independently - A child that skips
+revalidation does not skip any ancestor routes.
+
+[`fetcher.load`][use-fetcher] only revalidates by default after action
+submissions and explicit [`useRevalidator`][use-revalidator] calls, not
+on search-param or param-driven navigations.
+
+A plain `fetch()` to a [resource route][resource-routes] does not
+go through the router, so it does not revalidate loaders.
+
+## Skip a route with `shouldRevalidate`
+
+Export `shouldRevalidate` from the [route module][route-module]
+(Framework Mode) or set it on the [route object][data-mode]
+(Data Mode). Returning `false` skips **that route's** loader.
+
+```tsx filename=app/routes/dashboard.tsx
+// Framework Mode
+export function shouldRevalidate() {
+  return false;
+}
+```
+
+```tsx src/main.tsx
+// Data Mode
+createBrowserRouter([
+  {
+    path: "/dashboard",
+    loader: dashboardLoader,
+    shouldRevalidate: () => false,
+    Component: Dashboard,
+  },
+]);
+```
+
+Always returning `false` opts that route out of the default
+behavior completely, including cases you usually still want
+(param changes, explicit [`useRevalidator`][use-revalidator]).
+Prefer the conditional form below.
+
+## Opt out of specific requests
+
+Inspect
+[`ShouldRevalidateFunctionArgs`][should-revalidate-args]
+and return `defaultShouldRevalidate` for everything else.
+
+```tsx
+import type { ShouldRevalidateFunctionArgs } from "react-router";
+
+export function shouldRevalidate({
+  formMethod,
+  formAction,
+  defaultShouldRevalidate,
+}: ShouldRevalidateFunctionArgs) {
+  if (
+    formMethod === "POST" &&
+    formAction?.endsWith("/analytics")
+  ) {
+    return false;
+  }
+
+  return defaultShouldRevalidate;
+}
+```
+
+Other useful fields:
+
+- `formData`, `json`, `text` — the submission body
+- `actionResult`, `actionStatus` — the action's return value
+- `currentUrl`, `nextUrl`, `currentParams`, `nextParams` —
+  the navigation
+
+You can ignore search-param-only updates while still
+revalidating when the pathname changes:
+
+```tsx
+export function shouldRevalidate({
+  currentUrl,
+  nextUrl,
+  defaultShouldRevalidate,
+}: ShouldRevalidateFunctionArgs) {
+  if (currentUrl.pathname === nextUrl.pathname) {
+    return false;
+  }
+
+  return defaultShouldRevalidate;
+}
+```
+
+## Skip revalidation for one event
+
+Pass `defaultShouldRevalidate={false}` at the call site so you
+do not have to change every route file. This works on
+[`<Form>`][form], [`<Link>`][link], `<fetcher.Form>`, and as an
+option to [`useSubmit`][use-submit], `fetcher.submit`,
+[`useNavigate`][use-navigate], and
+[`useSearchParams`][use-search-params].
+
+```tsx
+import { Form, Link } from "react-router";
+
+<Link
+  to="/search?q=shoes"
+  defaultShouldRevalidate={false}
+>
+  Search Shoes
+</Link>
+
+<Form
+  method="post"
+  action="/analytics"
+  defaultShouldRevalidate={false}
+>
+  <button>Track Click</button>
+</Form>
+```
+
+```tsx
+fetcher.submit(
+  { intent: "save-progress" },
+  {
+    method: "post",
+    action: "/save-progress",
+    defaultShouldRevalidate: false,
+  },
+);
+```
+
+If a matched route does **not** export `shouldRevalidate`, this
+value is used directly for that loader. If it **does** export
+`shouldRevalidate`, the value is passed in as
+`defaultShouldRevalidate` and the route still has the final say.
+
+That is why a child `shouldRevalidate` that always returns
+`false` cannot hide a root reload after `fetcher.submit`. Either
+also opt `root` out for that case, or pass
+`defaultShouldRevalidate: false` at the call site when `root`
+has no `shouldRevalidate` of its own.
+
+[data-mode]: ../start/data/route-object#shouldrevalidate
+[form]: ../api/components/Form
+[link]: ../api/components/Link
+[resource-routes]: ./resource-routes
+[route-module]: ../start/framework/route-module#shouldrevalidate
+[should-revalidate-args]: https://api.reactrouter.com/v8/interfaces/react-router.ShouldRevalidateFunctionArgs.html
+[use-fetcher]: ../api/hooks/useFetcher
+[use-navigate]: ../api/hooks/useNavigate
+[use-revalidator]: ../api/hooks/useRevalidator
+[use-search-params]: ../api/hooks/useSearchParams
+[use-submit]: ../api/hooks/useSubmit

package/docs/how-to/pre-rendering.md

@@ -84,10 +84,11 @@ export default {
 
 ## Pre-Rendering with/without a Runtime Server
 
-Pre-Rendering can be used in two ways based on the `ssr` config value:
+Pre-Rendering can be used with these `ssr` config values:
 
 - Alongside a runtime SSR server with `ssr:true` (the default value)
 - Deployed to a static file server with `ssr:false`
+- Alongside a runtime API server with `ssr:"unstable_api-only"` (experimental)
 
 ### Pre-rendering with `ssr:true`
 
@@ -223,3 +224,24 @@ When pre-rendering with `ssr:false`, React Router will error at build time if yo
   - If you are using a `loader` on a pre-rendered route that has child routes, you will need to make sure the parent `loaderData` can be determined at run-time properly by either:
     - Pre-rendering all child routes so that the parent `loader` can be called at build-time for each child route path and rendered into a `.data` file, or
     - Use a `clientLoader` on the parent that can be called at run-time for non-pre-rendered child paths
+
+### Pre-rendering with API-only Mode (unstable)
+
+<docs-warning>API-only Mode is experimental and may change in minor or patch releases. It is not supported in RSC Framework Mode.</docs-warning>
+
+Use `ssr: "unstable_api-only"` with `prerender` to generate documents at build time while keeping a runtime server for loaders, actions, and route discovery:
+
+```ts filename=react-router.config.ts
+import type { Config } from "@react-router/dev/config";
+
+export default {
+  ssr: "unstable_api-only",
+  prerender: ["/"],
+} satisfies Config;
+```
+
+Document generation follows the same behavior as `ssr:false`: selected paths produce HTML and `.data` files, and other paths use a SPA fallback. The fallback is `__spa-fallback.html` when `/` is prerendered, or `index.html` otherwise.
+
+Prerendered pages hydrate using their build-time data. Pages using the fallback fetch server loader data during initialization. Server loaders and actions are available on all routes, including those outside the prerender list, and normal loader revalidation remains enabled.
+
+See [API-only Mode](../start/framework/rendering#api-only-mode-unstable) for deployment routing and configuring a separate API origin.

package/docs/how-to/react-server-components.md

@@ -498,16 +498,39 @@ Using Server Components in loaders can be helpful for incremental adoption of RS
 
 [Server Functions][react-server-functions-doc] are a React feature that allow you to call async functions executed on the server. They're defined with the [`"use server"`][use-server-docs] directive.
 
+<docs-warning>
+
+Treat every Server Function as a public endpoint. The client controls both the
+Server Function identifier and request URL, so do not rely on route middleware
+for authentication or authorization. Server Functions must perform their own
+access control and input validation; use a route `action` when access control
+should be middleware-driven.
+
+</docs-warning>
+
 ```tsx
 "use server";
 
+import { unstable_getRequest as getRequest } from "react-router";
+import { requireUser } from "./auth.ts";
+
 export async function updateFavorite(formData: FormData) {
-  let movieId = formData.get("id");
+  let user = await requireUser(getRequest());
+  let movieId = Number(formData.get("id"));
   let intent = formData.get("intent");
+
+  if (
+    !Number.isSafeInteger(movieId) ||
+    movieId <= 0 ||
+    (intent !== "add" && intent !== "remove")
+  ) {
+    throw new Error("Invalid form submission");
+  }
+
   if (intent === "add") {
-    await addFavorite(Number(movieId));
+    await addFavorite(user.id, movieId);
   } else {
-    await removeFavorite(Number(movieId));
+    await removeFavorite(user.id, movieId);
   }
 }
 ```

package/docs/how-to/resource-routes.md

@@ -66,6 +66,8 @@ export function action(_: Route.ActionArgs) {
 }
 ```
 
+Calling this `action` through [`<Form>`][form] or [`useFetcher`][fetcher] still revalidates matched UI loaders. A plain `fetch()` to the resource URL does not. See [Revalidation Optimization][optimize-revalidation] for more info.
+
 ## Return Types
 
 Resource Routes are flexible when it comes to the return type - you can return [`Response`][Response] instances or [`data()`][data] objects. A good general rule of thumb when deciding which type to use is:
@@ -124,3 +126,4 @@ export function action() {
 [form]: ../api/components/Form
 [await]: ../api/components/Await
 [error-boundary]: ../start/framework/route-module#errorboundary
+[optimize-revalidation]: ./optimize-revalidation

package/docs/how-to/route-discovery.md

@@ -0,0 +1,145 @@
+---
+title: Application-Controlled Route Discovery
+unstable: true
+---
+
+# Application-Controlled Route Discovery
+
+[MODES: framework]
+
+<docs-warning>This API is unstable and may change without a major release. It supports conventional Framework Mode; RSC modes are not supported.</docs-warning>
+
+Enable the future flag in `react-router.config.ts`:
+
+```ts
+import type { Config } from "@react-router/dev/config";
+
+export default {
+  future: { unstable_customRouteDiscovery: true },
+} satisfies Config;
+```
+
+Without this flag, React Router keeps its existing discovery implementation and the hook is unavailable. The flag supports conventional Framework Mode only.
+
+Keep `routeDiscovery.mode: "lazy"` (the default for SSR) and use `unstable_useRouteDiscovery` to choose when to discover destinations or load the complete route manifest.
+
+```tsx
+let { state, discoverRoutes, loadAllRoutes } =
+  unstable_useRouteDiscovery({
+    onManifestMismatch: async (event) => {
+      // Handle mismatch, potentially by loading the entire manifest
+      await loadAllRoutes();
+    },
+  });
+
+// state: "partial" | "loading" | "complete"
+
+// Eagerly discover specific paths
+let result = await discoverRoutes(paths);
+```
+
+## Imperative Route Discovery
+
+You can control route discovery through `discoverRoutes()` without having to render links/forms on the page - this allows you to eagerly discover routes that are not directly linked from the current UI. Note that discovery only loads route metadata - it does not navigate, run loaders/actions, or prefetch route modules/stylesheets. Paths are batched within the manifest request URL limit and previously discovered paths are skipped.
+
+`discoverRoutes(paths, { signal })` accepts application-root paths beginning with `/`. React Router applies the configured `basename` and ignores query strings and hashes. Relative paths and external URLs are not supported.
+
+The result is `{ type: "success" }`, `{ type: "version-mismatch" }`, or `{ type: "aborted" }`. Success means the discovery operation completed successfully; it does not guarantee that a request was sent or that each pathname matches a route. Cached paths need no request, and a concurrent full-manifest load can supersede an incremental request failure. Unrecovered request failures and unrelated handler errors reject. Imperative mismatches do not automatically trigger a reload.
+
+For example, the cart's checkout link automatically discovers the shipping route. Use the hook to discover later checkout steps when the cart mounts, even though those steps aren't linked from the cart:
+
+```tsx
+import { useEffect } from "react";
+import {
+  Link,
+  unstable_useRouteDiscovery,
+} from "react-router";
+
+function Cart() {
+  let { discoverRoutes } = unstable_useRouteDiscovery();
+
+  useEffect(() => {
+    let controller = new AbortController();
+
+    discoverRoutes(
+      ["/checkout/billing", "/checkout/review"],
+      { signal: controller.signal },
+    ).catch(console.error);
+
+    return () => controller.abort();
+  }, [discoverRoutes]);
+
+  return (
+    <>
+      {/* Render cart items and totals here. */}
+      <Link to="/checkout/shipping">
+        Proceed to checkout
+      </Link>
+    </>
+  );
+}
+```
+
+## Completing discovery
+
+`loadAllRoutes()` loads the running client's versioned manifest asset to complete its route tree, even if that client is stale. This merges all missing routes into the running router and thus prevents further incremental discovery. The exposed `version` remains the version of the running client. With `routeDiscovery.mode: "initial"`, SPA Mode, or development's full manifest, the state is already `complete` and the operations are successful no-ops.
+
+The shared `state` moves from `partial` to `loading` to `complete`. Concurrent calls share a load, and calls after completion resolve immediately. Failures reject and return the state to `partial`; applications can catch the error and choose whether to reload.
+
+Retain the client's versioned manifest **and its referenced assets** for as long as that client is supported. Server routing and loader/action contracts must also remain compatible. Loading build A's manifest does not make an incompatible build B backend safe for build A's client.
+
+## Handling manifest mismatches
+
+You can provide custom handling for manifest version mismatches to avoid hard reloads, giving you a chance to complete the route tree, or cancel the navigation and provide a prompt for the user to reload (see below). A mismatch indicates different versions, not which version is newer.
+
+```tsx
+unstable_useRouteDiscovery({
+  onManifestMismatch: async (event) => {
+    await event.loadAllRoutes();
+  },
+});
+```
+
+After mismatch handlers settle, surviving operations continue only if the tree is complete. Otherwise navigations and fetchers are canceled and their pending state settles. Canceling a navigation also cancels any pending revalidation - both return to idle and the current page and data remain in place without another loader pass. Similarly, interrupted fetcher loads settle with their existing data. If an action already changed server data, the displayed data may remain stale until a later navigation or explicit revalidation.
+
+Router-managed Back/Forward cancellations restore the prior history position. Additional browser Back/Forward presses during restoration can leave the URL and rendered route out of sync or navigate to another entry; preserving the current screen is not guaranteed in that case.
+
+Full-manifest load failures remain catchable and do not render route error boundaries, whether the handler calls `event.loadAllRoutes()` or the function returned by the hook. Uncaught full-load failures are reported through `<HydratedRouter onError>` or `console.error`, and the incomplete operation is canceled. Unrelated handler errors follow normal discovery error handling.
+
+## Temporary overrides
+
+Custom mismatch handlers override built-in recovery. Calling the hook without a handler does not override anything. Removing the last custom mismatch handler restores automatic recovery.
+
+Call `event.defaultBehavior()` to explicitly run built-in recovery: eager mismatches warn, navigation mismatches reload the destination, fetcher mismatches reload the current document, and imperative mismatches return without reloading. Repeated calls for one shared mismatch event reuse the same promise. It does not invoke other custom handlers or stop their propagation.
+
+```tsx
+unstable_useRouteDiscovery({
+  async onManifestMismatch(event) {
+    if (hasUnsavedChanges) {
+      event.stopPropagation();
+      setShowReloadDialog(true);
+      return;
+    }
+    await event.defaultBehavior();
+  },
+});
+```
+
+Custom handlers run in reverse registration order, with each awaited before the next. `stopPropagation()` prevents earlier handlers from running; it does not complete discovery or allow an operation to continue against an incomplete tree.
+
+```tsx
+unstable_useRouteDiscovery({
+  onManifestMismatch(event) {
+    if (hasUnsavedChanges) {
+      event.stopPropagation();
+      setShowReloadDialog(true);
+    }
+  },
+});
+```
+
+An editor mounted after a root recovery handler can use this to preserve a draft. Unmounting removes its registration and reveals earlier handlers. Callback updates preserve registration priority. This is registration order, not a guarantee that the deepest component runs first.
+
+Eager discovery waits for the initialized route tree to commit so a root handler can intercept the first request. It does not wait for every suspended descendant or guarantee an idle main thread. Discovery needed before handlers can mount retains normal lazy behavior.
+
+Without mismatch handlers, existing automatic recovery for eager/navigation/fetcher discovery remains unchanged. Deployment polling and staleness policy remain application-owned.

package/docs/how-to/spa.md

@@ -22,6 +22,8 @@ Typical Single Page apps send a mostly blank `index.html` template with little m
 
 <docs-info>SPA Mode is a special form of "Pre-Rendering" that allows you to serve all paths in your application from the same HTML file. Please refer to the [Pre-Rendering](./pre-rendering) guide if you want to do more extensive pre-rendering.</docs-info>
 
+<docs-info>If you want a SPA frontend backed by React Router server loaders and actions, see experimental [API-only Mode](../start/framework/rendering#api-only-mode-unstable).</docs-info>
+
 ## 1. Disable Runtime Server Rendering
 
 Server rendering is enabled by default. Set the `ssr` flag to `false` in `react-router.config.ts` to disable it.

package/docs/how-to/view-transitions.md

@@ -4,16 +4,78 @@ title: View Transitions
 
 # View Transitions
 
-[MODES: framework, data]
+[MODES: framework, data, declarative]
 
 <br/>
 <br/>
 
-Enable smooth animations between page transitions in your React Router applications using the [View Transitions API][view-transitions-api]. This feature allows you to create seamless visual transitions during client-side navigation.
+Use React's [`<ViewTransition>`][react-view-transition] component to animate client-side navigations. This requires React and React DOM 19.3 or later.
 
-## Basic View Transition
+<docs-warning>
 
-### 1. Enable view transitions on navigation
+React Router's `viewTransition` props/options, `useViewTransitionState` hook, and `NavLink`'s `isTransitioning` render prop and `transitioning` class are deprecated in favor of React's `<ViewTransition>` component. The existing APIs continue to work, including with older React versions.
+
+</docs-warning>
+
+## Navigation View Transitions with React
+
+Wrap the outlet in a persistent `<ViewTransition>` boundary in a shared layout route. In Framework Mode, this can be your root route's default export; in Data and Declarative modes, use it as the component for a parent route with children:
+
+```tsx
+import { ViewTransition } from "react";
+import { Link, Outlet } from "react-router";
+
+export default function PageLayout() {
+  return (
+    <>
+      <nav>
+        <Link to="/">Home</Link>
+        <Link to="/about">About</Link>
+      </nav>
+      <ViewTransition>
+        <main>
+          <Outlet />
+        </main>
+      </ViewTransition>
+    </>
+  );
+}
+```
+
+Navigations that update the outlet cross-fade its contents. Keep the boundary mounted across navigations; you don't need to key it by location or remount the route tree. The navigation stays outside the animated region. Other updates inside the boundary can also animate when they run in a React Transition.
+
+React Router wraps router state updates in [`React.startTransition`][start-transition] by default, which lets React activate `<ViewTransition>` without additional configuration. React Transitions must remain enabled for navigation view transitions to work: do not set `useTransitions={false}` on your router.
+
+This applies to navigations from `<Link>`, `<NavLink>`, and `<Form>`, as well as programmatic navigation with `useNavigate` and `useSubmit`. No additional `startTransition` wrapper is needed.
+
+### Migrating from React Router's view transitions
+
+- Remove `viewTransition` from `<Link>`, `<NavLink>`, and `<Form>`, and remove `viewTransition: true` from navigation/submission options. React coordinates `document.startViewTransition()` itself; enabling both implementations can interrupt animations.
+- Replace `useViewTransitionState`, `isTransitioning`, and `.transitioning` styles with React's [View Transition classes][react-view-transition-classes]. Those router APIs only track the legacy transitions.
+- For shared elements such as an image moving from a list to a detail route, wrap each side in `<ViewTransition name="...">` with the same unique name. See React's [shared element example][react-shared-elements].
+- Keep React Transitions enabled. `useTransitions={false}` and synchronous updates such as `flushSync` can prevent React's animations.
+
+React's component is not a drop-in replacement for every legacy animation. In particular, React [skips view transitions for synchronous updates from `popstate`][react-router-transitions], so browser Back/Forward navigations may not animate. Browsers without View Transitions support still navigate normally.
+
+Respect reduced-motion preferences when adding animations:
+
+```css
+@media (prefers-reduced-motion: reduce) {
+  ::view-transition-group(*),
+  ::view-transition-old(*),
+  ::view-transition-new(*) {
+    animation: none !important;
+  }
+}
+```
+
+## Legacy View Transitions (Deprecated)
+
+The following examples document the deprecated APIs for existing applications. These APIs are available in Framework and Data modes.
+
+### Basic View Transition
+
+#### 1. Enable view transitions on navigation
 
 The simplest way to enable view transitions is by adding the `viewTransition` prop to your `Link`, `NavLink`, or `Form` components. This automatically wraps the navigation update in `document.startViewTransition()`.
 
@@ -25,7 +87,7 @@ The simplest way to enable view transitions is by adding the `viewTransition` pr
 
 Without any additional CSS, this provides a basic cross-fade animation between pages.
 
-### 2. Enable view transitions with programmatic navigation
+#### 2. Enable view transitions with programmatic navigation
 
 When using programmatic navigation with the `useNavigate` hook, you can enable view transitions by passing the `viewTransition: true` option:
 
@@ -51,11 +113,11 @@ This provides the same cross-fade animation as using the `viewTransition` prop o
 
 For more information on using the View Transitions API, please refer to the ["Smooth transitions with the View Transition API" guide][view-transitions-guide] from the Google Chrome team.
 
-## Image Gallery Example
+### Image Gallery Example
 
 Let's build an image gallery that demonstrates how to trigger and use view transitions. We'll create a list of images that expand into a detail view with smooth animations.
 
-### 1. Create the image gallery route
+#### 1. Create the image gallery route
 
 ```tsx filename=routes/image-gallery.tsx
 import { NavLink } from "react-router";
@@ -91,7 +153,7 @@ export default function ImageGalleryRoute() {
 }
 ```
 
-### 2. Add transition styles
+#### 2. Add transition styles
 
 Define view transition names and animations for elements that should transition smoothly between routes.
 
@@ -127,7 +189,7 @@ Define view transition names and animations for elements that should transition
 }
 ```
 
-### 3. Create the image detail route
+#### 3. Create the image detail route
 
 The detail view needs to use the same view transition names to create a seamless animation.
 
@@ -151,7 +213,7 @@ export default function ImageDetailsRoute({
 }
 ```
 
-### 4. Add matching transition styles for the detail view
+#### 4. Add matching transition styles for the detail view
 
 ```css filename=app.css
 /* Match transition names from the list view */
@@ -169,11 +231,11 @@ export default function ImageDetailsRoute({
 }
 ```
 
-## Advanced Usage
+### Advanced Usage
 
 You can control view transitions more precisely using either render props or the `useViewTransitionState` hook.
 
-### 1. Using render props
+#### 1. Using render props
 
 ```tsx filename=routes/image-gallery.tsx
 <NavLink to={`/image/${idx}`} viewTransition>
@@ -201,7 +263,7 @@ You can control view transitions more precisely using either render props or the
 </NavLink>
 ```
 
-### 2. Using the `useViewTransitionState` hook
+#### 2. Using the `useViewTransitionState` hook
 
 ```tsx filename=routes/image-gallery.tsx
 function NavImage(props: { src: string; idx: number }) {
@@ -234,4 +296,9 @@ function NavImage(props: { src: string; idx: number }) {
 ```
 
 [view-transitions-api]: https://developer.mozilla.org/en-US/docs/Web/API/ViewTransition
+[react-view-transition]: https://react.dev/reference/react/ViewTransition
+[start-transition]: https://react.dev/reference/react/startTransition
+[react-view-transition-classes]: https://react.dev/reference/react/ViewTransition#view-transition-class
+[react-shared-elements]: https://react.dev/reference/react/ViewTransition#animating-a-shared-element
+[react-router-transitions]: https://react.dev/reference/react/ViewTransition#building-view-transition-enabled-routers
 [view-transitions-guide]: https://developer.chrome.com/docs/web-platform/view-transitions

package/docs/start/data/actions.md

@@ -9,7 +9,7 @@ order: 5
 
 ## Defining Actions
 
-Data mutations are done through Route actions defined on the `action` property of a route object. When the action completes, all loader data on the page is revalidated to keep your UI in sync with the data without writing any code to do it.
+Data mutations are done through Route actions defined on the `action` property of a route object. When the action completes, all loader data on the page is revalidated to keep your UI in sync with the data without writing any code to do it. To skip some or all of those reloads, see [Revalidation Optimization][optimize-revalidation].
 
 ```tsx
 import { createBrowserRouter } from "react-router";
@@ -136,3 +136,4 @@ function Project() {
 Next: [Navigating](./navigating)
 
 [fetchers]: ../../how-to/fetchers
+[optimize-revalidation]: ../../how-to/optimize-revalidation