From 5045ce8414e6aa011d75c82f8fd13c8d530569d9 Mon Sep 17 00:00:00 2001 From: Satyajit Sahoo Date: Fri, 22 Nov 2024 12:58:25 +0100 Subject: [PATCH] Fix broken anchor links --- blog/2020-02-06-react-navigation-5.0.md | 2 +- docusaurus.config.js | 2 ++ static/js/snack-helpers.js | 13 ------------- versioned_docs/version-1.x/navigation-actions.md | 8 ++++---- versioned_docs/version-1.x/navigation-options.md | 4 ++-- versioned_docs/version-1.x/redux-integration.md | 2 +- .../custom-android-back-button-handling.md | 2 +- .../version-2.x/custom-navigator-overview.md | 2 +- versioned_docs/version-2.x/drawer-actions.md | 6 +++--- versioned_docs/version-2.x/headers.md | 4 ++-- versioned_docs/version-2.x/navigation-actions.md | 1 - versioned_docs/version-2.x/navigation-events.md | 2 +- versioned_docs/version-2.x/navigation-key.md | 6 +++--- versioned_docs/version-2.x/navigation-lifecycle.md | 2 +- .../version-2.x/navigation-options-resolution.md | 6 +++--- versioned_docs/version-3.x/MST-integration.md | 2 +- .../custom-android-back-button-handling.md | 2 +- .../version-3.x/custom-navigator-overview.md | 2 +- versioned_docs/version-3.x/drawer-actions.md | 6 +++--- versioned_docs/version-3.x/headers.md | 4 ++-- versioned_docs/version-3.x/navigation-actions.md | 1 - versioned_docs/version-3.x/navigation-events.md | 2 +- versioned_docs/version-3.x/navigation-key.md | 6 +++--- versioned_docs/version-3.x/navigation-lifecycle.md | 2 +- .../version-3.x/navigation-options-resolution.md | 10 +++++----- versioned_docs/version-4.x/MST-integration.md | 2 +- .../version-4.x/custom-navigator-overview.md | 2 +- versioned_docs/version-4.x/drawer-actions.md | 6 +++--- versioned_docs/version-4.x/header-buttons.md | 1 - versioned_docs/version-4.x/headers.md | 5 ++--- .../version-4.x/hello-react-navigation.md | 1 - versioned_docs/version-4.x/modal.md | 1 - versioned_docs/version-4.x/navigating.md | 1 - versioned_docs/version-4.x/navigation-actions.md | 1 - versioned_docs/version-4.x/navigation-events.md | 2 +- versioned_docs/version-4.x/navigation-key.md | 6 +++--- versioned_docs/version-4.x/navigation-lifecycle.md | 2 +- .../version-4.x/navigation-options-resolution.md | 10 +++++----- versioned_docs/version-4.x/params.md | 1 - versioned_docs/version-5.x/headers.md | 4 ++-- versioned_docs/version-5.x/navigation-state.md | 6 +++--- versioned_docs/version-6.x/navigation-state.md | 6 +++--- versioned_docs/version-6.x/state-persistence.md | 2 +- versioned_docs/version-6.x/troubleshooting.md | 2 +- versioned_docs/version-6.x/upgrading-from-5.x.md | 4 ++-- versioned_docs/version-7.x/multiple-drawers.md | 4 ++-- versioned_docs/version-7.x/navigation-actions.md | 4 ++-- versioned_docs/version-7.x/navigation-object.md | 8 ++++---- versioned_docs/version-7.x/navigation-state.md | 6 +++--- versioned_docs/version-7.x/state-persistence.md | 2 +- versioned_docs/version-7.x/troubleshooting.md | 2 +- versioned_docs/version-7.x/upgrading-from-6.x.md | 12 ++++++------ 52 files changed, 91 insertions(+), 111 deletions(-) diff --git a/blog/2020-02-06-react-navigation-5.0.md b/blog/2020-02-06-react-navigation-5.0.md index d167bd53faa..fd15458e996 100644 --- a/blog/2020-02-06-react-navigation-5.0.md +++ b/blog/2020-02-06-react-navigation-5.0.md @@ -53,7 +53,7 @@ Hooks are great for stateful logic and code organization. Now we have several ho ### Update options from component -We’ve added a new [`setOptions`](/docs/5.x/navigation-prop#setoptions---update-screen-options-from-the-component) method on the `navigation` prop to make configuring screen navigation options more intuitive than its `static navigationOptions` predecessor. It lets us **easily set screen options based on props, state or context without messing with params**. Instead of using static options, we can call it anytime to configure the screen. +We’ve added a new [`setOptions`](/docs/5.x/navigation-prop#setoptions) method on the `navigation` prop to make configuring screen navigation options more intuitive than its `static navigationOptions` predecessor. It lets us **easily set screen options based on props, state or context without messing with params**. Instead of using static options, we can call it anytime to configure the screen. ```js navigation.setOptions({ diff --git a/docusaurus.config.js b/docusaurus.config.js index 7ad8ff625d9..dd90010233c 100755 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -12,6 +12,8 @@ export default { favicon: 'img/favicon.ico', organizationName: 'react-navigation', projectName: 'react-navigation.github.io', + onBrokenAnchors: 'throw', + onBrokenMarkdownLinks: 'throw', scripts: ['/js/snack-helpers.js', '/js/toc-fixes.js'], themeConfig: { colorMode: { diff --git a/static/js/snack-helpers.js b/static/js/snack-helpers.js index 907443b3781..66f7f19df11 100644 --- a/static/js/snack-helpers.js +++ b/static/js/snack-helpers.js @@ -184,24 +184,11 @@ function appendSnackLink() { }); } -// This is used to update links like the following: -// [Full source of what we have built so far](#example/full-screen-modal) -function transformExistingSnackLinks() { - document.querySelectorAll('a[href*="#example/"]').forEach((a) => { - let urlParts = a.href.split('#example/'); - let templateId = urlParts[urlParts.length - 1]; - a.href = getSnackUrl({ templateId }); - a.target = '_blank'; - }); -} - function initializeSnackObservers() { appendSnackLink(); - transformExistingSnackLinks(); const mutationObserver = new MutationObserver((mutations) => { mutations.forEach(appendSnackLink); - mutations.forEach(transformExistingSnackLinks); }); mutationObserver.observe(document.documentElement, { diff --git a/versioned_docs/version-1.x/navigation-actions.md b/versioned_docs/version-1.x/navigation-actions.md index 43794b24941..361460ce185 100644 --- a/versioned_docs/version-1.x/navigation-actions.md +++ b/versioned_docs/version-1.x/navigation-actions.md @@ -13,15 +13,15 @@ The following actions are supported: - [Navigate](#navigate) - Navigate to another route - [Back](#back) - Go back to previous state - [Set Params](#setparams) - Set Params for given route -- [Init](#init) - Used to initialize first state if state is undefined +- Init - Used to initialize first state if state is undefined Within a stack, you can also use: - [Reset](#reset) - Replace current state with a new state - [Replace](#replace) - Replace a route at a given key with another route -- [Push](#push) - Add a route on the top of the stack, and navigate forward to it -- [Pop](#pop) - Navigate back to previous routes -- [PopToTop](#poptotop) - Navigate to the top route of the stack, dismissing all other routes +- Push - Add a route on the top of the stack, and navigate forward to it +- Pop - Navigate back to previous routes +- PopToTop - Navigate to the top route of the stack, dismissing all other routes The action creator functions define `toString()` to return the action type, which enables easy usage with third-party Redux libraries, including redux-actions and redux-saga. diff --git a/versioned_docs/version-1.x/navigation-options.md b/versioned_docs/version-1.x/navigation-options.md index b5cd08a7e31..5cd2848c3cb 100644 --- a/versioned_docs/version-1.x/navigation-options.md +++ b/versioned_docs/version-1.x/navigation-options.md @@ -102,5 +102,5 @@ List of available navigation options depends on the `navigator` the screen is ad Check available options for: - [`drawer navigator`](drawer-navigator.md#screen-navigation-options) -- [`stack navigator`](stack-navigator.md#screen-navigation-options) -- [`tab navigator`](tab-navigator.md#screen-navigation-options) +- [`stack navigator`](stack-navigator.md#navigationoptions-used-by-stacknavigator) +- [`tab navigator`](tab-navigator.md#navigationoptions-used-by-tabnavigator) diff --git a/versioned_docs/version-1.x/redux-integration.md b/versioned_docs/version-1.x/redux-integration.md index d0064b7fa15..bb6fadee8ec 100644 --- a/versioned_docs/version-1.x/redux-integration.md +++ b/versioned_docs/version-1.x/redux-integration.md @@ -14,7 +14,7 @@ _You probably do not need to do this!_ Storing your React Navigation state in yo 1. To handle your app's navigation state in Redux, you can pass your own `navigation` prop to a navigator. -2. Once you pass your own navigation prop to the navigator, the default [`navigation`](navigation-prop.md) prop gets destroyed. You must construct your own `navigation` prop with [`state`](navigation-prop.md#state-the-screen-s-current-state-route), [`dispatch`](navigation-prop.md#dispatch-send-an-action-to-the-router), and `addListener` properties. +2. Once you pass your own navigation prop to the navigator, the default [`navigation`](navigation-prop.md) prop gets destroyed. You must construct your own `navigation` prop with [`state`](navigation-prop.md#state---the-screens-current-stateroute), [`dispatch`](navigation-prop.md#dispatch---send-an-action-to-the-router), and `addListener` properties. 3. The `state` will be fed from the reducer assigned to handle navigation state and the `dispatch` will be Redux's default `dispatch`. Thus you will be able to dispatch normal redux actions using `this.props.navigation.dispatch(ACTION)`, reducer will update the navigation state on the basis of dispatched action, the new navigation state will then be passed to the navigator. diff --git a/versioned_docs/version-2.x/custom-android-back-button-handling.md b/versioned_docs/version-2.x/custom-android-back-button-handling.md index 10b48240c14..0b5f3beb7de 100644 --- a/versioned_docs/version-2.x/custom-android-back-button-handling.md +++ b/versioned_docs/version-2.x/custom-android-back-button-handling.md @@ -8,7 +8,7 @@ By default, when user presses the Android hardware back button, react-navigation > If you're looking for an easy-to-use solution, you can check out a community-developed package [react-navigation-backhandler](https://github.com/vonovak/react-navigation-backhandler). The following text shows what the package does under the cover. -As an example, consider a screen where user is selecting items in a list, and a "selection mode" is active. On a back button press, you would first want the "selection mode" to be deactivated, and the screen should be popped only on the second back button press. The following code snippet demonstrates the situation. We make use of [`BackHandler`](https://reactnative.dev/docs/backhandler.html) which comes with react-native and we [subscribe to navigation lifecycle updates](navigation-prop.md#addlistener-subscribe-to-updates-to-navigation-lifecycle) to add our custom `hardwareBackPress` listener. +As an example, consider a screen where user is selecting items in a list, and a "selection mode" is active. On a back button press, you would first want the "selection mode" to be deactivated, and the screen should be popped only on the second back button press. The following code snippet demonstrates the situation. We make use of [`BackHandler`](https://reactnative.dev/docs/backhandler.html) which comes with react-native and we [subscribe to navigation lifecycle updates](navigation-prop.md#addlistener---subscribe-to-updates-to-navigation-lifecycle) to add our custom `hardwareBackPress` listener. Returning `true` from `onBackButtonPressAndroid` denotes that we have handled the event, and react-navigation's listener will not get called, thus not popping the screen. Returning `false` will cause the event to bubble up and react-navigation's listener will pop the screen. diff --git a/versioned_docs/version-2.x/custom-navigator-overview.md b/versioned_docs/version-2.x/custom-navigator-overview.md index a633b82f0d0..c1323d63ce7 100644 --- a/versioned_docs/version-2.x/custom-navigator-overview.md +++ b/versioned_docs/version-2.x/custom-navigator-overview.md @@ -24,7 +24,7 @@ The navigators render application screens which are just React components. To learn how to create screens, read about: - [Screen `navigation` prop](navigation-prop.md) to allow the screen to dispatch navigation actions, such as opening another screen -- Screen `navigationOptions` to customize how the screen gets presented by the navigator (e.g. [header title](stack-navigator.md#navigationoptions-used-by-stacknavigator), tab label) +- Screen `navigationOptions` to customize how the screen gets presented by the navigator (e.g. [header title](stack-navigator.md#navigationoptions-for-screens-inside-of-the-navigator), tab label) ### Calling Navigate on Top Level Component diff --git a/versioned_docs/version-2.x/drawer-actions.md b/versioned_docs/version-2.x/drawer-actions.md index 800725f688e..44f67c73056 100644 --- a/versioned_docs/version-2.x/drawer-actions.md +++ b/versioned_docs/version-2.x/drawer-actions.md @@ -8,9 +8,9 @@ sidebar_label: DrawerActions The following actions are supported: -- [openDrawer](#openDrawer) - open the drawer -- [closeDrawer](#closeDrawer) - close the drawer -- [toggleDrawer](#toggleDrawer) - toggle the state, ie. switch from closed to open and vice versa +- openDrawer - open the drawer +- closeDrawer - close the drawer +- toggleDrawer - toggle the state, ie. switch from closed to open and vice versa ### Usage diff --git a/versioned_docs/version-2.x/headers.md b/versioned_docs/version-2.x/headers.md index fb5b547f22d..e4c4d144f98 100644 --- a/versioned_docs/version-2.x/headers.md +++ b/versioned_docs/version-2.x/headers.md @@ -202,11 +202,11 @@ class HomeScreen extends React.Component { ## Additional configuration -You can read the full list of available `navigationOptions` for screens inside of a stack navigator in the [`createStackNavigator` reference](stack-navigator.md#navigationoptions-used-by-stacknavigator). +You can read the full list of available `navigationOptions` for screens inside of a stack navigator in the [`createStackNavigator` reference](stack-navigator.md#navigationoptions-for-screens-inside-of-the-navigator). ## Summary -- You can customize the header inside of the `navigationOptions` static property on your screen components. Read the full list of options [in the API reference](stack-navigator.md#navigationoptions-used-by-stacknavigator). +- You can customize the header inside of the `navigationOptions` static property on your screen components. Read the full list of options [in the API reference](stack-navigator.md#navigationoptions-for-screens-inside-of-the-navigator). - The `navigationOptions` static property can be an object or a function. When it is a function, it is provided with an object with the `navigation` prop, `screenProps`, and `navigationOptions` on it. - You can also specify shared `navigationOptions` in the stack navigator configuration when you initialize it. The static property takes precedence over that configuration. - [Full source of what we have built so far](https://snack.expo.io/@react-navigation/custom-header-title-component-v2). diff --git a/versioned_docs/version-2.x/navigation-actions.md b/versioned_docs/version-2.x/navigation-actions.md index 04fa334796c..a0ff2cc460d 100644 --- a/versioned_docs/version-2.x/navigation-actions.md +++ b/versioned_docs/version-2.x/navigation-actions.md @@ -13,7 +13,6 @@ The following actions are supported: - [Navigate](#navigate) - Navigate to another route - [Back](#back) - Go back to previous state - [Set Params](#setparams) - Set Params for given route -- [Init](#init) - Used to initialize first state if state is undefined For actions specific to a StackNavigator, see [StackActions](stack-actions.md). diff --git a/versioned_docs/version-2.x/navigation-events.md b/versioned_docs/version-2.x/navigation-events.md index 088c0c082bd..a258d361e33 100644 --- a/versioned_docs/version-2.x/navigation-events.md +++ b/versioned_docs/version-2.x/navigation-events.md @@ -14,7 +14,7 @@ sidebar_label: NavigationEvents - `onWillBlur` - event listener - `onDidBlur` - event listener -The event listener is the same as the imperative [`navigation.addListener(...)`](navigation-prop.md#addlistener-subscribe-to-updates-to-navigation-lifecycle) API. +The event listener is the same as the imperative [`navigation.addListener(...)`](navigation-prop.md#addlistener---subscribe-to-updates-to-navigation-lifecycle) API. ### Example diff --git a/versioned_docs/version-2.x/navigation-key.md b/versioned_docs/version-2.x/navigation-key.md index 8655464c291..941c6189082 100644 --- a/versioned_docs/version-2.x/navigation-key.md +++ b/versioned_docs/version-2.x/navigation-key.md @@ -17,14 +17,14 @@ If, however, you want to push several instances of the same route, you can do so > Note: the behavior of `navigate` without a `key` is significantly different in the 1.x series of releases. Read more about it [here](https://gist.github.com/vonovak/ef72f5efe1d36742de8968ff6a708985). -### Usage with [`reset`](navigation-actions.md#reset) +### Usage with [`reset`](stack-actions.md#reset) When resetting, `key` is also optional and can be a string or `null`. If set, the navigator with the given key will reset. If `null`, the root navigator will reset. You can obtain a route's navigator key by calling `this.props.navigation.dangerouslyGetParent().state.key`. Reason why the function is called `dangerouslyGetParent` is to warn developers against overusing it to eg. get parent of parent and other hard-to-follow patterns. -### Usage with [`replace`](navigation-actions.md#replace) +### Usage with [`replace`](stack-actions.md#replace) With the `replace` navigation action, `key` is a required parameter used for identifying the route to be replaced. If you use the helper function `this.props.navigation.replace`, we will automatically substitute the key of the current route. ### Usage with `goBack` -Please refer to the [`goBack docs`](navigation-prop.md#goback-close-the-active-screen-and-move-back) for a detailed explanation. +Please refer to the [`goBack docs`](navigation-prop.md#goback---close-the-active-screen-and-move-back) for a detailed explanation. diff --git a/versioned_docs/version-2.x/navigation-lifecycle.md b/versioned_docs/version-2.x/navigation-lifecycle.md index 7ece38a19b4..e6210d5f11e 100644 --- a/versioned_docs/version-2.x/navigation-lifecycle.md +++ b/versioned_docs/version-2.x/navigation-lifecycle.md @@ -41,7 +41,7 @@ We start on the `HomeScreen` and navigate to `DetailsScreen`. Then we use the ta Now that we understand how React lifecycle methods work in React Navigation, let's answer the question we asked at the beginning: "How do we find out that a user is leaving it or coming back to it?" -React Navigation emits events to screen components that subscribe to them. There are four different events that you can subscribe to: `willFocus`, `willBlur`, `didFocus` and `didBlur`. Read more about them in the [API reference](navigation-prop.md#addlistener-subscribe-to-updates-to-navigation-lifecycle). +React Navigation emits events to screen components that subscribe to them. There are four different events that you can subscribe to: `willFocus`, `willBlur`, `didFocus` and `didBlur`. Read more about them in the [API reference](navigation-prop.md#addlistener---subscribe-to-updates-to-navigation-lifecycle). Many of your use cases may be covered with the [`withNavigationFocus` HOC](with-navigation-focus.md) or the [`` component](navigation-events.md) which are a little more straightforward to use. diff --git a/versioned_docs/version-2.x/navigation-options-resolution.md b/versioned_docs/version-2.x/navigation-options-resolution.md index 80c91173736..746b673e557 100644 --- a/versioned_docs/version-2.x/navigation-options-resolution.md +++ b/versioned_docs/version-2.x/navigation-options-resolution.md @@ -108,7 +108,7 @@ HomeStack.navigationOptions = { We understand that overloading the naming here is a little bit confusing. Please [open a RFC](https://github.com/react-navigation/rfcs) if you have a suggestion about how we can make this API easier to learn and work with. -# A stack contains a tab navigator and you want to set the title on the stack header +## A stack contains a tab navigator and you want to set the title on the stack header Imagine the following configuration: @@ -177,7 +177,7 @@ Using this configuration, the `headerTitle` or `title` from `navigationOptions` Additionally, you can push new screens to the feed and profile stacks without hiding the tab bar by adding more routes to those stacks. If you want to push screens on top of the tab bar, then you can add them to the `AppNavigator` stack. -# A tab navigator contains a stack and you want to hide the tab bar on specific screens +## A tab navigator contains a stack and you want to hide the tab bar on specific screens Similar to the example above where a stack contains a tab navigator, we can solve this in two ways: add `navigationOptions` to our tab navigator to set the tab bar to hidden depending on which route is active in the child stack, or we can move the tab navigator inside of the stack. @@ -247,7 +247,7 @@ const AppNavigator = createSwitchNavigator({ }); ``` -# A drawer has a stack inside of it and you want to lock the drawer on certain screens +## A drawer has a stack inside of it and you want to lock the drawer on certain screens This is conceptually identical to having a tab with a stack inside of it (read that above if you have not already), where you want to hide the tab bar on certain screens. The only difference is that rather than using `tabBarVisible` you will use `drawerLockMode`. diff --git a/versioned_docs/version-3.x/MST-integration.md b/versioned_docs/version-3.x/MST-integration.md index 2ce8a8755f6..93e55fac08e 100644 --- a/versioned_docs/version-3.x/MST-integration.md +++ b/versioned_docs/version-3.x/MST-integration.md @@ -61,7 +61,7 @@ export const NavigationStore = types })); ``` -Note that `userProfileScreenParams` is a simple model with a `user` entry, while `productDetailScreenParams` is a map of `ProductDetailScreenParams` model. The reason we chose this shape of data is that we only have a single user profile screen in our app which reads its params from `userProfileScreenParams`. `productDetailScreenParams` is a map because the app can have several product screens on a stack. Each screen points to a `Product` instance saved in the map. The keys into the map are the React Navigation [keys](navigation-key.md#usage-with-the-navigate-navigation-actionshtml-navigate-call): think of the `key` as of an identifier of the route. +Note that `userProfileScreenParams` is a simple model with a `user` entry, while `productDetailScreenParams` is a map of `ProductDetailScreenParams` model. The reason we chose this shape of data is that we only have a single user profile screen in our app which reads its params from `userProfileScreenParams`. `productDetailScreenParams` is a map because the app can have several product screens on a stack. Each screen points to a `Product` instance saved in the map. The keys into the map are the React Navigation [keys](navigation-key.md#usage-with-the-navigate-call): think of the `key` as of an identifier of the route. Your navigation store may also be just one map where for each screen (regardless if it is a product or user profile screen), we store its navigation params. This is the approach taken in the [sample app](https://github.com/vonovak/react-navigation-mst-demo). diff --git a/versioned_docs/version-3.x/custom-android-back-button-handling.md b/versioned_docs/version-3.x/custom-android-back-button-handling.md index 10b48240c14..0b5f3beb7de 100644 --- a/versioned_docs/version-3.x/custom-android-back-button-handling.md +++ b/versioned_docs/version-3.x/custom-android-back-button-handling.md @@ -8,7 +8,7 @@ By default, when user presses the Android hardware back button, react-navigation > If you're looking for an easy-to-use solution, you can check out a community-developed package [react-navigation-backhandler](https://github.com/vonovak/react-navigation-backhandler). The following text shows what the package does under the cover. -As an example, consider a screen where user is selecting items in a list, and a "selection mode" is active. On a back button press, you would first want the "selection mode" to be deactivated, and the screen should be popped only on the second back button press. The following code snippet demonstrates the situation. We make use of [`BackHandler`](https://reactnative.dev/docs/backhandler.html) which comes with react-native and we [subscribe to navigation lifecycle updates](navigation-prop.md#addlistener-subscribe-to-updates-to-navigation-lifecycle) to add our custom `hardwareBackPress` listener. +As an example, consider a screen where user is selecting items in a list, and a "selection mode" is active. On a back button press, you would first want the "selection mode" to be deactivated, and the screen should be popped only on the second back button press. The following code snippet demonstrates the situation. We make use of [`BackHandler`](https://reactnative.dev/docs/backhandler.html) which comes with react-native and we [subscribe to navigation lifecycle updates](navigation-prop.md#addlistener---subscribe-to-updates-to-navigation-lifecycle) to add our custom `hardwareBackPress` listener. Returning `true` from `onBackButtonPressAndroid` denotes that we have handled the event, and react-navigation's listener will not get called, thus not popping the screen. Returning `false` will cause the event to bubble up and react-navigation's listener will pop the screen. diff --git a/versioned_docs/version-3.x/custom-navigator-overview.md b/versioned_docs/version-3.x/custom-navigator-overview.md index 97826743dd7..39699c3bda9 100644 --- a/versioned_docs/version-3.x/custom-navigator-overview.md +++ b/versioned_docs/version-3.x/custom-navigator-overview.md @@ -24,4 +24,4 @@ The navigators render application screens which are just React components. To learn how to create screens, read about: - [Screen `navigation` prop](navigation-prop.md) to allow the screen to dispatch navigation actions, such as opening another screen -- Screen `navigationOptions` to customize how the screen gets presented by the navigator (e.g. [header title](stack-navigator.md#navigationoptions-used-by-stacknavigator), tab label) +- Screen `navigationOptions` to customize how the screen gets presented by the navigator (e.g. [header title](stack-navigator.md#navigationoptions-for-screens-inside-of-the-navigator), tab label) diff --git a/versioned_docs/version-3.x/drawer-actions.md b/versioned_docs/version-3.x/drawer-actions.md index 800725f688e..44f67c73056 100644 --- a/versioned_docs/version-3.x/drawer-actions.md +++ b/versioned_docs/version-3.x/drawer-actions.md @@ -8,9 +8,9 @@ sidebar_label: DrawerActions The following actions are supported: -- [openDrawer](#openDrawer) - open the drawer -- [closeDrawer](#closeDrawer) - close the drawer -- [toggleDrawer](#toggleDrawer) - toggle the state, ie. switch from closed to open and vice versa +- openDrawer - open the drawer +- closeDrawer - close the drawer +- toggleDrawer - toggle the state, ie. switch from closed to open and vice versa ### Usage diff --git a/versioned_docs/version-3.x/headers.md b/versioned_docs/version-3.x/headers.md index 8ee2f7cfce1..cc00a8848a0 100644 --- a/versioned_docs/version-3.x/headers.md +++ b/versioned_docs/version-3.x/headers.md @@ -230,11 +230,11 @@ class HomeScreen extends React.Component { ## Additional configuration -You can read the full list of available `navigationOptions` for screens inside of a stack navigator in the [`createStackNavigator` reference](stack-navigator.md#navigationoptions-used-by-stacknavigator). +You can read the full list of available `navigationOptions` for screens inside of a stack navigator in the [`createStackNavigator` reference](stack-navigator.md#navigationoptions-for-screens-inside-of-the-navigator). ## Summary -- You can customize the header inside of the `navigationOptions` static property on your screen components. Read the full list of options [in the API reference](stack-navigator.md#navigationoptions-used-by-stacknavigator). +- You can customize the header inside of the `navigationOptions` static property on your screen components. Read the full list of options [in the API reference](stack-navigator.md#navigationoptions-for-screens-inside-of-the-navigator). - The `navigationOptions` static property can be an object or a function. When it is a function, it is provided with an object with the `navigation` prop, `screenProps`, and `navigationOptions` on it. - You can also specify shared `navigationOptions` in the stack navigator configuration when you initialize it. The static property takes precedence over that configuration. - [Full source of what we have built so far](https://snack.expo.io/@react-navigation/custom-header-title-component-v3). diff --git a/versioned_docs/version-3.x/navigation-actions.md b/versioned_docs/version-3.x/navigation-actions.md index 04fa334796c..a0ff2cc460d 100644 --- a/versioned_docs/version-3.x/navigation-actions.md +++ b/versioned_docs/version-3.x/navigation-actions.md @@ -13,7 +13,6 @@ The following actions are supported: - [Navigate](#navigate) - Navigate to another route - [Back](#back) - Go back to previous state - [Set Params](#setparams) - Set Params for given route -- [Init](#init) - Used to initialize first state if state is undefined For actions specific to a StackNavigator, see [StackActions](stack-actions.md). diff --git a/versioned_docs/version-3.x/navigation-events.md b/versioned_docs/version-3.x/navigation-events.md index 088c0c082bd..a258d361e33 100644 --- a/versioned_docs/version-3.x/navigation-events.md +++ b/versioned_docs/version-3.x/navigation-events.md @@ -14,7 +14,7 @@ sidebar_label: NavigationEvents - `onWillBlur` - event listener - `onDidBlur` - event listener -The event listener is the same as the imperative [`navigation.addListener(...)`](navigation-prop.md#addlistener-subscribe-to-updates-to-navigation-lifecycle) API. +The event listener is the same as the imperative [`navigation.addListener(...)`](navigation-prop.md#addlistener---subscribe-to-updates-to-navigation-lifecycle) API. ### Example diff --git a/versioned_docs/version-3.x/navigation-key.md b/versioned_docs/version-3.x/navigation-key.md index 8655464c291..941c6189082 100644 --- a/versioned_docs/version-3.x/navigation-key.md +++ b/versioned_docs/version-3.x/navigation-key.md @@ -17,14 +17,14 @@ If, however, you want to push several instances of the same route, you can do so > Note: the behavior of `navigate` without a `key` is significantly different in the 1.x series of releases. Read more about it [here](https://gist.github.com/vonovak/ef72f5efe1d36742de8968ff6a708985). -### Usage with [`reset`](navigation-actions.md#reset) +### Usage with [`reset`](stack-actions.md#reset) When resetting, `key` is also optional and can be a string or `null`. If set, the navigator with the given key will reset. If `null`, the root navigator will reset. You can obtain a route's navigator key by calling `this.props.navigation.dangerouslyGetParent().state.key`. Reason why the function is called `dangerouslyGetParent` is to warn developers against overusing it to eg. get parent of parent and other hard-to-follow patterns. -### Usage with [`replace`](navigation-actions.md#replace) +### Usage with [`replace`](stack-actions.md#replace) With the `replace` navigation action, `key` is a required parameter used for identifying the route to be replaced. If you use the helper function `this.props.navigation.replace`, we will automatically substitute the key of the current route. ### Usage with `goBack` -Please refer to the [`goBack docs`](navigation-prop.md#goback-close-the-active-screen-and-move-back) for a detailed explanation. +Please refer to the [`goBack docs`](navigation-prop.md#goback---close-the-active-screen-and-move-back) for a detailed explanation. diff --git a/versioned_docs/version-3.x/navigation-lifecycle.md b/versioned_docs/version-3.x/navigation-lifecycle.md index 7ece38a19b4..e6210d5f11e 100644 --- a/versioned_docs/version-3.x/navigation-lifecycle.md +++ b/versioned_docs/version-3.x/navigation-lifecycle.md @@ -41,7 +41,7 @@ We start on the `HomeScreen` and navigate to `DetailsScreen`. Then we use the ta Now that we understand how React lifecycle methods work in React Navigation, let's answer the question we asked at the beginning: "How do we find out that a user is leaving it or coming back to it?" -React Navigation emits events to screen components that subscribe to them. There are four different events that you can subscribe to: `willFocus`, `willBlur`, `didFocus` and `didBlur`. Read more about them in the [API reference](navigation-prop.md#addlistener-subscribe-to-updates-to-navigation-lifecycle). +React Navigation emits events to screen components that subscribe to them. There are four different events that you can subscribe to: `willFocus`, `willBlur`, `didFocus` and `didBlur`. Read more about them in the [API reference](navigation-prop.md#addlistener---subscribe-to-updates-to-navigation-lifecycle). Many of your use cases may be covered with the [`withNavigationFocus` HOC](with-navigation-focus.md) or the [`` component](navigation-events.md) which are a little more straightforward to use. diff --git a/versioned_docs/version-3.x/navigation-options-resolution.md b/versioned_docs/version-3.x/navigation-options-resolution.md index c0461b7245d..3ab0a7263e9 100644 --- a/versioned_docs/version-3.x/navigation-options-resolution.md +++ b/versioned_docs/version-3.x/navigation-options-resolution.md @@ -126,7 +126,7 @@ const HomeStack = createStackNavigator( → Run this code -# getActiveChildNavigationOptions +## getActiveChildNavigationOptions If you would like to get the `navigationOptions` from the active child of a navigator, you can do that with `getActiveChildNavigationOptions`. This makes it possible for you to set the `tabBarLabel` directly on a screen inside of a stack that is inside of a tab, for example. @@ -157,11 +157,11 @@ const HomeStack = createStackNavigator( → Run this code -# **Note**: the navigationOptions property vs navigator configuration +## **Note**: the navigationOptions property vs navigator configuration Navigators are initialized with `create*Navigator(routeConfig, navigatorConfig)`. Inside of `navigatorConfig` we can add a `defaultNavigationOptions` property. These `defaultNavigationOptions` are the default options for screens within that navigator ([read more about sharing common navigationOptions](headers.md#sharing-common-navigationoptions-across-screens)), they do not refer to the `navigationOptions` for that navigator — as we have seen above, we set the `navigationOptions` property directly on the navigator for that use case. -# A stack contains a tab navigator and you want to set the title on the stack header +## A stack contains a tab navigator and you want to set the title on the stack header Imagine the following configuration: @@ -230,7 +230,7 @@ Using this configuration, the `headerTitle` or `title` from `navigationOptions` Additionally, you can push new screens to the feed and profile stacks without hiding the tab bar by adding more routes to those stacks. If you want to push screens on top of the tab bar, then you can add them to the `AppNavigator` stack. -# A tab navigator contains a stack and you want to hide the tab bar on specific screens +## A tab navigator contains a stack and you want to hide the tab bar on specific screens Similar to the example above where a stack contains a tab navigator, we can solve this in two ways: add `navigationOptions` to our tab navigator to set the tab bar to hidden depending on which route is active in the child stack, or we can move the tab navigator inside of the stack. @@ -300,7 +300,7 @@ const AppNavigator = createSwitchNavigator({ }); ``` -# A drawer has a stack inside of it and you want to lock the drawer on certain screens +## A drawer has a stack inside of it and you want to lock the drawer on certain screens This is conceptually identical to having a tab with a stack inside of it (read that above if you have not already), where you want to hide the tab bar on certain screens. The only difference is that rather than using `tabBarVisible` you will use `drawerLockMode`. diff --git a/versioned_docs/version-4.x/MST-integration.md b/versioned_docs/version-4.x/MST-integration.md index 2ce8a8755f6..93e55fac08e 100644 --- a/versioned_docs/version-4.x/MST-integration.md +++ b/versioned_docs/version-4.x/MST-integration.md @@ -61,7 +61,7 @@ export const NavigationStore = types })); ``` -Note that `userProfileScreenParams` is a simple model with a `user` entry, while `productDetailScreenParams` is a map of `ProductDetailScreenParams` model. The reason we chose this shape of data is that we only have a single user profile screen in our app which reads its params from `userProfileScreenParams`. `productDetailScreenParams` is a map because the app can have several product screens on a stack. Each screen points to a `Product` instance saved in the map. The keys into the map are the React Navigation [keys](navigation-key.md#usage-with-the-navigate-navigation-actionshtml-navigate-call): think of the `key` as of an identifier of the route. +Note that `userProfileScreenParams` is a simple model with a `user` entry, while `productDetailScreenParams` is a map of `ProductDetailScreenParams` model. The reason we chose this shape of data is that we only have a single user profile screen in our app which reads its params from `userProfileScreenParams`. `productDetailScreenParams` is a map because the app can have several product screens on a stack. Each screen points to a `Product` instance saved in the map. The keys into the map are the React Navigation [keys](navigation-key.md#usage-with-the-navigate-call): think of the `key` as of an identifier of the route. Your navigation store may also be just one map where for each screen (regardless if it is a product or user profile screen), we store its navigation params. This is the approach taken in the [sample app](https://github.com/vonovak/react-navigation-mst-demo). diff --git a/versioned_docs/version-4.x/custom-navigator-overview.md b/versioned_docs/version-4.x/custom-navigator-overview.md index 97826743dd7..39699c3bda9 100644 --- a/versioned_docs/version-4.x/custom-navigator-overview.md +++ b/versioned_docs/version-4.x/custom-navigator-overview.md @@ -24,4 +24,4 @@ The navigators render application screens which are just React components. To learn how to create screens, read about: - [Screen `navigation` prop](navigation-prop.md) to allow the screen to dispatch navigation actions, such as opening another screen -- Screen `navigationOptions` to customize how the screen gets presented by the navigator (e.g. [header title](stack-navigator.md#navigationoptions-used-by-stacknavigator), tab label) +- Screen `navigationOptions` to customize how the screen gets presented by the navigator (e.g. [header title](stack-navigator.md#navigationoptions-for-screens-inside-of-the-navigator), tab label) diff --git a/versioned_docs/version-4.x/drawer-actions.md b/versioned_docs/version-4.x/drawer-actions.md index 91dd2574ae8..c09626ede59 100644 --- a/versioned_docs/version-4.x/drawer-actions.md +++ b/versioned_docs/version-4.x/drawer-actions.md @@ -8,9 +8,9 @@ sidebar_label: DrawerActions The following actions are supported: -- [openDrawer](#openDrawer) - open the drawer -- [closeDrawer](#closeDrawer) - close the drawer -- [toggleDrawer](#toggleDrawer) - toggle the state, ie. switches from closed to open and vice versa +- openDrawer - open the drawer +- closeDrawer - close the drawer +- toggleDrawer - toggle the state, ie. switches from closed to open and vice versa ### Usage diff --git a/versioned_docs/version-4.x/header-buttons.md b/versioned_docs/version-4.x/header-buttons.md index 3d218a8ceae..47466e9994d 100644 --- a/versioned_docs/version-4.x/header-buttons.md +++ b/versioned_docs/version-4.x/header-buttons.md @@ -90,4 +90,3 @@ Generally, this is what you want. But it's possible that in some circumstances t - You can set buttons in the header through the `headerLeft` and `headerRight` properties in `navigationOptions`. - The back button is fully customizable with `headerLeft`, but if you just want to change the title or image, there are other `navigationOptions` for that — `headerBackTitle`, `headerTruncatedBackTitle`, and `headerBackImage`. -- [Full source of what we have built so far](#example/header-interaction). diff --git a/versioned_docs/version-4.x/headers.md b/versioned_docs/version-4.x/headers.md index a064dfbe26b..8b93bc3ff2f 100644 --- a/versioned_docs/version-4.x/headers.md +++ b/versioned_docs/version-4.x/headers.md @@ -230,11 +230,10 @@ class HomeScreen extends React.Component { ## Additional configuration -You can read the full list of available `navigationOptions` for screens inside of a stack navigator in the [`createStackNavigator` reference](stack-navigator.md#navigationoptions-used-by-stacknavigator). +You can read the full list of available `navigationOptions` for screens inside of a stack navigator in the [`createStackNavigator` reference](stack-navigator.md#navigationoptions-for-screens-inside-of-the-navigator). ## Summary -- You can customize the header inside of the `navigationOptions` static property on your screen components. Read the full list of options [in the API reference](stack-navigator.md#navigationoptions-used-by-stacknavigator). +- You can customize the header inside of the `navigationOptions` static property on your screen components. Read the full list of options [in the API reference](stack-navigator.md#navigationoptions-for-screens-inside-of-the-navigator). - The `navigationOptions` static property can be an object or a function. When it is a function, it is provided with an object with the `navigation` prop, `screenProps`, and `navigationOptions` on it. - You can also specify shared `navigationOptions` in the stack navigator configuration when you initialize it. The static property takes precedence over that configuration. -- [Full source of what we have built so far](#example/custom-header-title-component). diff --git a/versioned_docs/version-4.x/hello-react-navigation.md b/versioned_docs/version-4.x/hello-react-navigation.md index f52560019ad..e45acbff1b8 100644 --- a/versioned_docs/version-4.x/hello-react-navigation.md +++ b/versioned_docs/version-4.x/hello-react-navigation.md @@ -115,4 +115,3 @@ Now our stack has two _routes_, a `Home` route and a `Details` route. The `Home` - `createStackNavigator` is a function that takes a route configuration object and an options object and returns a React component. - The keys in the route configuration object are the route names and the values are the configuration for that route. The only required property on the configuration is the `screen` (the component to use for the route). - To specify what the initial route in a stack is, provide an `initialRouteName` on the stack options object. -- [Full source of what we have built so far](#example/hello-react-navigation-full). diff --git a/versioned_docs/version-4.x/modal.md b/versioned_docs/version-4.x/modal.md index e4119780951..fe31980e201 100644 --- a/versioned_docs/version-4.x/modal.md +++ b/versioned_docs/version-4.x/modal.md @@ -91,4 +91,3 @@ There are some important things to notice here: - To change the type of transition on a stack navigator you can use the `mode` configuration. When set to `modal`, all screens animate-in from bottom to top rather than right to left. This applies to that entire stack navigator, so to use right to left transitions on other screens, we add another navigation stack with the default configuration. - `this.props.navigation.navigate` traverses up the navigator tree to find a navigator that can handle the `navigate` action. -- [Full source of what we have built so far](#example/full-screen-modal) diff --git a/versioned_docs/version-4.x/navigating.md b/versioned_docs/version-4.x/navigating.md index f12c9ddf8e6..da79fd58e5e 100644 --- a/versioned_docs/version-4.x/navigating.md +++ b/versioned_docs/version-4.x/navigating.md @@ -134,4 +134,3 @@ Another common requirement is to be able to go back _multiple_ screens -- for ex - The header bar will automatically show a back button, but you can programmatically go back by calling `this.props.navigation.goBack()`. On Android, the hardware back button just works as expected. - You can go back to an existing screen in the stack with `this.props.navigation.navigate('RouteName')`, and you can go back to the first screen in the stack with `this.props.navigation.popToTop()`. - The `navigation` prop is available to all screen components (components defined as screens in route configuration and rendered by React Navigation as a route). -- [Full source of what we have built so far](#example/go-back). diff --git a/versioned_docs/version-4.x/navigation-actions.md b/versioned_docs/version-4.x/navigation-actions.md index cf196c9c287..f8268ae5ba2 100644 --- a/versioned_docs/version-4.x/navigation-actions.md +++ b/versioned_docs/version-4.x/navigation-actions.md @@ -15,7 +15,6 @@ The following actions are supported: - [Navigate](#navigate) - Navigate to another route - [Back](#back) - Go back to previous state - [Set Params](#setparams) - Set Params for given route -- [Init](#init) - Used to initialize first state if state is undefined For actions specific to a StackNavigator, see [StackActions](stack-actions.md). For actions specific to a switch-based navigators such as TabNavigator, see [SwitchActions](switch-actions.md). diff --git a/versioned_docs/version-4.x/navigation-events.md b/versioned_docs/version-4.x/navigation-events.md index 088c0c082bd..a258d361e33 100644 --- a/versioned_docs/version-4.x/navigation-events.md +++ b/versioned_docs/version-4.x/navigation-events.md @@ -14,7 +14,7 @@ sidebar_label: NavigationEvents - `onWillBlur` - event listener - `onDidBlur` - event listener -The event listener is the same as the imperative [`navigation.addListener(...)`](navigation-prop.md#addlistener-subscribe-to-updates-to-navigation-lifecycle) API. +The event listener is the same as the imperative [`navigation.addListener(...)`](navigation-prop.md#addlistener---subscribe-to-updates-to-navigation-lifecycle) API. ### Example diff --git a/versioned_docs/version-4.x/navigation-key.md b/versioned_docs/version-4.x/navigation-key.md index 8655464c291..941c6189082 100644 --- a/versioned_docs/version-4.x/navigation-key.md +++ b/versioned_docs/version-4.x/navigation-key.md @@ -17,14 +17,14 @@ If, however, you want to push several instances of the same route, you can do so > Note: the behavior of `navigate` without a `key` is significantly different in the 1.x series of releases. Read more about it [here](https://gist.github.com/vonovak/ef72f5efe1d36742de8968ff6a708985). -### Usage with [`reset`](navigation-actions.md#reset) +### Usage with [`reset`](stack-actions.md#reset) When resetting, `key` is also optional and can be a string or `null`. If set, the navigator with the given key will reset. If `null`, the root navigator will reset. You can obtain a route's navigator key by calling `this.props.navigation.dangerouslyGetParent().state.key`. Reason why the function is called `dangerouslyGetParent` is to warn developers against overusing it to eg. get parent of parent and other hard-to-follow patterns. -### Usage with [`replace`](navigation-actions.md#replace) +### Usage with [`replace`](stack-actions.md#replace) With the `replace` navigation action, `key` is a required parameter used for identifying the route to be replaced. If you use the helper function `this.props.navigation.replace`, we will automatically substitute the key of the current route. ### Usage with `goBack` -Please refer to the [`goBack docs`](navigation-prop.md#goback-close-the-active-screen-and-move-back) for a detailed explanation. +Please refer to the [`goBack docs`](navigation-prop.md#goback---close-the-active-screen-and-move-back) for a detailed explanation. diff --git a/versioned_docs/version-4.x/navigation-lifecycle.md b/versioned_docs/version-4.x/navigation-lifecycle.md index dc72def1d0e..f40ec969cad 100644 --- a/versioned_docs/version-4.x/navigation-lifecycle.md +++ b/versioned_docs/version-4.x/navigation-lifecycle.md @@ -20,7 +20,7 @@ When going back from `B` to `A`, `componentWillUnmount` of `B` is called, but `c Now that we understand how React lifecycle methods work in React Navigation, let's answer the question we asked at the beginning: "How do we find out that a user is leaving it or coming back to it?" -React Navigation emits events to screen components that subscribe to them. There are four different events that you can subscribe to: `willFocus`, `willBlur`, `didFocus` and `didBlur`. Read more about them in the [API reference](navigation-prop.md#addlistener-subscribe-to-updates-to-navigation-lifecycle). +React Navigation emits events to screen components that subscribe to them. There are four different events that you can subscribe to: `willFocus`, `willBlur`, `didFocus` and `didBlur`. Read more about them in the [API reference](navigation-prop.md#addlistener---subscribe-to-updates-to-navigation-lifecycle). Many of your use cases may be covered with the [`withNavigationFocus` higher-order-component](with-navigation-focus.md), the [`` component](navigation-events.md), or the [useFocusState hook](https://github.com/react-navigation/hooks#usefocusstate). diff --git a/versioned_docs/version-4.x/navigation-options-resolution.md b/versioned_docs/version-4.x/navigation-options-resolution.md index 0ad9065f545..c29573edfa4 100644 --- a/versioned_docs/version-4.x/navigation-options-resolution.md +++ b/versioned_docs/version-4.x/navigation-options-resolution.md @@ -126,7 +126,7 @@ const HomeStack = createStackNavigator( → Run this code -# getActiveChildNavigationOptions +## getActiveChildNavigationOptions If you would like to get the `navigationOptions` from the active child of a navigator, you can do that with `getActiveChildNavigationOptions`. This makes it possible for you to set the `tabBarLabel` directly on a screen inside of a stack that is inside of a tab, for example. @@ -157,11 +157,11 @@ const HomeStack = createStackNavigator( → Run this code -# **Note**: the navigationOptions property vs navigator configuration +## **Note**: the navigationOptions property vs navigator configuration Navigators are initialized with `create*Navigator(routeConfig, navigatorConfig)`. Inside of `navigatorConfig` we can add a `defaultNavigationOptions` property. These `defaultNavigationOptions` are the default options for screens within that navigator ([read more about sharing common navigationOptions](headers.md#sharing-common-navigationoptions-across-screens)), they do not refer to the `navigationOptions` for that navigator — as we have seen above, we set the `navigationOptions` property directly on the navigator for that use case. -# A stack contains a tab navigator and you want to set the title on the stack header +## A stack contains a tab navigator and you want to set the title on the stack header Imagine the following configuration: @@ -230,7 +230,7 @@ Using this configuration, the `headerTitle` or `title` from `navigationOptions` Additionally, you can push new screens to the feed and profile stacks without hiding the tab bar by adding more routes to those stacks. If you want to push screens on top of the tab bar, then you can add them to the `AppNavigator` stack. -# A tab navigator contains a stack and you want to hide the tab bar on specific screens +## A tab navigator contains a stack and you want to hide the tab bar on specific screens Similar to the example above where a stack contains a tab navigator, we can solve this in two ways: add `navigationOptions` to our tab navigator to set the tab bar to hidden depending on which route is active in the child stack, or we can move the tab navigator inside of the stack. @@ -300,7 +300,7 @@ const AppNavigator = createSwitchNavigator({ }); ``` -# A drawer has a stack inside of it and you want to lock the drawer on certain screens +## A drawer has a stack inside of it and you want to lock the drawer on certain screens This is conceptually identical to having a tab with a stack inside of it (read that above if you have not already), where you want to hide the tab bar on certain screens. The only difference is that rather than using `tabBarVisible` you will use `drawerLockMode`. diff --git a/versioned_docs/version-4.x/params.md b/versioned_docs/version-4.x/params.md index f3d239d3a50..d959b7fbe47 100644 --- a/versioned_docs/version-4.x/params.md +++ b/versioned_docs/version-4.x/params.md @@ -74,4 +74,3 @@ class DetailsScreen extends React.Component { - `navigate` and `push` accept an optional second argument to let you pass parameters to the route you are navigating to. For example: `this.props.navigation.navigate('RouteName', {paramName: 'value'})`. - You can read the params through `this.props.navigation.getParam` - As an alternative to `getParam`, you may use `this.props.navigation.state.params`. It is `null` if no parameters are specified. -- [Full source of what we have built so far](#example/passing-params). diff --git a/versioned_docs/version-5.x/headers.md b/versioned_docs/version-5.x/headers.md index 027e479bfd6..bd4501e6dea 100755 --- a/versioned_docs/version-5.x/headers.md +++ b/versioned_docs/version-5.x/headers.md @@ -177,10 +177,10 @@ function StackScreen() { ## Additional configuration -You can read the full list of available `options` for screens inside of a stack navigator in the [`createStackNavigator` reference](stack-navigator.md#navigationoptions-used-by-stacknavigator). +You can read the full list of available `options` for screens inside of a stack navigator in the [`createStackNavigator` reference](stack-navigator.md#options). ## Summary -- You can customize the header inside of the `options` prop of your screen components. Read the full list of options [in the API reference](stack-navigator.md#navigationoptions-used-by-stacknavigator). +- You can customize the header inside of the `options` prop of your screen components. Read the full list of options [in the API reference](stack-navigator.md#options). - The `options` prop can be an object or a function. When it is a function, it is provided with an object with the `navigation` and `route` prop. - You can also specify shared `screenOptions` in the stack navigator configuration when you initialize it. The prop takes precedence over that configuration. diff --git a/versioned_docs/version-5.x/navigation-state.md b/versioned_docs/version-5.x/navigation-state.md index 46e5f6e5225..ffa3dd8d3a3 100644 --- a/versioned_docs/version-5.x/navigation-state.md +++ b/versioned_docs/version-5.x/navigation-state.md @@ -4,7 +4,7 @@ title: Navigation state reference sidebar_label: Navigation state --- -The navigation state is the state where React Navigation stores the navigation structure and history of the app. It's useful to know about the structure of the navigation state if you need to do advanced operations such as [resetting the state](navigation-actions.md#reset), [providing a custom initial state](navigation-container.md#initial-state) etc. +The navigation state is the state where React Navigation stores the navigation structure and history of the app. It's useful to know about the structure of the navigation state if you need to do advanced operations such as [resetting the state](navigation-actions.md#reset), [providing a custom initial state](navigation-container.md#initialstate) etc. It's a JavaScript object which looks like this: @@ -84,7 +84,7 @@ navigation.reset({ React Navigation would correct `index` to 1, and display the route and perform navigation as intended. -This feature comes handy when doing operations such as [reset](navigation-actions.md#reset), [providing a initial state](navigation-container.md#initial-state) etc., as you can safely omit many properties from the navigation state object and relying on React Navigation to add those properties for you, making your code simpler. For example, you can only provide a `routes` array without any keys and React Navigation will automatically add everything that's needed to make it work: +This feature comes handy when doing operations such as [reset](navigation-actions.md#reset), [providing a initial state](navigation-container.md#initialstate) etc., as you can safely omit many properties from the navigation state object and relying on React Navigation to add those properties for you, making your code simpler. For example, you can only provide a `routes` array without any keys and React Navigation will automatically add everything that's needed to make it work: ```js const state = { @@ -114,4 +114,4 @@ It's also possible to provide invalid data such as non-existent screens and it'l > If you want React Navigation to fix invalid state, you need to make sure that you don't have `stale: false` in the state object. State objects with `stale: false` are assumed to be valid state objects and React Navigation won't attempt to fix them. -When you're providing a state object in [`initialState`](navigation-container.md#initial-state), React Navigation will always assume that it's a stale state object, which makes sure that things like state persistence work smoothly without extra manipulation of the state object. +When you're providing a state object in [`initialState`](navigation-container.md#initialstate), React Navigation will always assume that it's a stale state object, which makes sure that things like state persistence work smoothly without extra manipulation of the state object. diff --git a/versioned_docs/version-6.x/navigation-state.md b/versioned_docs/version-6.x/navigation-state.md index 6070d146199..46d2bf13a2c 100644 --- a/versioned_docs/version-6.x/navigation-state.md +++ b/versioned_docs/version-6.x/navigation-state.md @@ -4,7 +4,7 @@ title: Navigation state reference sidebar_label: Navigation state --- -The navigation state is the state where React Navigation stores the navigation structure and history of the app. It's useful to know about the structure of the navigation state if you need to do advanced operations such as [resetting the state](navigation-actions.md#reset), [providing a custom initial state](navigation-container.md#initial-state) etc. +The navigation state is the state where React Navigation stores the navigation structure and history of the app. It's useful to know about the structure of the navigation state if you need to do advanced operations such as [resetting the state](navigation-actions.md#reset), [providing a custom initial state](navigation-container.md#initialstate) etc. It's a JavaScript object which looks like this: @@ -84,7 +84,7 @@ navigation.reset({ React Navigation would correct `index` to 1, and display the route and perform navigation as intended. -This feature comes handy when doing operations such as [reset](navigation-actions.md#reset), [providing a initial state](navigation-container.md#initial-state) etc., as you can safely omit many properties from the navigation state object and relying on React Navigation to add those properties for you, making your code simpler. For example, you can only provide a `routes` array without any keys and React Navigation will automatically add everything that's needed to make it work: +This feature comes handy when doing operations such as [reset](navigation-actions.md#reset), [providing a initial state](navigation-container.md#initialstate) etc., as you can safely omit many properties from the navigation state object and relying on React Navigation to add those properties for you, making your code simpler. For example, you can only provide a `routes` array without any keys and React Navigation will automatically add everything that's needed to make it work: ```js const state = { @@ -118,4 +118,4 @@ If you want React Navigation to fix invalid state, you need to make sure that yo ::: -When you're providing a state object in [`initialState`](navigation-container.md#initial-state), React Navigation will always assume that it's a stale state object, which makes sure that things like state persistence work smoothly without extra manipulation of the state object. +When you're providing a state object in [`initialState`](navigation-container.md#initialstate), React Navigation will always assume that it's a stale state object, which makes sure that things like state persistence work smoothly without extra manipulation of the state object. diff --git a/versioned_docs/version-6.x/state-persistence.md b/versioned_docs/version-6.x/state-persistence.md index d697850d2f4..3bde677dc8a 100755 --- a/versioned_docs/version-6.x/state-persistence.md +++ b/versioned_docs/version-6.x/state-persistence.md @@ -100,6 +100,6 @@ if (!isReady) { ## Warning: Serializable State -Each param, route, and navigation state must be fully serializable for this feature to work. Typically, you would serialize the state as a JSON string. This means that your routes and params must contain no functions, class instances, or recursive data structures. React Navigation already [warns you during development](troubleshooting.md#i-get-the-warning-"non-serializable-values-were-found-in-the-navigation-state") if it encounters non-serializable data, so watch out for the warning if you plan to persist navigation state. +Each param, route, and navigation state must be fully serializable for this feature to work. Typically, you would serialize the state as a JSON string. This means that your routes and params must contain no functions, class instances, or recursive data structures. React Navigation already [warns you during development](troubleshooting.md#i-get-the-warning-non-serializable-values-were-found-in-the-navigation-state) if it encounters non-serializable data, so watch out for the warning if you plan to persist navigation state. You can modify the initial state object before passing it to container, but note that if your `initialState` isn't a [valid navigation state](navigation-state.md#partial-state-objects), React Navigation may not be able to handle the situation gracefully. diff --git a/versioned_docs/version-6.x/troubleshooting.md b/versioned_docs/version-6.x/troubleshooting.md index 51436d92854..5a00ee9ab80 100755 --- a/versioned_docs/version-6.x/troubleshooting.md +++ b/versioned_docs/version-6.x/troubleshooting.md @@ -237,7 +237,7 @@ LogBox.ignoreLogs([ ## I'm getting "Invalid hook call. Hooks can only be called inside of the body of a function component" -This can happen when you pass a React component to an option that accepts a function returning a react element. For example, the [`headerTitle` option in native stack navigator](native-stack-navigator.md#headerTitle) expects a function returning a react element: +This can happen when you pass a React component to an option that accepts a function returning a react element. For example, the [`headerTitle` option in native stack navigator](native-stack-navigator.md#headertitle) expects a function returning a react element: ```js