Fix typos in docs (#8256)

Author: codeiotic

docs/getting-started/concepts.md

@@ -415,7 +415,7 @@ That's right, two of them!
 /teams/:teamId
 ```
 
-React Router has to make a decision here, there can be only one. Many routers, both client side and server side, will simply process the patterns in the order in which they were defined. First to match wins. In this case we would match `/` and render the `<Home/>` component. Definintely not what we wanted. These kinds of routers require us to order our routes perfectly to get the expected result. This is how React Router has worked up until v6, but now its much smarter.
+React Router has to make a decision here, there can be only one. Many routers, both client side and server side, will simply process the patterns in the order in which they were defined. First to match wins. In this case we would match `/` and render the `<Home/>` component. Definitely not what we wanted. These kinds of routers require us to order our routes perfectly to get the expected result. This is how React Router has worked up until v6, but now its much smarter.
 
 Looking at those patterns, you intuitively know that we want `/teams/new` to match the URL `/teams/new`. It's a perfect match! React Router also knows that. When matching, it will rank your routes according the number of segments, static segments, dynamic segments, star patterns, etc. and pick the most specific match. You never have to think about ordering your routes.
 

docs/guides/ssr.md

@@ -18,7 +18,7 @@ The most basic server rendering in React Router is pretty straightforward. Howev
 - Environment variables and secrets
 - Deployment
 
-Setting all of this up well can be pretty involved but is worth the performance and UX charactertics you can only get when server rendering.
+Setting all of this up well can be pretty involved but is worth the performance and UX characteristics you can only get when server rendering.
 
 If you want to server render your React Router app, we highly recommend you use [Remix](https://remix.run). This is another project of ours that's built on top of React Router and handles all of the things mentioned above and more. Give it a shot!
 

docs/upgrading/reach.md

@@ -290,7 +290,7 @@ If your app has a `<Link to="/events" />` still hanging around and the user
 clicks it, the server isn't involved since you're using a client-side router.
 You'll need to be more diligent about updating your links 😬.
 
-Alternatively, if you want to allow for out-dated links, _and you realize you need to configure your redirects on both the client and the server_, go ahead and copy paste the `Redirect` component we were about to ship but then deleted.
+Alternatively, if you want to allow for outdated links, _and you realize you need to configure your redirects on both the client and the server_, go ahead and copy paste the `Redirect` component we were about to ship but then deleted.
 
 ```jsx
 import { useEffect } from "react";
@@ -404,7 +404,7 @@ function PartialNavLink(props) {
 
 #### Justification
 
-"Prop getters" are clunky and can almost always be replaced with a hook. This also allows you to use the other hooks, like useLocation, and do even more custom things, like making a link active with a search string:
+"Prop getters" are clunky and can almost always be replaced with a hook. This also allows you to use the other hooks, like `useLocation`, and do even more custom things, like making a link active with a search string:
 
 ```jsx
 function RecentPostsLink(props) {
@@ -446,7 +446,7 @@ Also note the change from `uri -> url`.
 
 #### Justification
 
-Just feels cleaner to have the params be seperate from URL and path.
+Just feels cleaner to have the params be separate from URL and path.
 
 Also nobody knows the difference between URL and URI, so we didn't want to start a bunch of pedantic arguments about it. React Router always called it URL, and it's got more production apps, so we used URL instead of URI.
 

docs/upgrading/v5.md

@@ -518,7 +518,7 @@ cd ../../stats                  # pwd is /stats
 cd ../../../stats               # pwd is /stats
 ```
 
-**Note**: The decision to ignore trailing slashes while matching and creating relative paths was not taken lightly by our team. We consulted with a number of our friends and clients (who are also our friends!) about it. We found that most of us don't even understand how plain HTML relative links are handled with the trailing slash. Most people guessed it worked like `cd` on the command line (it does not). Also, HTML relative links don't have the concept of nested routes, they only worked on the URL, so we had to blaze our own trail here a bit. `@reach/router` set this precendent and it has worked out well for a couple of years.
+**Note**: The decision to ignore trailing slashes while matching and creating relative paths was not taken lightly by our team. We consulted with a number of our friends and clients (who are also our friends!) about it. We found that most of us don't even understand how plain HTML relative links are handled with the trailing slash. Most people guessed it worked like `cd` on the command line (it does not). Also, HTML relative links don't have the concept of nested routes, they only worked on the URL, so we had to blaze our own trail here a bit. `@reach/router` set this precedent and it has worked out well for a couple of years.
 
 In addition to ignoring trailing slashes in the current URL, it is important to note that `<Link to="..">` will not always behave like `<a href="..">` when your `<Route path>` matches more than one segment of the URL. Instead of removing just one segment of the URL, **it will resolve based upon the parent route's path, essentially removing all path segments specified by that route**.
 
@@ -638,7 +638,7 @@ function App() {
 }
 ```
 
-If you need to replace the current location instead of push a new one onto the history stack, use `navigate(to, { replace: true })`. If you need state, use `navigate(to, { state })`. You can think of the first arg to `navigate` as your `<Link to>` and the other arg as the `replace` and `state` props.
+If you need to replace the current location instead of push a new one onto the history stack, use `navigate(to, { replace: true })`. If you need state, use `navigate(to, { state })`. You can think of the first argument to `navigate` as your `<Link to>` and the other arguments as the `replace` and `state` props.
 
 If you prefer to use a declarative API for navigation (ala v5's `Redirect` component), v6 provides a `Navigate` component. Use it like: