docs(route): fix grammar + typos (#10655)

MichaelDeBoey · web-flow · commit 1afa284a4281 · 2025-06-09T08:39:36.000-05:00
diff --git a/docs/route/action.md b/docs/route/action.md
@@ -6,7 +6,7 @@ title: action
 
 <docs-success>Watch the <a href="https://www.youtube.com/playlist?list=PLXoynULbYuEDG2wBFSZ66b85EIspy3fy6">📼 Remix Singles</a>: <a href="https://www.youtube.com/watch?v=Iv25HAHaFDs&list=PLXoynULbYuEDG2wBFSZ66b85EIspy3fy6">Data Mutations with Form + action</a> and <a href="https://www.youtube.com/watch?v=w2i-9cYxSdc&list=PLXoynULbYuEDG2wBFSZ66b85EIspy3fy6">Multiple Forms and Single Button Mutations</a></docs-success>
 
-A route `action` is a server only function to handle data mutations and other actions. If a non-`GET` request is made to your route (`DELETE`, `PATCH`, `POST`, or `PUT`) then the action is called before the [`loader`][loader]s.
+A route `action` is a server-only function to handle data mutations and other actions. If a non-`GET` request is made to your route (`DELETE`, `PATCH`, `POST`, or `PUT`) then the action is called before the [`loader`][loader]s.
 
 `action`s have the same API as `loader`s, the only difference is when they are called. This enables you to co-locate everything about a data set in a single route module: the data read, the component that renders the data, and the data writes:
 
@@ -57,7 +57,7 @@ If you want to post to an index route use `?index` in the action: `<Form action=
 | `/accounts?index` | `app/routes/accounts._index.tsx` |
 | `/accounts`       | `app/routes/accounts.tsx`        |
 
-Also note that forms without an action prop (`<Form method="post">`) will automatically post to the same route within which they are rendered, so using the `?index` param to disambiguate between parent and index routes is only useful if you're posting to an index route from somewhere besides the index route itself. If you're posting from the index route to itself, or from the parent route to itself, you don't need to define a `<Form action>` at all, just omit it: `<Form method="post">`.
+Also note that forms without an action prop (`<Form method="post">`) will automatically post to the same route within which they are rendered, so using the `?index` param to disambiguate between parent and index routes is only useful if you're posting to an index route from somewhere besides the index route itself. If you're posting from the index route to itself, or from the parent route to itself, you don't need to define a `<Form action>` at all, omit it: `<Form method="post">`.
 
 See also:
 
diff --git a/docs/route/client-action.md b/docs/route/client-action.md
@@ -20,7 +20,7 @@ export const clientAction = async ({
 };
 ```
 
-This function is only ever run on the client, and can be used in a few ways:
+This function is only ever run on the client and can be used in a few ways:
 
 - Instead of a server `action` for full-client routes
 - To use alongside a `clientLoader` cache by invalidating the cache on mutations
diff --git a/docs/route/client-loader.md b/docs/route/client-loader.md
@@ -23,7 +23,7 @@ export const clientLoader = async ({
 };
 ```
 
-This function is only ever run on the client, and can be used in a few ways:
+This function is only ever run on the client and can be used in a few ways:
 
 - Instead of a server `loader` for full-client routes
 - To use alongside a `clientLoader` cache by invalidating the cache on mutations
@@ -58,7 +58,7 @@ export default function Component() {
 
 ### `clientLoader.hydrate`
 
-If you need to run your `clientLoader` during hydration on the initial document request, you can opt-in by setting `clientLoader.hydrate=true`. This will tell Remix that it needs to run the `clientLoader` on hydration. Without a `HydrateFallback`, your route component will be SSR'd with the server `loader` data - and then `clientLoader` will run and the returned data will be updated in-place in the hydrated route Component.
+If you need to run your `clientLoader` during hydration on the initial document request, you can opt in by setting `clientLoader.hydrate=true`. This will tell Remix that it needs to run the `clientLoader` on hydration. Without a `HydrateFallback`, your route component will be SSR'd with the server `loader` data - and then `clientLoader` will run and the returned data will be updated in-place in the hydrated route Component.
 
 <docs-info>If a route exports a `clientLoader` and does not export a server `loader`, then `clientLoader.hydrate` is automatically treated as `true` since there is no server data to SSR with. Therefore, we always need to run the `clientLoader` on hydration before rendering the route component.</docs-info>
 
@@ -78,7 +78,7 @@ This function receives the same [`request`][loader-request] argument as a [`load
 
 ### `serverLoader`
 
-`serverLoader` is an asynchronous function to get the data from the server `loader` for this route. On client-side navigations, this will make a [fetch][fetch] call to the Remix server `loader`. If you opt-into running your `clientLoader` on hydration, then this function will return you the data that was already loaded on the server (via `Promise.resolve`).
+`serverLoader` is an asynchronous function to get the data from the server `loader` for this route. On client-side navigations, this will make a [fetch][fetch] call to the Remix server `loader`. If you opt-into running your `clientLoader` on hydration, then this function will return you the data already loaded on the server (via `Promise.resolve`).
 
 See also:
 
diff --git a/docs/route/error-boundary.md b/docs/route/error-boundary.md
@@ -4,7 +4,7 @@ title: ErrorBoundary
 
 # `ErrorBoundary`
 
-A Remix `ErrorBoundary` component works just like normal React [error boundaries][error-boundaries], but with a few extra capabilities. When there is an error in your route component, the `ErrorBoundary` will be rendered in its place, nested inside any parent routes. `ErrorBoundary` components also render when there is an error in the `loader` or `action` functions for a route, so all errors for that route may be handled in one spot.
+A Remix `ErrorBoundary` component works just like normal React [error boundaries][error-boundaries] but with a few extra capabilities. When there is an error in your route component, the `ErrorBoundary` will be rendered in its place, nested inside any parent routes. `ErrorBoundary` components also render when there is an error in the `loader` or `action` functions for a route, so all errors for that route may be handled in one spot.
 
 The most common use-cases tend to be:
 
@@ -14,7 +14,7 @@ The most common use-cases tend to be:
   - Throwing a 404 when you can't find requested data
 - React may unintentionally throw an `Error` if it encounters a runtime error during rendering
 
-To obtain the thrown object, you can use the [`useRouteError`][use-route-error] hook. When a `Response` is thrown, it will be automatically unwrapped into an `ErrorResponse` instance with `state`/`statusText`/`data` fields so that you don't need to bother with `await response.json()` in your component. To differentiate thrown `Response`'s from thrown `Error`'s you can use the [`isRouteErrorResponse`][is-route-error-response] utility.
+To get the thrown object, you can use the [`useRouteError`][use-route-error] hook. When a `Response` is thrown, it will be automatically unwrapped into an `ErrorResponse` instance with `state`/`statusText`/`data` fields so that you don't need to bother with `await response.json()` in your component. To differentiate thrown `Response`'s from thrown `Error`'s you can use the [`isRouteErrorResponse`][is-route-error-response] utility.
 
 ```tsx
 import {
diff --git a/docs/route/headers.md b/docs/route/headers.md
@@ -58,11 +58,11 @@ If we are looking at `/users/123/profile` then three routes are rendering:
 
 If a user is looking at `/users/123/profile` and `users.$userId.profile.tsx` does not export a `headers` function, then Remix will use the return value of `users.$userId.tsx`'s `headers` function. If that file doesn't export one, then it will use the result of the one in `users.tsx`, and so on.
 
-If all three define `headers`, the deepest module wins, in this case `users.$userId.profile.tsx`. However, if your `users.$userId.profile.tsx`'s `loader` threw and bubbled to a boundary in `users.$userId.tsx` - then `users.$userId.tsx`'s `headers` function would be used as it is the leaf rendered route.
+If all three define `headers`, the deepest module wins, in this case `users.$userId.profile.tsx`. However, if your `users.$userId.profile.tsx`'s `loader` threw and bubbled to a boundary in `users.$userId.tsx` - then `users.$userId.tsx`'s `headers` function would be used as it is the leaf-rendered route.
 
 We don't want surprise headers in your responses, so it's your job to merge them if you'd like. Remix passes in the `parentHeaders` to your `headers` function. So `users.tsx` headers get passed to `users.$userId.tsx`, and then `users.$userId.tsx`'s `headers` are passed to `users.$userId.profile.tsx`'s `headers`.
 
-That is all to say that Remix has given you a very large gun with which to shoot your foot. You need to be careful not to send a `Cache-Control` from a child route module that is more aggressive than a parent route. Here's some code that picks the least aggressive caching in these cases:
+That is all to say that Remix has given you a huge gun with which to shoot your foot. You need to be careful not to send a `Cache-Control` from a child route module that is more aggressive than a parent route. Here's some code that picks the least aggressive caching in these cases:
 
 ```tsx
 import type { HeadersFunction } from "@remix-run/node"; // or cloudflare/deno
@@ -125,7 +125,7 @@ export default function handleRequest(
 }
 ```
 
-Just keep in mind that doing this will apply to _all_ document requests, but does not apply to `data` requests (for client-side transitions for example). For those, use [`handleDataRequest`][handle-data-request].
+Keep in mind that doing this will apply to _all_ document requests, but does not apply to `data` requests (for client-side transitions, for example). For those, use [`handleDataRequest`][handle-data-request].
 
 [cache-control-header]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
 [action]: ./action
diff --git a/docs/route/hydrate-fallback.md b/docs/route/hydrate-fallback.md
@@ -6,7 +6,7 @@ title: HydrateFallback
 
 A `HydrateFallback` component is your way of informing Remix that you do not want to render your route component until _after_ the `clientLoader` has run on hydration. When exported, Remix will render the fallback during SSR instead of your default route component, and will render your route component client-side once the `clientLoader` completes.
 
-The most common use-cases for this are client-only routes (such an in-browser canvas game) and augmenting your server data with client-side data (such as saved user preferences).
+The most common use-cases for this are client-only routes (such as an in-browser canvas game) and augmenting your server data with client-side data (such as saved user preferences).
 
 ```tsx filename=routes/client-only-route.tsx
 export async function clientLoader() {
@@ -63,7 +63,7 @@ export default function Component() {
 
 There are a few nuances worth noting around the behavior of `HydrateFallback`:
 
-- It is only relevant on initial document request and hydration, and will not be rendered on any subsequent client-side navigations
+- It is only relevant on initial document request and hydration and will not be rendered on any subsequent client-side navigations
 - It is only relevant when you are also setting [`clientLoader.hydrate=true`][hydrate-true] on a given route
 - It is also relevant if you do have a `clientLoader` without a server `loader`, as this implies `clientLoader.hydrate=true` since there is otherwise no loader data at all to return from `useLoaderData`
   - Even if you do not specify a `HydrateFallback` in this case, Remix will not render your route component and will bubble up to any ancestor `HydrateFallback` component
diff --git a/docs/route/loader.md b/docs/route/loader.md
@@ -18,7 +18,7 @@ export const loader = async () => {
 
 This function is only ever run on the server. On the initial server render, it will provide data to the HTML document. On navigations in the browser, Remix will call the function via [`fetch`][fetch] from the browser.
 
-This means you can talk directly to your database, use server-only API secrets, etc. Any code that isn't used to render the UI will be removed from the browser bundle.
+This means you can talk directly to your database, use server-only API secrets, etc. Any code not used to render the UI will be removed from the browser bundle.
 
 Using the database ORM [Prisma][prisma] as an example:
 
diff --git a/docs/route/meta.md b/docs/route/meta.md
@@ -150,7 +150,7 @@ export const meta: MetaFunction<
 
 Because multiple nested routes render at the same time, there is some merging that needs to happen to determine the meta tags that ultimately render. Remix gives you complete control over this merge because there is no obvious default.
 
-Remix will take the last matching route with a meta export and use that. This allows you to override things like `title`, remove things like `og:image` that the parent route added, or keep everything from the parent and add new meta for the child route.
+Remix will take the last matching route with a `meta` export and use that. This allows you to override things like `title`, remove things like `og:image` that the parent route added, or keep everything from the parent and add new meta for the child route.
 
 This can get quite tricky when you're new.
 
@@ -186,7 +186,7 @@ With this code, we will lose the `viewport` meta tag at `/projects` and `/projec
 
 ### Global `meta`
 
-Nearly every app will have global meta like the `viewport` and `charSet`. We recommend using normal [`<meta>` tags][meta-element] inside the [root route][root-route] instead of the `meta` export, so you simply don't have to deal with merging:
+Nearly every app will have global meta like the `viewport` and `charSet`. We recommend using normal [`<meta>` tags][meta-element] inside the [root route][root-route] instead of the `meta` export, so you don't have to deal with merging:
 
 ```tsx filename=app/root.tsx lines=[12-16]
 import {
diff --git a/docs/route/should-revalidate.md b/docs/route/should-revalidate.md
@@ -25,7 +25,7 @@ export const shouldRevalidate: ShouldRevalidateFunction = ({
 };
 ```
 
-<docs-warning>This feature is an <i>additional</i> optimization. In general, Remix's design already optimizes which loaders need to be called and when. When you use this feature you risk your UI getting out of sync with your server. Use with caution!</docs-warning>
+<docs-warning>This feature is an <i>additional</i> optimization. In general, Remix's design already optimizes which loaders need to be called and when. When you use this feature, you risk your UI getting out of sync with your server. Use with caution!</docs-warning>
 
 During client-side transitions, Remix 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, Remix 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.
 
@@ -35,7 +35,7 @@ This function lets apps further optimize by returning `false` when Remix is abou
 
 ## `actionResult`
 
-When a submission causes the revalidation this will be the result of the action—either action data or an error if the action failed. It's common to include some information in the action result to instruct `shouldRevalidate` to revalidate or not.
+When a submission causes the revalidation, this will be the result of the action—either action data or an error if the action failed. It's common to include some information in the action result to instruct `shouldRevalidate` to revalidate or not.
 
 ```tsx
 export async function action() {
@@ -127,7 +127,7 @@ In the case of navigation, these are the [URL params][url-params] from the next
 
 ## `nextUrl`
 
-In the case of navigation, this the URL the user is requesting. Some revalidations are not navigation, so it will simply be the same as `currentUrl`.
+In the case of navigation, this is the URL the user is requesting. Some revalidations are not navigation, so it will simply be the same as `currentUrl`.
 
 ## `formMethod`
 
@@ -145,7 +145,7 @@ The data submitted with the form that triggered the revalidation.
 
 ### Never reloading the root
 
-It's common for root loaders to return data that never changes, like environment variables to be sent to the client app. In these cases you never need the root loader to be called again. For this case, you can simply `return false`.
+It's common for root loaders to return data that never changes, like environment variables, to be sent to the client app. In these cases you never need the root loader to be called again. For this case, you can simply `return false`.
 
 ```tsx lines=[10]
 export const loader = async () => {
@@ -224,7 +224,7 @@ export async function loader({
 }
 ```
 
-There are a lot of ways to do this, and the rest of the code in the app matters, but ideally you don't think about the UI you're trying to optimize (the search params changing) but instead look at the values your loader cares about. In our case, it only cares about the projectId, so we can check two things:
+There are a lot of ways to do this. The rest of the code in the app matters, but ideally, you don't think about the UI you're trying to optimize (the search params changing) but instead look at the values your loader cares about. In our case, it only cares about the projectId, so we can check two things:
 
 - did the params stay the same?
 - was it a `GET` and not a mutation?
