docs(guides): fix grammar + typos (#10652)

Co-authored-by: Brooks Lybrand <[email protected]>

Author: MichaelDeBoey

docs/guides/accessibility.md

@@ -18,7 +18,7 @@ Remix also provides the [`<NavLink/>`][navlink] which behaves the same as `<Link
 
 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 Remix app should already work this way by default!
+With a traditional multipage 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 Remix app should already work this way by default!
 
 When the client scripts in Remix are loaded, React Router takes control of routing and prevents the browser's default behavior. Remix doesn't make any assumptions about your UI as the route changes. There are some important features you'll want to consider as a result, including:
 

docs/guides/api-development-strategy.md

@@ -57,12 +57,12 @@ export default defineConfig({
 
 - Both the existing `v2` behavior and the new `v3_somethingDifferent` behavior coexist simultaneously.
 - Applications can adopt changes incrementally, one step at a time, instead of having to adjust to a multitude of changes all at once in the next major release.
-- If all the `v3_*` future flags are enabled, transitioning to `v3` should ideally not necessitate any changes to your codebase.
+- If all the `v3_*` future flags are enabled, transitioning to `v3` should ideally not require any changes to your codebase.
 - Some future flags that bring about breaking changes initially start as `unstable_*` flags. These might undergo modifications during minor releases. Once they become `v3_*` future flags, the corresponding API is set and won't change further.
 
 ## Summary
 
-Our development strategy focuses on gradual feature adoption and seamless version upgrades for major releases. This empowers developers to selectively integrate new features, avoiding the need for extensive code adjustments during version transitions. By introducing features through `unstable_*` flags, we refine the API collaboratively with early adopters while ensuring stable releases benefit from enhancements. Through careful management of breaking changes using `v3_*` flags, we provide the flexibility to adopt changes incrementally, facilitating a smoother transition between major versions. While this increases the complexity for developing Remix the framework, this developer-centric approach greatly simplifies application development with Remix, ultimately leading to improved software quality and (hopefully!) developer satisfaction.
+Our development strategy focuses on gradual feature adoption and seamless version upgrades for major releases. This empowers developers to selectively integrate new features, avoiding the need for extensive code adjustments during version transitions. By introducing features through `unstable_*` flags, we refine the API collaboratively with early adopters while ensuring stable releases benefit from enhancements. Through careful management of breaking changes using `v3_*` flags, we provide the flexibility to adopt changes incrementally, facilitating a smoother transition between major versions. While this increases the complexity of developing Remix the framework, this developer-centric approach greatly simplifies application development with Remix, ultimately leading to improved software quality and (hopefully!) developer satisfaction.
 
 [vite-config-future]: ../file-conventions/vite-config#future
 [remix-config-future]: ../file-conventions/remix-config#future

docs/guides/api-routes.md

@@ -4,7 +4,7 @@ title: API Routes
 
 # API Routes
 
-You might be used to building React apps that don't run on the server, or least not very much of it does, so it's backed by a set of API routes. In Remix, most of your routes are both your UI and your API, so Remix in the browser knows how to talk to itself on the server.
+You might be used to building React apps that don't run on the server, or at least not very much of it does, so it's backed by a set of API routes. In Remix, most of your routes are both your UI and your API, so Remix in the browser knows how to talk to itself on the server.
 
 In general, you don't need the concept of "API Routes" at all. But we knew you'd come poking around with this term, so here we are!
 
@@ -92,7 +92,7 @@ function CitySearchCombobox() {
 
 ## Resource Routes
 
-In other cases, you may need routes that are part of your application, but aren't part of your application's UI. Maybe you want a loader that renders a report as a PDF:
+In other cases, you may need routes that are part of your application but aren't part of your application's UI. Maybe you want a loader that renders a report as a PDF:
 
 ```tsx
 export async function loader({

docs/guides/bff.md

@@ -7,9 +7,9 @@ toc: false
 
 While Remix can serve as your fullstack application, it also fits perfectly into the "Backend for your 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.
+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.
 
-Mature apps already have a lot of backend application code in Ruby, Elixir, PHP, etc. and there's no reason to justify migrating it all to a server-side JavaScript runtime just to get the benefits of Remix. Instead, you can use your Remix app as a backend for your frontend.
+Mature apps already have a lot of backend application code in Ruby, Elixir, PHP, etc., and there's no reason to justify migrating it all to a server-side JavaScript runtime just to get the benefits of Remix. Instead, you can use your Remix app as a backend for your frontend.
 
 Because Remix polyfills the Web Fetch API, you can use `fetch` right from your loaders and actions to your backend.
 
@@ -21,7 +21,7 @@ import escapeHtml from "escape-html";
 export async function loader({
   request,
 }: LoaderFunctionArgs) {
-  const apiUrl = "http://api.example.com/some-data.json";
+  const apiUrl = "https://api.example.com/some-data.json";
   const res = await fetch(apiUrl, {
     headers: {
       Authorization: `Bearer ${process.env.API_TOKEN}`,
@@ -43,7 +43,7 @@ export async function loader({
 
 There are several benefits of this approach vs. fetching directly from the browser. The highlighted lines above show how you can:
 
-1. Simplify third party integrations and keep tokens and secrets out of client bundles.
+1. Simplify third-party integrations and keep tokens and secrets out of client bundles.
 2. Prune the data down to send less kB over the network, speeding up your app significantly.
 3. Move a lot of code from browser bundles to the server, like `escapeHtml`, which speeds up your app. Additionally, moving code to the server usually makes your code easier to maintain since server-side code doesn't have to worry about UI states for async operations.
 

docs/guides/breadcrumbs.md

@@ -4,11 +4,11 @@ title: Breadcrumbs Guide
 
 # Breadcrumbs Guide
 
-In Remix, you can easily build dynamic breadcrumbs based on your route hierarchy. This guide will take you through the process using the [`useMatches`][use-matches] and [`handle`][handle] features.
+In Remix, you can build dynamic breadcrumbs based on your route hierarchy. This guide will take you through the process using the [`useMatches`][use-matches] and [`handle`][handle] features.
 
 ## Understanding the Basics
 
-Remix provides access to all route matches and related data at the top of the React element tree. This enables components like [`<Meta />`][meta-component], [`<Links />`][links-component], and [`<Scripts />`][scripts-component] to obtain values from nested routes and render them at the top of the document.
+Remix provides access to all route matches and related data at the top of the React element tree. This enables components like [`<Meta />`][meta-component], [`<Links />`][links-component], and [`<Scripts />`][scripts-component] to get values from nested routes and render them at the top of the document.
 
 You can use a similar strategy using the `useMatches` and `handle` functions. While we're focusing on breadcrumbs, the principles demonstrated here are applicable to a range of scenarios.
 

docs/guides/browser-support.md

@@ -6,21 +6,21 @@ title: Browser Support
 
 Remix only runs in browsers that support [ES Modules][esm-browsers].
 
-Usually teams are concerned about IE11 support when asking this question. Note that [Microsoft itself has stopped supporting this browser][msie] for their web applications and it's probably time for you, too.
+Usually teams are concerned about IE11 support when asking this question. Note that [Microsoft itself has stopped supporting this browser][msie] for their web applications, and it's probably time for you, too.
 
-However, thanks to first-class support for [Progressive Enhancement][pe], Remix apps can support browsers as old as Netscape 1.0! This works because Remix is built on the foundations of the web: HTML, HTTP, and browser behavior. By following Remix conventions, your app can work at a baseline level for IE11, while still providing a highly-interactive SPA experience for modern browsers. It doesn't take much effort on your part to achieve this, either.
+However, thanks to first-class support for [Progressive Enhancement][pe], Remix apps can support browsers as old as Netscape 1.0! This works because Remix is built on the foundations of the web: HTML, HTTP, and browser behavior. By following Remix conventions, your app can work at a baseline level for IE11, while still providing a highly interactive SPA experience for modern browsers. It doesn't take much effort on your part to achieve this, either.
 
 Here's how it works. The Remix `<Scripts/>` component renders module script tags like this:
 
 ```html
 <script type="module" src="..." />
 ```
 
-Older browsers ignore it because they don't understand the `type`, so no JavaScript is loaded. Links, loaders, forms, and actions still work because they are built on the foundations of HTML, HTTP and browser behavior. Modern browsers will load the scripts, providing enhanced SPA behavior with faster transitions and the enhanced UX of your application code.
+Older browsers ignore it because they don't understand the `type`, so no JavaScript is loaded. Links, loaders, forms, and actions still work because they are built on the foundations of HTML, HTTP, and browser behavior. Modern browsers will load the scripts, providing enhanced SPA behavior with faster transitions and the enhanced UX of your application code.
 
 ## Does Remix implement CSRF protection?
 
-Remix cookies are configured to `SameSite=Lax` by default which is a platform built-in protection against CSRF, if you need to support old browsers (IE11 or older) that doesn't support `SameSite=Lax` you would have to implement CSRF protection yourself or use a library that implements it.
+Remix cookies are configured to `SameSite=Lax` by default which is platform built-in protection against CSRF, if you need to support old browsers (IE11 or older) that doesn't support `SameSite=Lax` you would have to implement CSRF protection yourself or use a library that implements it.
 
 [pe]: https://en.wikipedia.org/wiki/Progressive_enhancement
 [esm-browsers]: https://caniuse.com/es6-module

docs/guides/cache-control.md

@@ -7,9 +7,9 @@ hidden: true
 
 ## In Routes Modules
 
-Each route can also define its http headers. This is mostly important for http caching. Remix doesn't rely on building your website into static files to be uploaded to a CDN for performance, instead we rely on cache headers. The end result of either approach is the same: a static document on a CDN. [Check out this video for more information on that][check-out-this-video-for-more-information-on-that].
+Each route can also define its http headers. This is mostly important for http caching. Remix doesn't rely on building your website into static files to be uploaded to a CDN for performance, instead we rely on cache headers. The result of either approach is the same: a static document on a CDN. [Check out this video for more information on that][check-out-this-video-for-more-information-on-that].
 
-Usually, the difficulty with cache headers is configuring them. In Remix we've made it easy. Just export a `headers` function from your route.
+Usually, the difficulty with cache headers is configuring them. In Remix, we've made it easy. Just export a `headers` function from your route.
 
 ```tsx
 export function headers() {
@@ -27,9 +27,9 @@ export default function Gists() {
 }
 ```
 
-The max-age tells the user's browser to cache this for 300 seconds, or 5 minutes. That means if they click back or on a link to the same page again within 5 minutes, the browser won't even make a request for the page, it will use the cache.
+The max-age tells the user's browser to cache this for 300 seconds or 5 minutes. That means if they click back or on a link to the same page again within 5 minutes, the browser won't even make a request for the page, it will use the cache.
 
-The s-maxage tells the CDN to cache it for an hour. Here's what it looks like when the first person visits our website:
+The `s-maxage` tells the CDN to cache it for an hour. Here's what it looks like when the first person visits our website:
 
 1. Request comes in to the website, which is really the CDN
 2. CDN doesn't have the document cached, so it makes a request to our server (the "origin server").
@@ -65,9 +65,9 @@ export function headers({
 
 The `loaderHeaders` object is an instance of the [Web Fetch API Headers constructor][web-fetch-api-headers-constructor]
 
-Now when the browser or a CDN wants to cache our page, it gets the headers from our data source, which is usually what you want. Note in our case we're actually just using headers GitHub sent in the response from our fetch!
+Now when the browser or a CDN wants to cache our page, it gets the headers from our data source, which usually is what you want. Note in our case we're actually just using headers GitHub sent in the response from our fetch!
 
-The second reason this matters is that Remix calls your loaders via `fetch` in the browser on client-side transitions. By returning good cache headers here, when the user clicks back/forward or visits the same page multiple times, the browser won't actually make another request for the data but will use a cached version instead. This greatly speeds up a website's performance, even for pages that you can't cache on a CDN. A lot of React apps rely on a JavaScript cache, but browser caches already work great!
+The second reason this matters is that Remix calls your loaders via `fetch` in the browser on client-side transitions. By returning good cache headers here, when the user clicks back/forward or visits the same page multiple times, the browser won't make another request for the data but will use a cached version instead. This greatly speeds up a website's performance, even for pages that you can't cache on a CDN. A lot of React apps rely on a JavaScript cache, but browser caches already work great!
 
 [check-out-this-video-for-more-information-on-that]: https://youtu.be/bfLFHp7Sbkg
 [cdn-caching]: ../guides/caching

docs/guides/client-data.md

@@ -6,15 +6,15 @@ title: Client Data
 
 Remix introduced support for "Client Data" ([RFC][rfc]) in [`v2.4.0`][2.4.0] which allows you to opt-into running route loaders/actions in the browser via [`clientLoader`][clientloader]/[`clientAction`][clientaction] exports from your route.
 
-These new exports are a bit of a sharp knife and are not recommended as your _primary_ data loading/submission mechanisms - but instead give you a lever to pull on for some of the following advanced use cases:
+These new exports are a bit of a sharp knife and are not recommended as your _primary_ data loading/submission mechanisms — but instead give you a lever to pull on for some of the following advanced use cases:
 
 - **Skip the Hop:** Query a data API directly from the browser, using loaders simply for SSR
 - **Fullstack State:** Augment server data with client data for your full set of loader data
 - **One or the Other:** Sometimes you use server loaders, sometimes you use client loaders, but not both on one route
 - **Client Cache:** Cache server loader data in the client and avoid some server calls
-- **Migration:** Ease your migration from React Router -> Remix SPA -> Remix SSR (once Remix supports [SPA Mode][rfc-spa])
+- **Migration:** Ease your migration from React Router → Remix SPA → Remix SSR (once Remix supports [SPA Mode][rfc-spa])
 
-Please use these new exports with caution! If you're not careful - it's easy to get your UI out of sync. Remix out of the box tries _very_ hard to ensure that this doesn't happen - but once you take control over your own client-side cache, and potentially prevent Remix from performing its normal server `fetch` calls - then Remix can no longer guarantee your UI remains in sync.
+Please use these new exports with caution! If you're not careful — it's straightforward to get your UI out of sync. Remix out of the box tries _very_ hard to ensure that this doesn't happen - but once you take control over your own client-side cache, and potentially prevent Remix from performing its normal server `fetch` calls - then Remix can no longer guarantee your UI remains in sync.
 
 ## Skip the Hop
 
@@ -88,7 +88,7 @@ export function HydrateFallback() {
 }
 
 export default function Component() {
-  // This will always be the combined set of server + client data
+  // This will always be the combined set of server and client data
   const data = useLoaderData();
   return <>...</>;
 }
@@ -227,7 +227,7 @@ We expect to write up a separate guide for migrations once [SPA Mode][rfc-spa] l
 3. Incrementally move to file-based route definitions via the use of a Vite plugin (not yet provided)
 4. Migrate your React Router SPA to Remix SPA Mode where all current file-based `loader` function act as `clientLoader`
 5. Opt out of Remix SPA Mode (and into Remix SSR mode) and find/replace your `loader` functions to `clientLoader`
-   - You're now running an SSR app but all your data loading is still happening in the client via `clientLoader`
+   - You're now running an SSR app, but all your data loading is still happening in the client via `clientLoader`
 6. Incrementally start moving `clientLoader -> loader` to start moving data loading to the server
 
 [rfc]: https://github.com/remix-run/remix/discussions/7634