Fix some typos (#1221)

* Removed some typos from drawer-navigator.md

* fix: Removed some typos

fix: Removed some typos from `/versioned_docs/version-6.x/auth-flow.md`

* fix: changed options to option

* Move changes over to v7

---------

Co-authored-by: Mian Muhammad Sharjeel Safdar <66178522+SharjeelSafdar@users.noreply.github.com>

Author: kacperkapusciak

versioned_docs/version-6.x/auth-flow.md

@@ -4,7 +4,7 @@ title: Authentication flows
 sidebar_label: Authentication flows
 ---
 
-Most apps require that a user authenticate in some way to have access to data associated with a user or other private content. Typically the flow will look like this:
+Most apps require that a user authenticates in some way to have access to data associated with a user or other private content. Typically the flow will look like this:
 
 - The user opens the app.
 - The app loads some authentication state from encrypted persistent storage (for example, [`SecureStore`](https://docs.expo.io/versions/latest/sdk/securestore/)).
@@ -15,7 +15,7 @@ Most apps require that a user authenticate in some way to have access to data as
 
 ## What we need
 
-This is the behavior that we want from the authentication flow: when users sign in, we want to throw away the state of the authentication flow and unmount all of the screens related to authentication, and when we press the hardware back button we expect to not be able to go back to the authentication flow.
+This is the behavior that we want from the authentication flow: when users sign in, we want to throw away the state of the authentication flow and unmount all of the screens related to authentication, and when we press the hardware back button, we expect to not be able to go back to the authentication flow.
 
 ## How it will work
 
@@ -101,7 +101,7 @@ The main thing to notice is that we're conditionally defining screens based on t
 - `SignIn` screen is only defined if `userToken` is `null` (user is not signed in)
 - `Home` screen is only defined if `userToken` is non-null (user is signed in)
 
-Here, we're conditionally defining one screen for each case. But you could also define multiple screens. For example, you probably want to define password reset, signup, etc screens as well when the user isn't signed in. Similarly for the screens accessible after sign in, you probably have more than one screen. We can use `React.Fragment` to define multiple screens:
+Here, we're conditionally defining one screen for each case. But you could also define multiple screens. For example, you probably want to define password reset, signup, etc screens as well when the user isn't signed in. Similarly, for the screens accessible after signing in, you probably have more than one screen. We can use `React.Fragment` to define multiple screens:
 
 ```js
 state.userToken == null ? (
@@ -118,7 +118,7 @@ state.userToken == null ? (
 );
 ```
 
-> If you have both your login-related screens and rest of the screens in Stack navigators, we recommend to use a single Stack navigator and place the conditional inside instead of using 2 different navigators. This makes it possible to have a proper transition animation during login/logout.
+> If you have both your login-related screens and rest of the screens in two different Stack navigators, we recommend to use a single Stack navigator and place the conditional inside instead of using 2 different navigators. This makes it possible to have a proper transition animation during login/logout.
 
 ## Implement the logic for restoring the token
 
@@ -132,8 +132,8 @@ From the previous snippet, we can see that we need 3 state variables:
 
 So we need to:
 
-- Add some logic for restoring token, sign in and sign out
-- Expose methods for sign in and sign out to other components
+- Add some logic for restoring token, signing in and signing out
+- Expose methods for signing in and signing out to other components
 
 We'll use `React.useReducer` and `React.useContext` in this guide. But if you're using a state management library such as Redux or Mobx, you can use them for this functionality instead. In fact, in bigger apps, a global state management library is more suitable for storing authentication tokens. You can adapt the same approach to your state management library.
 

versioned_docs/version-6.x/drawer-navigator.md

@@ -48,9 +48,9 @@ Then, you need to install and configure the libraries that are required by the d
 
 3. If you're on a Mac and developing for iOS, you also need to install the pods (via [Cocoapods](https://cocoapods.org/)) to complete the linking.
 
-  ```sh
-  npx pod-install ios
-  ```
+```sh
+npx pod-install ios
+```
 
 ## API Definition
 
@@ -85,7 +85,7 @@ Optional unique ID for the navigator. This can be used with [`navigation.getPare
 
 #### `initialRouteName`
 
-The name of the route to render on first load of the navigator.
+The name of the route to render on the first load of the navigator.
 
 #### `screenOptions`
 
@@ -107,7 +107,7 @@ It supports the following values:
 
 The default status of the drawer - whether the drawer should stay `open` or `closed` by default.
 
-When this is set to `open`, the drawer will be open from the initial render. It can be closed normally using gestures or programmatically. However, when going back, drawer will re-open if it was closed. This is essentially the opposite of the default behavior of the drawer where it starts `closed`, and back button closes an open drawer.
+When this is set to `open`, the drawer will be open from the initial render. It can be closed normally using gestures or programmatically. However, when going back, the drawer will re-open if it was closed. This is essentially the opposite of the default behavior of the drawer where it starts `closed`, and the back button closes an open drawer.
 
 #### `detachInactiveScreens`
 
@@ -117,7 +117,7 @@ Boolean used to indicate whether inactive screens should be detached from the vi
 
 Whether to use the legacy implementation based on Reanimated 1. The new implementation based on Reanimated 2 will perform better, but you need additional configuration and need to use Hermes with Flipper to debug.
 
-This defaults to `true` in following cases:
+This defaults to `true` in the following cases:
 
 - Reanimated 2 is not configured
 - App is connected to Chrome debugger (Reanimated 2 cannot be used with Chrome debugger)
@@ -129,7 +129,7 @@ Otherwise, it defaults to `false`
 
 Function that returns React element to render as the content of the drawer, for example, navigation items
 
-The content component receives following props by default:
+The content component receives the following props by default:
 
 - `state` - The [navigation state](navigation-state.md) of the navigator.
 - `navigation` - The navigation object for the navigator.
@@ -139,7 +139,7 @@ The content component receives following props by default:
 
 The default component for the drawer is scrollable and only contains links for the routes in the RouteConfig. You can easily override the default component to add a header, footer, or other content to the drawer. The default content component is exported as `DrawerContent`. It renders a `DrawerItemList` component inside a `ScrollView`.
 
-By default the drawer is scrollable and supports devices with notches. If you customize the content, you can use `DrawerContentScrollView` to handle this automatically:
+By default, the drawer is scrollable and supports devices with notches. If you customize the content, you can use `DrawerContentScrollView` to handle this automatically:
 
 ```js
 import {
@@ -241,7 +241,7 @@ The following [options](screen-options.md) can be used to configure the screens
 
 #### `title`
 
-Generic title that can be used as a fallback for `headerTitle` and `drawerLabel`.
+A generic title that can be used as a fallback for `headerTitle` and `drawerLabel`.
 
 #### `lazy`
 
@@ -314,7 +314,7 @@ Options are `left` or `right`. Defaults to `left` for LTR languages and `right`
 
 Type of the drawer. It determines how the drawer looks and animates.
 
-- `front`: Traditional drawer which covers the screen with a overlay behind it.
+- `front`: Traditional drawer which covers the screen with an overlay behind it.
 - `back`: The drawer is revealed behind the screen on swipe.
 - `slide`: Both the screen and the drawer slide on swipe to reveal the drawer.
 - `permanent`: A permanent drawer is shown as a sidebar. Useful for having always visible drawer on larger screens.
@@ -553,7 +553,7 @@ navigation.toggleDrawer();
 
 #### `jumpTo`
 
-Navigates to an existing screen in the drawer navigator. The method accepts following arguments:
+Navigates to an existing screen in the drawer navigator. The method accepts the following arguments:
 
 - `name` - _string_ - Name of the route to jump to.
 - `params` - _object_ - Screen params to pass to the destination route.
@@ -643,4 +643,4 @@ class Profile extends React.Component {
 
 ## Nesting drawer navigators inside others
 
-If a drawer navigator is nested inside of another navigator that provides some UI, for example a tab navigator or stack navigator, then the drawer will be rendered below the UI from those navigators. The drawer will appear below the tab bar and below the header of the stack. You will need to make the drawer navigator the parent of any navigator where the drawer should be rendered on top of its UI.
+If a drawer navigator is nested inside of another navigator that provides some UI, for example, a tab navigator or stack navigator, then the drawer will be rendered below the UI from those navigators. The drawer will appear below the tab bar and below the header of the stack. You will need to make the drawer navigator the parent of any navigator where the drawer should be rendered on top of its UI.

versioned_docs/version-6.x/modal.md

@@ -61,7 +61,7 @@ function RootStackScreen() {
 }
 ```
 
-Here, we are creating 2 groups of screens using the `RootStack.Group` component. The first group is for our regular screens, and the second group is for our modal screens. For the modal group, we have specified `presentation: 'modal'` in `screenOptions`. This will apply this option to all the screens inside the group. This options will change the animation for the screens to animate from bottom-to-top rather than right to left. The `presentation` option for stack navigator can be either `card` (default) or `modal`. The `modal` behavior slides the screen in from the bottom and allows the user to swipe down from the top to dismiss it on iOS.
+Here, we are creating 2 groups of screens using the `RootStack.Group` component. The first group is for our regular screens, and the second group is for our modal screens. For the modal group, we have specified `presentation: 'modal'` in `screenOptions`. This will apply this option to all the screens inside the group. This option will change the animation for the screens to animate from bottom-to-top rather than right to left. The `presentation` option for stack navigator can be either `card` (default) or `modal`. The `modal` behavior slides the screen in from the bottom and allows the user to swipe down from the top to dismiss it on iOS.
 
 Instead of specifying this option for a group, it's also possible to specify it for a single screen using the `options` prop on `RootStack.Screen`.
 

versioned_docs/version-7.x/auth-flow.md

@@ -4,7 +4,7 @@ title: Authentication flows
 sidebar_label: Authentication flows
 ---
 
-Most apps require that a user authenticate in some way to have access to data associated with a user or other private content. Typically the flow will look like this:
+Most apps require that a user authenticates in some way to have access to data associated with a user or other private content. Typically the flow will look like this:
 
 - The user opens the app.
 - The app loads some authentication state from encrypted persistent storage (for example, [`SecureStore`](https://docs.expo.io/versions/latest/sdk/securestore/)).
@@ -15,7 +15,7 @@ Most apps require that a user authenticate in some way to have access to data as
 
 ## What we need
 
-This is the behavior that we want from the authentication flow: when users sign in, we want to throw away the state of the authentication flow and unmount all of the screens related to authentication, and when we press the hardware back button we expect to not be able to go back to the authentication flow.
+This is the behavior that we want from the authentication flow: when users sign in, we want to throw away the state of the authentication flow and unmount all of the screens related to authentication, and when we press the hardware back button, we expect to not be able to go back to the authentication flow.
 
 ## How it will work
 
@@ -101,7 +101,7 @@ The main thing to notice is that we're conditionally defining screens based on t
 - `SignIn` screen is only defined if `userToken` is `null` (user is not signed in)
 - `Home` screen is only defined if `userToken` is non-null (user is signed in)
 
-Here, we're conditionally defining one screen for each case. But you could also define multiple screens. For example, you probably want to define password reset, signup, etc screens as well when the user isn't signed in. Similarly for the screens accessible after sign in, you probably have more than one screen. We can use `React.Fragment` to define multiple screens:
+Here, we're conditionally defining one screen for each case. But you could also define multiple screens. For example, you probably want to define password reset, signup, etc screens as well when the user isn't signed in. Similarly, for the screens accessible after signing in, you probably have more than one screen. We can use `React.Fragment` to define multiple screens:
 
 ```js
 state.userToken == null ? (
@@ -118,7 +118,7 @@ state.userToken == null ? (
 );
 ```
 
-> If you have both your login-related screens and rest of the screens in Stack navigators, we recommend to use a single Stack navigator and place the conditional inside instead of using 2 different navigators. This makes it possible to have a proper transition animation during login/logout.
+> If you have both your login-related screens and rest of the screens in two different Stack navigators, we recommend to use a single Stack navigator and place the conditional inside instead of using 2 different navigators. This makes it possible to have a proper transition animation during login/logout.
 
 ## Implement the logic for restoring the token
 
@@ -132,8 +132,8 @@ From the previous snippet, we can see that we need 3 state variables:
 
 So we need to:
 
-- Add some logic for restoring token, sign in and sign out
-- Expose methods for sign in and sign out to other components
+- Add some logic for restoring token, signing in and signing out
+- Expose methods for signing in and signing out to other components
 
 We'll use `React.useReducer` and `React.useContext` in this guide. But if you're using a state management library such as Redux or Mobx, you can use them for this functionality instead. In fact, in bigger apps, a global state management library is more suitable for storing authentication tokens. You can adapt the same approach to your state management library.
 
@@ -324,7 +324,11 @@ So our updated code will look like following:
       <Stack.Screen name="SignUp" component={SignUpScreen} />
     </>
   )}
-  <Stack.Screen navigationKey={isSignedIn ? 'user' : 'guest'} name="Help" component={HelpScreen} />
+  <Stack.Screen
+    navigationKey={isSignedIn ? 'user' : 'guest'}
+    name="Help"
+    component={HelpScreen}
+  />
 </>
 ```