Address code review comments

Author: satya164

sidebars.js

@@ -127,13 +127,13 @@ There are 2 primary ways to configure the navigators:
 
 ### Static configuration
 
-The static configuration API has reduced boilerplate and simplifies things such as TypeScript types and deep linking. If you're starting a new project or are new to React Navigation, this is the **recommended way** to set up your app.
+The static configuration API has reduced boilerplate and simplifies things such as TypeScript types and deep linking. If you're starting a new project or are new to React Navigation, this is the **recommended way** to set up your app. If you need more flexibility in the future, you can always mix and match with the dynamic configuration.
 
 Continue to ["Hello React Navigation"](hello-react-navigation.md?config=static) to start writing some code with the static API.
 
 ### Dynamic configuration
 
-The dynamic configuration allows for more flexibility but requires more boilerplate and configuration.
+The dynamic configuration allows for more flexibility but requires more boilerplate and configuration (e.g. for deep links, typescript etc.).
 
 To get started with dynamic configuration, first, we need to wrap your app in `NavigationContainer`. Usually, you'd do this in your entry file, such as `index.js` or `App.js`:
 

versioned_docs/version-7.x/getting-started.md

@@ -66,7 +66,7 @@ This object can be accessed with the [`useNavigation`](use-navigation.md) hook.
 
 For more details, see the ["Navigation object docs"](navigation-object.md).
 
-The ["Route object reference"](route-object.md) section goes into more detail on this, describes workarounds, and provides more information on other properties available on `route` prop.
+The ["Route object reference"](route-object.md) section goes into more detail on this, describes workarounds, and provides more information on other properties available on `route` object.
 
 ## Route object
 

versioned_docs/version-7.x/glossary-of-terms.md

@@ -107,7 +107,7 @@ The argument that is passed in to the `options` function is an object with the f
 - `navigation` - The [navigation object](navigation-object.md) for the screen.
 - `route` - The [route object](route-object.md) for the screen
 
-We only needed the `route` prop in the above example but you may in some cases want to use `navigation` as well.
+We only needed the `route` object in the above example but you may in some cases want to use `navigation` as well.
 
 ## Updating `options` with `setOptions`
 
@@ -193,7 +193,7 @@ There are a couple of things to notice here:
 
 ## Sharing common `options` across screens
 
-It is common to want to configure the header in a similar way across many screens. For example, your company brand color might be red and so you want the header background color to be red and tint color to be white. Conveniently, these are the colors we're using in our running example, and you'll notice that when you navigate to the `DetailsScreen` the colors go back to the defaults. Wouldn't it be awful if we had to copy the `options` header style properties from `Home` to `Details`, and for every single screen we use in our app? Thankfully, we do not. We can instead move the configuration up to the native stack navigator under `screenOptions`:
+It is common to want to configure the header in a similar way across many screens. For example, your company brand color might be red and so you want the header background color to be red and the tint color to be white. Conveniently, these are the colors we're using in our running example, and you'll notice that when you navigate to the `DetailsScreen` the colors go back to the defaults. Wouldn't it be awful if we had to copy the `options` header style properties from `Home` to `Details`, and for every single screen we use in our app? Thankfully, we do not. We can instead move the configuration up to the native stack navigator under `screenOptions`:
 
 <Tabs groupId="config" queryString="config">
 <TabItem value="static" label="Static" default>

versioned_docs/version-7.x/headers.md

@@ -93,7 +93,7 @@ class Profile extends React.Component {
 }
 ```
 
-One thing to keep in mind is that you can only listen to events from the immediate navigator with `addListener`. For example, if you try to add a listener in a screen that's inside a stack that's nested in a tab, it won't get the `tabPress` event. If you need to listen to an event from a parent navigator, you may use [`navigation.getParent`](navigation-object.md#getparent) to get a reference to parent screen's navigation object and add a listener.
+One thing to keep in mind is that you can only listen to events from the immediate navigator with `addListener`. For example, if you try to add a listener in a screen that's inside a stack that's nested in a tab, it won't get the `tabPress` event. If you need to listen to an event from a parent navigator, you may use [`navigation.getParent`](navigation-object.md#getparent) to get a reference to the parent screen's navigation object and add a listener.
 
 ```js
 const unsubscribe = navigation

versioned_docs/version-7.x/navigation-events.md

@@ -108,7 +108,7 @@ If you want to achieve this behavior, see the guide for [screen options with nes
 
 ### Each screen in a navigator has its own params
 
-For example, any `params` passed to a screen in a nested navigator are in the `route` prop of that screen and aren't accessible from a screen in a parent or child navigator.
+For example, any `params` passed to a screen in a nested navigator are in the `route` object of that screen and aren't accessible from a screen in a parent or child navigator.
 
 If you need to access params of the parent screen from a child screen, you can use [React Context](https://reactjs.org/docs/context.html) to expose params to children.
 

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

@@ -4,7 +4,7 @@ title: Route object reference
 sidebar_label: Route object
 ---
 
-Each `screen` component in your app is provided with the `route` prop automatically. The prop contains various information regarding current route (place in navigation hierarchy component lives).
+Each `screen` component in your app is provided with the `route` object as a prop automatically. The prop contains various information regarding current route (place in navigation hierarchy component lives).
 
 - `route`
   - `key` - Unique key of the screen. Created automatically or added while navigating to this screen.

versioned_docs/version-7.x/route-object.md

@@ -31,7 +31,7 @@ You can pass a prop named `options` to the `Screen` component to configure a scr
 </Stack.Navigator>
 ```
 
-You can also pass a function to `options`. The function will receive the [`navigation` object](navigation-object.md) and the [`route` prop](route-object.md) for that screen. This can be useful if you want to perform navigation in your options:
+You can also pass a function to `options`. The function will receive the [`navigation` object](navigation-object.md) and the [`route` object](route-object.md) for that screen. This can be useful if you want to perform navigation in your options:
 
 ```js
 <Stack.Screen

versioned_docs/version-7.x/screen-options.md

@@ -60,7 +60,7 @@ The type containing the mappings must be a type alias (e.g. `type RootStackParam
 
 ### Type checking screens
 
-To type check our screens, we need to annotate the `navigation` prop and the `route` prop received by a screen. The navigator packages in React Navigation export a generic types to define types for both the `navigation` and `route` props from the corresponding navigator.
+To type check our screens, we need to annotate the `navigation` and the `route` props received by a screen. The navigator packages in React Navigation export generic types to define types for both the `navigation` and `route` props from the corresponding navigator.
 
 For example, you can use `NativeStackScreenProps` for the Native Stack Navigator.
 
@@ -120,7 +120,7 @@ type ProfileScreenNavigationProp = Props['navigation'];
 type ProfileScreenRouteProp = Props['route'];
 ```
 
-Alternatively, you can also annotate the `navigation` and `route` props separately.
+Alternatively, you can also annotate the `navigation` and `route` objects separately.
 
 To get the type for the `navigation` prop, we need to import the corresponding type from the navigator. For example, `NativeStackNavigationProp` for `@react-navigation/native-stack`:
 
@@ -135,7 +135,7 @@ type ProfileScreenNavigationProp = NativeStackNavigationProp<
 
 Similarly, you can import `StackNavigationProp` from `@react-navigation/stack`, `DrawerNavigationProp` from `@react-navigation/drawer`, `BottomTabNavigationProp` from `@react-navigation/bottom-tabs` etc.
 
-To get the type for the `route` prop, we need to use the `RouteProp` type from `@react-navigation/native`:
+To get the type for the `route` object, we need to use the `RouteProp` type from `@react-navigation/native`:
 
 ```tsx
 import type { RouteProp } from '@react-navigation/native';
@@ -231,11 +231,11 @@ const navigation = useNavigation<ProfileScreenNavigationProp>();
 :::danger
 
 Annotating `useRoute` isn't type-safe because the type parameter cannot be statically verified.
-Prefer using the [`route` prop](route-object.md) instead when possible. Use `useRoute` for generic code that doesn't need specific route type.
+Prefer using the [`route` object](route-object.md) from the screen component's props instead when possible. Use `useRoute` for generic code that doesn't need specific route type.
 
 :::
 
-To annotate the `route` prop that we get from `useRoute`, we can use a type parameter:
+To annotate the `route` object that we get from `useRoute`, we can use a type parameter:
 
 ```ts
 const route = useRoute<ProfileScreenRouteProp>();
@@ -257,7 +257,7 @@ const options: StackNavigationOptions = {
 
 Similarly, you can import `DrawerNavigationOptions` from `@react-navigation/drawer`, `BottomTabNavigationOptions` from `@react-navigation/bottom-tabs` etc.
 
-When using the function form of `options` and `screenOptions`, you can annotate the arguments with the same type you used to annotate the `navigation` and `route` props.
+When using the function form of `options` and `screenOptions`, you can annotate the arguments with the same type you used to annotate the `navigation` and `route` objects from the [Type checking screens](#type-checking-screens) section.
 
 ### Annotating `ref` on `NavigationContainer`
 

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

@@ -4,9 +4,9 @@ title: useRoute
 sidebar_label: useRoute
 ---
 
-`useRoute` is a hook which gives access to `route` object. It's useful when you cannot pass the `route` prop into the component directly, or don't want to pass it in case of a deeply nested child.
+`useRoute` is a hook which gives access to `route` object. It's useful when you cannot pass down the `route` object from props to the component, or don't want to pass it in case of a deeply nested child.
 
-`useRoute()` returns the `route` prop of the screen it's inside.
+`useRoute()` returns the `route` object of the screen it's inside.
 
 ## Example
 
@@ -24,7 +24,7 @@ function MyText() {
 }
 ```
 
-See the documentation for the [`route` prop](route-object.md) for more info.
+See the documentation for the [`route` object](route-object.md) for more info.
 
 ## Using with class component
 

versioned_docs/version-7.x/typescript.md

@@ -41,7 +41,6 @@
       "upgrading-from-6.x"
     ],
     "Static configuration": [
-      "static-configuration",
       "static-api-reference",
       "static-typescript",
       "static-authentication",