Merge static configuration section with rest

Author: satya164

versioned_docs/version-7.x/static-combine-with-dynamic.md renamed to versioned_docs/version-7.x/combine-static-with-dynamic.md

@@ -1,7 +1,7 @@
 ---
-id: static-combine-with-dynamic
+id: combine-static-with-dynamic
 title: Combining static and dynamic APIs
-sidebar_label: Combining with dynamic API
+sidebar_label: Combining static and dynamic APIs
 ---
 
 While the static API has many advantages, it doesn't fit use cases where the navigation configuration needs to be dynamic. So React Navigation supports interop between the static and dynamic APIs.

versioned_docs/version-7.x/nesting-navigators.md

@@ -1039,7 +1039,7 @@ We recommend to reduce nesting navigators to minimal. Try to achieve the behavio
 - Nesting same type of navigators (e.g. tabs inside tabs, drawer inside drawer etc.) might lead to a confusing UX
 - With excessive nesting, code becomes difficult to follow when navigating to nested screens, configuring deep link etc.
 
-Think of nesting navigators as a way to achieve the UI you want rather than a way to organize your code. If you want to create separate group of screens for organization, instead of using separate navigators, you can use the [`Group`](group.md) component for dynamic configuration or [`groups` property](static-api-reference.md#groups) for static configuration.
+Think of nesting navigators as a way to achieve the UI you want rather than a way to organize your code. If you want to create separate group of screens for organization, instead of using separate navigators, you can use the [`Group`](group.md) component for dynamic configuration or [`groups` property](static-configuration.md#groups) for static configuration.
 
 <Tabs groupId="config" queryString="config">
 <TabItem value="static" label="Static" default>

versioned_docs/version-7.x/static-authentication.md

@@ -26,7 +26,7 @@ This is the behavior that we want from the authentication flow: when users sign
 We can configure different screens to be available based on some condition. For example, if the user is signed in, we can define `Home`, `Profile`, `Settings` etc. If the user is not signed in, we can define `SignIn` and `SignUp` screens. To do this, we need a couple of things:
 
 1. Define two hooks: `useIsSignedIn` and `useIsSignedOut`, which return a boolean value indicating whether the user is signed in or not.
-2. Use the `useIsSignedIn` and `useIsSignedOut` along with the [`if`](static-api-reference.md#if) property to define the screens that are available based on the condition.
+2. Use the `useIsSignedIn` and `useIsSignedOut` along with the [`if`](static-configuration.md#if) property to define the screens that are available based on the condition.
 
 This tells React Navigation to show specific screens based on the signed in status. When the signed in status changes, React Navigation will automatically show the appropriate screen.
 
@@ -113,7 +113,7 @@ In the above snippet, `isLoading` means that we're still checking if we have a t
 
 Next, we're exposing the sign in status via the `SignInContext` so that it's available to the `useIsSignedIn` and `useIsSignedOut` hooks.
 
-In the above example, we're have 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 [`groups`](static-api-reference.md#groups) to define multiple screens:
+In the above example, we're have 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 [`groups`](static-configuration.md#groups) to define multiple screens:
 
 ```js
 const RootStack = createNativeStackNavigator({

versioned_docs/version-7.x/static-api-reference.md renamed to versioned_docs/version-7.x/static-configuration.md

@@ -1,7 +1,7 @@
 ---
-id: static-api-reference
-title: Static API Reference
-sidebar_label: API Reference
+id: static-configuration
+title: Static configuration
+sidebar_label: Static configuration
 ---
 
 The bulk of the static configuration is done using the `createXNavigator` functions, e.g. [`createNativeStackNavigator`](native-stack-navigator.md), [`createBottomTabNavigator`](bottom-tab-navigator.md), [`createDrawerNavigator`](drawer-navigator.md) etc. We'll refer to these functions as `createXNavigator` in the rest of this guide.
@@ -167,7 +167,7 @@ const RootStack = createNativeStackNavigator({
 
 The `linking` object supports the same configuration options described in [Configuring links](configuring-links.md) such as `parse`, `stringify` and `exact`.
 
-To make deep links work on native apps, you also need to [configure your app](deep-linking.md) and pass `prefixes` to the navigation component returned by [`createStaticNavigation`](static-api-reference.md#createstaticnavigation):
+To make deep links work on native apps, you also need to [configure your app](deep-linking.md) and pass `prefixes` to the navigation component returned by [`createStaticNavigation`](static-configuration.md#createstaticnavigation):
 
 ```js
 const Navigation = createStaticNavigation(RootStack);
@@ -322,7 +322,7 @@ const RootStackNavigator = createComponentForStaticNavigation(RootStack, 'RootNa
 
 The returned component doesn't take any props. All of the configuration is inferred from the static config. It's essentially the same as defining a component using the dynamic API.
 
-This looks similar to `createStaticNavigation` however they are very different. When using static configuration, you'd never use this function directly. The only time you'd use this is if you're migrating away from static configuration and want to reuse existing code you wrote instead of rewriting it to the dynamic API. See [Combining static and dynamic APIs](static-combine-with-dynamic.md) for more details.
+This looks similar to `createStaticNavigation` however they are very different. When using static configuration, you'd never use this function directly. The only time you'd use this is if you're migrating away from static configuration and want to reuse existing code you wrote instead of rewriting it to the dynamic API. See [Combining static and dynamic APIs](combine-static-with-dynamic.md) for more details.
 
 ## `createPathConfigForStaticNavigation`
 
@@ -338,4 +338,4 @@ const config = {
 };
 ```
 
-Similar to `createComponentForStaticNavigation`, this is intended to be used when migrating away from static configuration. See [Combining static and dynamic APIs](static-combine-with-dynamic.md) for more details.
+Similar to `createComponentForStaticNavigation`, this is intended to be used when migrating away from static configuration. See [Combining static and dynamic APIs](combine-static-with-dynamic.md) for more details.

versioned_sidebars/version-7.x-sidebars.json

@@ -33,18 +33,14 @@
       "screen-tracking",
       "themes",
       "state-persistence",
+      "combine-static-with-dynamic",
       "testing",
       "typescript",
       "redux-integration",
       "MST-integration",
       "troubleshooting",
       "upgrading-from-6.x"
     ],
-    "Static configuration": [
-      "static-api-reference",
-      "static-authentication",
-      "static-combine-with-dynamic"
-    ],
     "Navigators": [
       "stack-navigator",
       "native-stack-navigator",
@@ -59,6 +55,7 @@
       "drawer-layout"
     ],
     "API reference": [
+      "static-configuration",
       "navigation-container",
       "server-container",
       "group",