Skip to content

fix: Removed some typos in docs #1084

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions versioned_docs/version-6.x/auth-flow.md
Original file line number Diff line number Diff line change
Expand Up @@ -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/)).
Expand All @@ -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

Expand Down Expand Up @@ -50,7 +50,7 @@ By conditionally defining different screens based on a variable, we can implemen

## Don't manually navigate when conditionally rendering screens

It's important to note that when using such a setup, you **don't manually navigate** to the `Home` screen by calling `navigation.navigate('Home')` or any other method. **React Navigation will automatically navigate to the correct screen** when `isSigned` in changes - `Home` screen when `isSignedIn` becomes `true`, and to `SignIn` screen when `isSignedIn` becomes `false`. You'll get an error if you attempt to navigate manually.
It's important to note that when using such a setup, you **don't manually navigate** to the `Home` screen by calling `navigation.navigate('Home')` or any other method. **React Navigation will automatically navigate to the correct screen** when `isSignedIn` changes - `Home` screen when `isSignedIn` becomes `true`, and to `SignIn` screen when `isSignedIn` becomes `false`. You'll get an error if you attempt to navigate manually.

## Define our screens

Expand Down Expand Up @@ -97,7 +97,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 ? (
Expand All @@ -114,7 +114,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

Expand All @@ -128,8 +128,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.

Expand Down
24 changes: 12 additions & 12 deletions versioned_docs/version-6.x/drawer-navigator.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ npm install @react-navigation/drawer

You also need to install [`react-native-gesture-handler`](https://docs.swmansion.com/react-native-gesture-handler/) and [`react-native-reanimated`](https://docs.swmansion.com/react-native-reanimated/).

If you have a Expo managed project, in your project directory, run:
If you have an Expo managed project, in your project directory, run:

```sh
expo install react-native-gesture-handler react-native-reanimated
Expand Down Expand Up @@ -73,15 +73,15 @@ The `Drawer.Navigator` component accepts following props:

#### `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`

Default options to use for the screens in the navigator.

#### `backBehavior`

This controls how going back in the navigator is handled. This includes when the back button is pressed/back gesture is performed, or `goBack` is called.
This controls how going back in the navigator is handled. This includes when the back button is pressed, back gesture is performed, or `goBack` is called.

It supports the following values:

Expand All @@ -95,7 +95,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`

Expand All @@ -107,7 +107,7 @@ Whether the screens should render the first time they are accessed. Defaults to

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)
Expand All @@ -119,7 +119,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.
Expand All @@ -130,7 +130,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 {
Expand Down Expand Up @@ -231,7 +231,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`

Expand Down Expand Up @@ -304,7 +304,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.
Expand Down Expand Up @@ -513,7 +513,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.
Expand Down Expand Up @@ -578,7 +578,7 @@ import { getDrawerStatusFromState } from '@react-navigation/drawer';
const isDrawerOpen = getDrawerStatusFromState(navigation.getState()) === 'open';
```

For class components, you can listen tp the `state` event to check if drawer was opened or closed:
For class components, you can listen to the `state` event to check if drawer was opened or closed:

```js
class Profile extends React.Component {
Expand All @@ -603,4 +603,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.
2 changes: 1 addition & 1 deletion versioned_docs/version-6.x/modal.md
Original file line number Diff line number Diff line change
Expand Up @@ -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`.

Expand Down