Fix docs for headerTransparent

Author: satya164

versioned_docs/version-6.x/native-stack-navigator.md

@@ -144,13 +144,23 @@ Style object for header. Supported properties:
 
 Whether to hide the elevation shadow (Android) or the bottom border (iOS) on the header.
 
-#### `headerTranslucent`
+#### `headerTransparent`
 
-Boolean indicating whether the navigation bar is translucent. Setting this to `true` makes the header absolutely positioned, and changes the background color to `transparent` unless specified in `headerStyle`.
+Boolean indicating whether the navigation bar is translucent.
+
+Defaults to `false`. Setting this to `true` makes the header absolutely positioned - so that the header floats over the screen so that it overlaps the content underneath, and changes the background color to `transparent` unless specified in `headerStyle`.
+
+This is useful if you want to render a semi-transparent header or a blurred background.
+
+Note that if you don't want your content to appear under the header, you need to manually add a top margin to your content. React Navigation won't do it automatically.
+
+To get the height of the header, you can use [`HeaderHeightContext`](elements.md#headerheightcontext) with [React's Context API](https://reactjs.org/docs/context.html#contextconsumer) or [`useHeaderHeight`](elements.md#useheaderheight).
 
 #### `headerBlurEffect`
 
-Blur effect for the translucent header. Supported values:
+Blur effect for the translucent header. The `headerTransparent` option needs to be set to `true` for this to work.
+
+Supported values:
 
 - `extraLight`
 - `light`

versioned_docs/version-6.x/pitch.md

@@ -8,16 +8,16 @@ It's useful when considering whether or not to use a project to understand the t
 
 ## Pitch
 
-- React Navigation doesn't include any native code in the library itself, but we use many native libraries such as [Reanimated](https://software-mansion.github.io/react-native-reanimated/), [Gesture Handler](https://software-mansion.github.io/react-native-gesture-handler/), [Screens](https://github.com/software-mansion/react-native-screens) etc. to implement performant animations and gestures. Depending on the navigator, many UI components are written in JavaScript on top of React Native primitives. This has a lot of benefits:
+- React Navigation doesn't include any native code in the library itself, but we use many native libraries such as [Screens](https://github.com/software-mansion/react-native-screens), [Reanimated](https://software-mansion.github.io/react-native-reanimated/), [Gesture Handler](https://software-mansion.github.io/react-native-gesture-handler/) etc. to implement performant animations and gestures. Depending on the navigator, many UI components are written in JavaScript on top of React Native primitives. This has a lot of benefits:
   - Easy OTA updates
   - Debuggable
   - Customizable
-- Most apps heavily customize navigation, to do this with an API that wraps native navigation you will need to write a lot of native code. In React Navigation, we provide navigators written fully with JavaScript (e.g. [Stack Navigator](stack-navigator.md)) and navigators implemented on top of platform navigation primitives (e.g. [Native Stack Navigator](https://github.com/software-mansion/react-native-screens/tree/master/native-stack)). This lets you pick the navigators suitable for your use case, depending on whether you want native platform behavior or full customizability.
-- It's easy to write your own navigators that integrate cleanly with standard navigators, or to fork the standard navigators and create your own version of them with the exact look and feel you want in your app.
+- Most apps heavily customize navigation, to do this with an API that wraps native navigation you will need to write a lot of native code. In React Navigation, we provide navigators written fully with JavaScript (e.g. [Stack Navigator](stack-navigator.md)) and navigators implemented on top of platform navigation primitives (e.g. [Native Stack Navigator](native-stack-navigator.md)). This lets you pick the navigators suitable for your use case, depending on whether you want native platform behavior or full customizability.
+- It's possible to write your own navigators that integrate cleanly with standard navigators, or to fork the standard navigators and create your own version of them with the exact look and feel you want in your app.
 
 ## Anti-pitch
 
 - Improvements may require breaking changes. We are working to make ["easy things easy and hard things possible"](https://www.quora.com/What-is-the-origin-of-the-phrase-make-the-easy-things-easy-and-the-hard-things-possible) and this may require us to change the API at times.
-- Many navigators don't directly use the native navigation APIs on iOS and Android; rather, they use the lowest level pieces and then re-creates some subset of the APIs on top. This is a conscious choice in order to make it possible for users to customize any part of the navigation experience (because it's implemented in JavaScript) and to be able to debug issues that they encounter without needing to learn Objective C / Swift / Java / Kotlin.
-  - If you need the exact platform behavior, you can choose to use the navigators that use native platform primitives (e.g. [Native Stack Navigator](https://github.com/software-mansion/react-native-screens/tree/master/native-stack)), or use another library that wraps the platform APIs. Read more about these in [Alternatives](alternatives.md) and be sure to understand the tradeoffs that they make before digging in!
+- Some navigators don't directly use the native navigation APIs on iOS and Android; rather, they use the lowest level pieces and then re-creates some subset of the APIs on top. This is a conscious choice in order to make it possible for users to customize any part of the navigation experience (because it's implemented in JavaScript) and to be able to debug issues that they encounter without needing to learn Objective C / Swift / Java / Kotlin.
+  - If you need the exact platform behavior, you can choose to use the navigators that use native platform primitives (e.g. [Native Stack Navigator](natives-stack-navigator.md)), or use another library that wraps the platform APIs. Read more about these in [Alternatives](alternatives.md) and be sure to understand the tradeoffs that they make before digging in!
 - There are other limitations which you may want to consider, see [Limitations](limitations.md) for more details.

versioned_docs/version-6.x/upgrading-from-5.x.md

@@ -195,6 +195,10 @@ See docs for [`NavigationContainer`](navigation-container.md#ref) and [Navigatin
 
 Earlier, `useNavigation`, `Link`, `useLinkProps` etc. could only be used inside screens. But now it's possible to use them in any component that's a child of [`NavigationContainer`](navigation-container.md).
 
+### Stricter types for TypeScript
+
+The type definitions are not stricter, which makes it easier to catch errors earlier by minimizing unsafe types. For example, `useNavigation` now throws an error if you don't specify a type. You can handle this by annotating it, or for an easier way, specify a type for root navigator which will be used for all usage of `useNavigation`.
+
 ### Ability to specify a type for root navigator when using TypeScript
 
 Previously, we needed to specify a type for things such as `useNavigation`, `Link` etc. in every place we use them. But it's now possible to specify the type of the root navigator in one place that'll be used everywhere by default:
@@ -327,6 +331,7 @@ npm install @react-navigation/native-stack
 - `headerHideBackButton` is changed to `headerBackVisible`
 - `headerHideShadow` is changed to `headerShadowVisible`
 - `headerLargeTitleHideShadow` is changed to `headerLargeTitleShadowVisible`
+- `headerTranslucent` is changed to `headerTransparent`
 - `headerBlurEffect` is now a separate option and no longer a property in `headerStyle`
 - `headerTopInsetEnabled` option is removed, it's now automatically set when necessary
 - `replaceAnimation` is renamed to `animationTypeForReplace`