docs(discussion): fix grammar + typos (#10650)

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

Author: MichaelDeBoey

docs/discussion/concurrency.md

@@ -4,7 +4,7 @@ title: Network Concurrency Management
 
 # Network Concurrency Management
 
-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. Remix simplifies this process by automating network management, mirroring and expanding the intuitive behavior of web browsers.
+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. Remix simplifies this process by automating network management, mirroring, and expanding the intuitive behavior of web browsers.
 
 To help understand how Remix works, remember from [Fullstack Data Flow][fullstack_data_flow] that after `form` submissions, Remix will fetch fresh data from the loaders. This is called revalidation.
 
@@ -49,11 +49,11 @@ submission 2:    |-----✓-----✅
 submission 3:             |-----✓-----✅
 ```
 
-Because the revalidation from submission (2) started later and landed earlier than submission (1), the requests from submission (1) are cancelled and only the data from submission (2) is committed to the UI. It was requested later so its more likely to contain the updated values from both (1) and (2).
+Because the revalidation from submission (2) started later and landed earlier than submission (1), the requests from submission (1) are canceled and only the data from submission (2) is committed to the UI. It was requested later, so it's more likely to contain the updated values from both (1) and (2).
 
 ## Potential for Stale Data
 
-It's unlikely your users will ever experience this, but there are still chances for the user to see stale data in very rare conditions with inconsistent infrastructure. Even though Remix cancels requests for stale data, they will still end up making it to the server. Cancelling a request in the browser simply releases browser resources for that request, it can't "catch up" and stop it from getting to the server. In extremely rare conditions, a cancelled request may change data after the interrupting `action`'s revalidation lands. Consider this diagram:
+It's unlikely your users will ever experience this, but there are still chances for the user to see stale data in very rare conditions with inconsistent infrastructure. Even though Remix cancels requests for stale data, they will still end up making it to the server. Cancelling a request in the browser simply releases browser resources for that request, it can't "catch up" and stop it from getting to the server. In extremely rare conditions, a canceled request may change data after the interrupting `action`'s revalidation lands. Consider this diagram:
 
 ```text
      👇 interruption with new submission
@@ -120,11 +120,11 @@ export function CitySearchCombobox() {
 }
 ```
 
-All the application needs to know is how to query the data and how to render it, Remix handles the network.
+All the application needs to know is how to query the data and how to render it; Remix handles the network.
 
 ## Conclusion
 
-Remix offers developers an intuitive, browser-based approach to managing network requests. By mirroring browser behaviors and enhancing them where needed, it simplifies the complexities of concurrency, revalidation, and potential race conditions. Whether you're building a simple webpage or a sophisticated web application, Remix ensures that your user interactions are smooth, reliable, and always up-to-date.
+Remix offers developers an intuitive, browser-based approach to managing network requests. By mirroring browser behaviors and enhancing them where needed, it simplifies the complexities of concurrency, revalidation, and potential race conditions. Whether you're building a simple webpage or a sophisticated web application, Remix ensures that your user interactions are smooth, reliable, and always up to date.
 
 [fullstack_data_flow]: ./data-flow
 [use_fetcher]: ../hooks/use-fetcher

docs/discussion/data-flow.md

@@ -171,7 +171,7 @@ When you send HTML from the server, it's best to have it work even before JavaSc
 
 When the user submits the form before JavaScript loads:
 
-1. The browser submits the form to the action (instead of `fetch`) and the browsers pending states activate (spinning favicon)
+1. The browser submits the form to the action (instead of `fetch`) and the browsers' pending states activate (spinning favicon)
 2. After the action completes, loaders are called
 3. Remix renders the page and sends HTML to the browser
 

docs/discussion/form-vs-fetcher.md

@@ -134,7 +134,7 @@ Combined, these APIs offer a balanced blend of structured navigation and feedbac
 
 Now consider we're looking at a list of recipes that have delete buttons on each item. When a user clicks the delete button, we want to delete the recipe from the database and remove it from the list without navigating away from the list.
 
-First consider the basic route setup to get a list of recipes on the page:
+First, consider the basic route setup to get a list of recipes on the page:
 
 ```tsx filename=app/routes/recipes/_index.tsx
 import type { LoaderFunctionArgs } from "@remix-run/node"; // or cloudflare/deno
@@ -192,11 +192,11 @@ const RecipeListItem: FunctionComponent<{
 };
 ```
 
-Using [`useFetcher`][use_fetcher] in this scenario works perfectly. Instead of navigating away or refreshing the entire page, we want in-place updates. When a user deletes a recipe, the action called and the fetcher manages the corresponding state transitions.
+Using [`useFetcher`][use_fetcher] in this scenario works perfectly. Instead of navigating away or refreshing the entire page, we want in-place updates. When a user deletes a recipe, the `action` is called and the fetcher manages the corresponding state transitions.
 
 The key advantage here is the maintenance of context. The user stays on the list when the deletion completes. The fetcher's state management capabilities are leveraged to give real-time feedback: it toggles between `"Deleting..."` and `"Delete"`, providing a clear indication of the ongoing process.
 
-Furthermore, with each fetcher having the autonomy to manage its own state, operations on individual list items become independent, ensuring that actions on one item don't affect the others (though revalidation of the page data is a shared concern that is covered in [Network Concurrency Management][network_concurrency_management]).
+Furthermore, with each `fetcher` having the autonomy to manage its own state, operations on individual list items become independent, ensuring that actions on one item don't affect the others (though revalidation of the page data is a shared concern covered in [Network Concurrency Management][network_concurrency_management]).
 
 In essence, `useFetcher` offers a seamless mechanism for actions that don't necessitate a change in the URL or navigation, enhancing the user experience by providing real-time feedback and context preservation.
 

docs/discussion/hot-module-replacement.md

@@ -8,7 +8,7 @@ Hot Module Replacement is a technique for updating modules in your app without n
 It's a great developer experience, and Remix supports it out of the box.
 
 Notably, HMR does its best to preserve browser state across updates.
-If you have form within a modal, and you fill out all the fields traditional live reload would hard refresh the page.
+If you have a `form` within a modal, and you fill out all the fields, traditional live reload would hard refresh the page.
 So you'd lose all the data in the form.
 Every time you make a change, you'd have to open up the modal _again_ and fill out the form _again_. 😭
 

docs/discussion/introduction.md

@@ -44,7 +44,7 @@ app.all(
 );
 ```
 
-Express (or Node.js) is the actual server, Remix is just a handler on that server. The `"@remix-run/express"` package is called an adapter. Remix handlers are server agnostic. Adapters make them work for a specific server by converting the server's request/response API into the Fetch API on the way in, and then adapting the Fetch Response coming from Remix into the server's response API. Here's some pseudocode of what an adapter does:
+Express (or Node.js) is the actual server, Remix is just a handler on that server. The `"@remix-run/express"` package is called an adapter. Remix handlers are server agnostic. Adapters make them work for a specific server by converting the server's request/response API into the Fetch API on the way in and then adapting the Fetch Response coming from Remix into the server's response API. Here's some pseudocode of what an adapter does:
 
 ```ts
 export function createRequestHandler({ build }) {
@@ -65,7 +65,7 @@ export function createRequestHandler({ build }) {
 }
 ```
 
-Real adapters do a bit more than that, but that's the gist of it. Not only does this enable you to deploy Remix anywhere, but it also lets you incrementally adopt it in an existing JavaScript server since you can have routes outside of Remix that your server continues to handle before getting to Remix.
+Real adapters do a bit more than that, but that's the gist of it. Not only does this enable you to deploy Remix anywhere, it also lets you incrementally adopt it in an existing JavaScript server since you can have routes outside of Remix that your server continues to handle before getting to Remix.
 
 Additionally, if Remix doesn't have an adapter for your server already, you can look at the source of one of the adapters and build your own.
 
@@ -77,7 +77,7 @@ Instead of having a split between View and Controller, Remix Route modules take
 
 Most server-side frameworks are "model focused". A controller manages _multiple URLs_ for a single model.
 
-Remix is _UI focused_. Routes can handle an entire URL or just a segment of the URL. When a route maps to just a segment, the nested URL segments become nested layouts in the UI. In this way, each layout (view) can be its own controller and then Remix will aggregate the data and components to build the complete UI.
+Remix is _UI-focused_. Routes can handle an entire URL or just a segment of the URL. When a route maps to just a segment, the nested URL segments become nested layouts in the UI. In this way, each layout (view) can be its own controller and then Remix will aggregate the data and components to build the complete UI.
 
 More often than not, a Remix route module can contain both the UI and the interactions with the models in the same file, which leads to really nice developer ergonomics and productivity.
 
@@ -140,7 +140,7 @@ export async function action({
 
 You can actually use Remix as just a server-side framework without using any browser JavaScript at all. The route conventions for data loading with `loader`, mutations with `action` and HTML forms, and components that render at URLs, can provide the core feature set of a lot of web projects.
 
-In this way, **Remix scales down**. Not every page in your application needs a bunch of JavaScript in the browser and not every user interaction requires any extra flair than the browser's default behaviors. In Remix, you can build it the simple way first, and then scale up without changing the fundamental model. Additionally, the majority of the app works before JavaScript loads in the browser, which makes Remix apps resilient to choppy network conditions by design.
+In this way, **Remix scales down**. Not every page in your application needs a bunch of JavaScript in the browser, and not every user interaction requires any extra flair than the browser's default behaviors. In Remix, you can build it the simple way first, and then scale up without changing the fundamental model. Additionally, the majority of the app works before JavaScript loads in the browser, which makes Remix apps resilient to choppy network conditions by design.
 
 If you're not familiar with traditional back-end web frameworks, you can think of Remix routes as React components that are already their own API route and already know how to load and submit data to themselves on the server.
 
@@ -154,20 +154,20 @@ Additionally, when users submit a `<Form>` to update data, instead of doing a no
 
 This has many performance benefits over making a full-document request:
 
-1. Assets don't need to be re-downloaded (or pulled from cache)
+1. Assets don't need to be re-downloaded (or pulled from the cache)
 2. Assets don't need to be parsed by the browser again
 3. The data fetched is much smaller than the entire document (sometimes orders of magnitude)
 4. Because Remix enhances HTML APIs (`<a>` and `<form>`), your app tends to work even before JavaScript has loaded on the page
 
-Remix also has some built in optimizations for client-side navigation. It knows which layouts will persist between the two URLs, so it only fetches the data for the ones that are changing. A full document request would require all data to be fetched on the server, wasting resources on your back end and slowing down your app.
+Remix also has some built-in optimizations for client-side navigation. It knows which layouts will persist between the two URLs, so it only fetches the data for the ones that are changing. A full document request would require all data to be fetched on the server, wasting resources on your back end and slowing down your app.
 
 This approach also has UX benefits like not resetting the scroll position of a sidebar nav and allowing you to move focus to something that makes more sense than the top of the document.
 
 Remix can also prefetch all resources for a page when the user is about to click a link. The browser framework knows about the compiler's asset manifest. It can match the URL of the link, read the manifest, and then prefetch all data, JavaScript modules, and even CSS resources for the next page. This is how Remix apps feel fast even when networks are slow.
 
 Remix then provides client side APIs, so you can create rich user experiences without changing the fundamental model of HTML and browsers.
 
-Taking our route module from before, here are a few small, but useful UX improvements to the form that you can only do with JavaScript in the browser:
+Taking our route module from before, here are a few small but useful UX improvements to the form that you can only do with JavaScript in the browser:
 
 1. Disable the button when the form is being submitted
 2. Focus the input when server-side form validation fails