docs(file-conventions): fix grammar + typos (#10651)

Author: MichaelDeBoey

docs/file-conventions/asset-imports.md

@@ -11,7 +11,7 @@ Any files inside the `app` folder can be imported into your modules. Remix will:
 2. Fingerprint the file for long-term caching
 3. Return the public URL to your module to be used while rendering
 
-It's most common for stylesheets, but can be used for any file type with [a defined loader][remix-loaders].
+It's most common for stylesheets but can be used for any file type with [a defined loader][remix-loaders].
 
 ```tsx
 import type { LinksFunction } from "@remix-run/node"; // or cloudflare/deno

docs/file-conventions/entry.client.md

@@ -5,9 +5,9 @@ toc: false
 
 # entry.client
 
-By default, Remix will handle hydrating your app on the client for you. If you want to customize this behavior, you can run `npx remix reveal` to generate a `app/entry.client.tsx` (or `.jsx`) that will take precedence. This file is the entry point for the browser and is responsible for hydrating the markup generated by the server in your [server entry module][server_entry_module], however you can also initialize any other client-side code here.
+By default, Remix will handle hydrating your app on the client for you. If you want to customize this behavior, you can run `npx remix reveal` to generate a `app/entry.client.tsx` (or `.jsx`) that will take precedence. This file is the entry point for the browser and is responsible for hydrating the markup generated by the server in your [server entry module][server_entry_module]; however, you can also initialize any other client-side code here.
 
-Typically, this module uses `ReactDOM.hydrateRoot` to hydrate the markup that was already generated on the server in your [server entry module][server_entry_module].
+Typically, this module uses `ReactDOM.hydrateRoot` to hydrate the markup already generated on the server in your [server entry module][server_entry_module].
 
 Here's a basic example:
 
@@ -26,6 +26,6 @@ startTransition(() => {
 });
 ```
 
-This is the first piece of code that runs in the browser. You can initialize client side libraries, add client only providers, etc.
+This is the first piece of code that runs in the browser. You can initialize client side libraries, add client-only providers, etc.
 
 [server_entry_module]: ./entry.server

docs/file-conventions/entry.server.md

@@ -11,7 +11,7 @@ This module should render the markup for the current page using a `<RemixServer>
 
 ## `handleDataRequest`
 
-You can export an optional `handleDataRequest` function that will allow you to modify the response of a data request. These are the requests that do not render HTML, but rather return the loader and action data to the browser once client-side hydration has occurred.
+You can export an optional `handleDataRequest` function that will allow you to modify the response of a data request. These are the requests that do not render HTML but rather return the loader and action data to the browser once client-side hydration has occurred.
 
 ```tsx
 export function handleDataRequest(
@@ -51,7 +51,7 @@ _Note that you generally want to avoid logging when the request was aborted, sin
 
 ### Streaming Rendering Errors
 
-When you are streaming your HTML responses via [`renderToPipeableStream`][rendertopipeablestream] or [`renderToReadableStream`][rendertoreadablestream], your own `handleError` implementation will only handle errors encountered during the initial shell render. If you encounter a rendering error during subsequent streamed rendering you will need to handle these errors manually since the Remix server has already sent the Response by that point.
+When you are streaming your HTML responses via [`renderToPipeableStream`][rendertopipeablestream] or [`renderToReadableStream`][rendertoreadablestream], your own `handleError` implementation will only handle errors encountered during the initial shell render. If you encounter a rendering error during subsequent streamed rendering, you will need to handle these errors manually since the Remix server has already sent the Response by that point.
 
 - For `renderToPipeableStream`, you can handle these errors in the `onError` callback function. You will need to toggle a boolean in `onShellReady` so you know if the error was a shell rendering error (and can be ignored) or an async rendering error (and must be handled).
   - For an example, please refer to the default [`entry.server.tsx`][node-streaming-entry-server] for Node.
@@ -60,7 +60,7 @@ When you are streaming your HTML responses via [`renderToPipeableStream`][render
 
 ### Thrown Responses
 
-Note that this does not handle thrown `Response` instances from your `loader`/`action` functions. The intention of this handler is to find bugs in your code which result in unexpected thrown errors. If you are detecting a scenario and throwing a 401/404/etc. `Response` in your `loader`/`action` then it's an expected flow that is handled by your code. If you also wish to log, or send those to an external service, that should be done at the time you throw the response.
+Note that this does not handle thrown `Response` instances from your `loader`/`action` functions. The intention of this handler is to find bugs in your code which result in unexpected thrown errors. If you are detecting a scenario and throwing a 401/404/etc. `Response` in your `loader`/`action` then it's an expected flow handled by your code. If you also wish to log or send those to an external service, that should be done at the time you throw the response.
 
 [browser-entry-module]: ./entry.client
 [rendertopipeablestream]: https://react.dev/reference/react-dom/server/renderToPipeableStream

docs/file-conventions/remix-config.md

@@ -7,7 +7,7 @@ hidden: true
 
 <docs-warning>`remix.config.js` is only relevant when using the [Classic Remix Compiler][classic-remix-compiler]. When using [Remix Vite][remix-vite], this file should not be present in your project. Instead, Remix configuration should be provided to the Remix plugin in your [Vite config][vite-config].</docs-warning>
 
-This file has a few build and development configuration options, but does not actually run on your server.
+This file has a few build and development configuration options but does not run on your server.
 
 ```js filename=remix.config.js
 /** @type {import('@remix-run/dev').AppConfig} */
@@ -44,7 +44,7 @@ exports.appDirectory = "./elsewhere";
 ## assetsBuildDirectory
 
 The path to the browser build, relative to remix.config.js. Defaults to
-"public/build". Should be deployed to static hosting.
+`"public/build"`. Should be deployed to static hosting.
 
 ## browserNodeBuiltinsPolyfill
 
@@ -95,7 +95,7 @@ module.exports = {
 };
 ```
 
-If you wish to serve static assets from a separate domain you may also specify an absolute path:
+If you wish to serve static assets from a separate domain, you may also specify an absolute path:
 
 ```js filename=remix.config.js
 /** @type {import('@remix-run/dev').AppConfig} */
@@ -163,7 +163,7 @@ field in `package.json`.
 
 A list of regex patterns that determines if a module is transpiled and included
 in the server bundle. This can be useful when consuming ESM only packages in a
-CJS build, or when consuming packages with [CSS side effect
+CJS build or when consuming packages with [CSS side effect
 imports][css_side_effect_imports].
 
 For example, the `unified` ecosystem is all ESM-only. Let's also say we're using
@@ -234,7 +234,7 @@ The platform the server build is targeting, which can either be `"neutral"` or
 
 ## tailwind
 
-Whether to support [Tailwind functions and directives][tailwind_functions_and_directives] in CSS files if `tailwindcss` is installed. Defaults to `true`.
+Whether to support [Tailwind CSS functions and directives][tailwind_functions_and_directives] in CSS files if `tailwindcss` is installed. Defaults to `true`.
 
 ```js filename=remix.config.js
 /** @type {import('@remix-run/dev').AppConfig} */

docs/file-conventions/root.md

@@ -7,7 +7,7 @@ toc: false
 
 The "root" route (`app/root.tsx`) is the only _required_ route in your Remix application because it is the parent to all routes in your `routes/` directory and is in charge of rendering the root `<html>` document.
 
-Beyond that, it's mostly just like any other route and supports all of the standard route exports:
+Beyond that, it's mostly just like any other route and supports all the standard route exports:
 
 - [`headers`][headers]
 - [`meta`][meta]
@@ -22,7 +22,7 @@ Beyond that, it's mostly just like any other route and supports all of the stand
 - [`handle`][handle]
 - [`shouldRevalidate`][shouldrevalidate]
 
-Because the root route manages your document, it is the proper place to render a handful of "document-level" components Remix provides. These components are to be used once inside your root route and they include everything Remix figured out or built in order for your page to render properly.
+Because the root route manages your document, it is the proper place to render a handful of "document-level" components Remix provides. These components are to be used once inside your root route, and they include everything Remix figured out or built in order for your page to render properly.
 
 ```tsx filename=app/root.tsx
 import type { LinksFunction } from "@remix-run/node"; // or cloudflare/deno
@@ -81,7 +81,7 @@ export default function App() {
 
 ## Layout Export
 
-Because the root route manages the document for all routes, it also supports an additional optional `Layout` export. You can read the details in this [RFC][layout-rfc] but the layout route serves 2 purposes:
+Because the root route manages the document for all routes, it also supports an additional optional `Layout` export. You can read the details in this [RFC][layout-rfc] but the layout route serves two purposes:
 
 - Avoid duplicating your document/"app shell" across your root component, `HydrateFallback`, and `ErrorBoundary`
 - Avoids React from re-mounting your app shell elements when switching between the root component/`HydrateFallback`/`ErrorBoundary` which can cause a FOUC if React removes and re-adds `<link rel="stylesheet">` tags from your `<Links>` component.
@@ -148,7 +148,7 @@ export function ErrorBoundary() {
 
 **A note on `useLoaderData`in the `Layout` Component**
 
-`useLoaderData` is not permitted to be used in `ErrorBoundary` components because it is intended for the happy-path route rendering, and its typings have a built-in assumption that the `loader` ran successfully and returned something. That assumption doesn't hold in an `ErrorBoundary` because it could have been the `loader` that threw and triggered the boundary! In order to access loader data in `ErrorBoundary`'s, you can use `useRouteLoaderData` which accounts for the loader data potentially being `undefined`.
+`useLoaderData` is not permitted to be used in `ErrorBoundary` components because it is intended for the happy-path route rendering, and its typings have a built-in assumption that the `loader` ran successfully and returned something. That assumption doesn't hold in an `ErrorBoundary` because it could have been the `loader` that threw and triggered the boundary! To access loader data in `ErrorBoundary`'s, you can use `useRouteLoaderData` which accounts for the loader data potentially being `undefined`.
 
 Because your `Layout` component is used in both success and error flows, this same restriction holds. If you need to fork logic in your `Layout` depending on if it was a successful request or not, you can use `useRouteLoaderData("root")` and `useRouteError()`.
 

docs/file-conventions/routes.md

@@ -12,17 +12,17 @@ Please note that you can use either `.js`, `.jsx`, `.ts` or `.tsx` file extensio
 
 ## Disclaimer
 
-Before we go too far into the Remix convention though, we'd like to point out that file-based routing is an **incredibly** subjective idea. Some folks love the "flat" routes idea, some folks hate it and would prefer nesting routes in folders. Some folks simply hate file-based routing and would prefer to configure routes via JSON. Some folks would prefer to configure routes via JSX like they did in their React Router SPA's.
+Before we go too far into the Remix convention, though, we'd like to point out that file-based routing is an **incredibly** subjective idea. Some folks love the "flat" routes idea, some folks hate it and would prefer nesting routes in folders. Some folks simply hate file-based routing and would prefer to configure routes via JSON. Some folks would prefer to configure routes via JSX like they did in their React Router SPA's.
 
 The point is, we are well aware of this and from the get-go, Remix has always given you a first-class way to opt-out via the [`routes`][routes_config]/[`ignoredRouteFiles`][ignoredroutefiles_config] and [configure your routes manually][manual-route-configuration]. But, there has to be _some_ default so that folks can get up and running quickly and easily - and we think that the flat routes convention document below is a pretty good default that scales well for small-to-medium sized apps.
 
-Large applications with hundreds or thousands of routes will _always_ be a bit chaotic no matter what convention you use - and the idea is that via the `routes` config, you get to build _exactly_ the convention that works best for your application/team. It would be quite literally impossible for Remix to have a default convention that made everyone happy. We'd much rather give you a fairly straightforward default, and then let the community build any number of conventions you can pick and choose from.
+Large applications with hundreds or thousands of routes will _always_ be a bit chaotic no matter what convention you use — and the idea is that via the `routes` config, you get to build _exactly_ the convention that works best for your application/team. It would be quite literally impossible for Remix to have a default convention that made everyone happy. We'd much rather give you a fairly straightforward default and then let the community build any number of conventions you can pick and choose from.
 
-So, before we dive into the details of the Remix default convention, here's some community alternatives you can check out if you decide that our default is not your cup of tea.
+So, before we dive into the details of the Remix default convention, here are some community alternatives you can check out if you decide that our default is not your cup of tea.
 
-- [`remix-flat-routes`][flat_routes] - The Remix default is basically a simplified version of this package. The author has continued to iterate on and evolve this package so if you generally like the "flat routes" idea but want a bit more power (including a hybrid approach of files and folders), definitely check this one out.
+- [`remix-flat-routes`][flat_routes] - The Remix default is basically a simplified version of this package. The author has continued to iterate on and evolve this package, so if you generally like the "flat routes" idea but want a bit more power (including a hybrid approach of files and folders), definitely check this one out.
 - [`remix-custom-routes`][custom_routes] - If you want even more customization, this package lets you define that types of files should be treated as routes. This lets you go beyond the simple flat/nested concept and do something such as _"any file with an extension of `.route.tsx` is a route"_.
-- [`remix-json-routes`][json_routes] - If you just want to specify your routes via a config file, this is your jam - just provide Remix a JSON object with your routes and skip the flat/nested concept entirely. There's even a JSX option in there too.
+- [`remix-json-routes`][json_routes] - If you just want to specify your routes via a config file, this is your jam — provide Remix a JSON object with your routes and skip the flat/nested concept entirely. There's even a JSX option in there too.
 
 ## Root Route
 
@@ -227,7 +227,7 @@ Think of the `trailing_` underscore as the long bit at the end of your parent's
 
 We call these <a name="pathless-routes"><b>Pathless Routes</b></a>
 
-Sometimes you want to share a layout with a group of routes without adding any path segments to the URL. A common example is a set of authentication routes that have a different header/footer than the public pages or the logged in app experience. You can do this with a `_leading` underscore.
+Sometimes you want to share a layout with a group of routes without adding any path segments to the URL. A common example is a set of authentication routes that have a different header/footer than the public pages or the logged-in-app experience. You can do this with a `_leading` underscore.
 
 ```text lines=[3-5]
  app/
@@ -274,7 +274,7 @@ Wrapping a route segment in parentheses will make the segment optional.
 | `/en/american-flag-speedo` | `app/routes/($lang).$productId.tsx` |
 | `/fr/american-flag-speedo` | `app/routes/($lang).$productId.tsx` |
 
-You may wonder why `/american-flag-speedo` is matching the `($lang)._index.tsx` route instead of `($lang).$productId.tsx`. This is because when you have an optional dynamic param segment followed by another dynamic param, Remix cannot reliably determine if a single-segment URL such as `/american-flag-speedo` should match `/:lang` `/:productId`. Optional segments match eagerly and thus it will match `/:lang`. If you have this type of setup it's recommended to look at `params.lang` in the `($lang)._index.tsx` loader and redirect to `/:lang/american-flag-speedo` for the current/default language if `params.lang` is not a valid language code.
+You may wonder why `/american-flag-speedo` is matching the `($lang)._index.tsx` route instead of `($lang).$productId.tsx`. This is because when you have an optional dynamic param segment followed by another dynamic param, Remix cannot reliably determine if a single-segment URL such as `/american-flag-speedo` should match `/:lang` `/:productId`. Optional segments match eagerly and thus it will match `/:lang`. If you have this type of setup, it's recommended to look at `params.lang` in the `($lang)._index.tsx` loader and redirect to `/:lang/american-flag-speedo` for the current/default language if `params.lang` is not a valid language code.
 
 ## Splat Routes
 
@@ -395,7 +395,7 @@ app/routes/app._index/route.tsx
 
 ## Scaling
 
-Our general recommendation for scale is to make every route a folder and put the modules used exclusively by that route in the folder, then put the shared modules outside of routes folder elsewhere. This has a couple benefits:
+Our general recommendation for scale is to make every route a folder and put the modules used exclusively by that route in the folder, then put the shared modules outside the `routes` folder elsewhere. This has a couple of benefits:
 
 - Easy to identify shared modules, so tread lightly when changing them
 - Easy to organize and refactor the modules for a specific route without creating "file organization fatigue" and cluttering up other parts of the app

docs/file-conventions/vite-config.md

@@ -108,7 +108,7 @@ The path to the build directory, relative to the project root. Defaults to
 
 #### basename
 
-An optional basename for your route paths, passed through to the [React Router "basename" option][rr-basename]. Please note that this is different from your _asset_ paths. You can can configure the [base public path][vite-public-base-path] for your assets via the [Vite "base" option][vite-base].
+An optional basename for your route paths, passed through to the [React Router "basename" option][rr-basename]. Please note that this is different from your _asset_ paths. You can configure the [base public path][vite-public-base-path] for your assets via the [Vite "base" option][vite-base].
 
 #### buildEnd
 
@@ -125,7 +125,7 @@ An array of [presets] to ease integration with other tools and hosting providers
 
 #### serverBuildFile
 
-The name of the server file generated in the server build directory. Defaults to `"index.js"`.
+The name of the server file is generated in the server build directory. Defaults to `"index.js"`.
 
 #### serverBundles