Skip to content

Use native-stack instead of stack by default #1004

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

Merged
merged 34 commits into from
Jul 1, 2021

Conversation

kacperkapusciak
Copy link
Member

@kacperkapusciak kacperkapusciak commented Jun 2, 2021

This PR treats native-stack (createNativeStackNavigator) as the default-choice stack navigator in React Navigation library.

@netlify
Copy link

netlify bot commented Jun 2, 2021

❌ Deploy Preview for react-navigation-docs failed.

🔨 Explore the source changes: 83bedbd

🔍 Inspect the deploy log: https://app.netlify.com/sites/react-navigation-docs/deploys/60d9cc1245e6af000768663c

{() => (
<Tab.Navigator
initialRouteName="Analitics"
tabBar={() => null}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why hide the tab bar? There'd be no way to switch between tabs

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is like that since v5.
This particular example shows how to deal with safe areas and that's why tabs are hidden. I've also hidden the header to match what the example was trying to show.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kacperkapusciak oki, I think we need to revisit that page, currently, I see 2 issues:

  • it seems pointless to use a tab navigator if you're going to hide the tab bar
  • the title mentions "custom header", but you don't need to add a safe area to your screen because you use a custom header
  • this example is not typical, there are often screens with header and no tab bar (not hidden)

what it should document is

  • general guide to using safe area on any screen that touches any screen edges - even if it has both header and tab bar, it's still necessary to handle horizontal insets (can be merged with landscape mode)
  • mention that you need top safe area when not using a header/hiding header/transparent header
  • mention that you need bottom safe area when not using a tab bar/transparent tab bar
  • we should document an example for ScrollViews and FlatList because they are common to be in screens

I'll create a task on notion for that

@@ -114,7 +114,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 `HomeScreen` to `DetailsScreen`, and for every single screen component we use in our app? Thankfully, we do not. We can instead move the configuration up to the stack navigator under the prop `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 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 `HomeScreen` to `DetailsScreen`, and for every single screen component we use in our app? Thankfully, we do not. We can instead move the configuration up to the native stack navigator under the prop `screenOptions`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this PR, but we might wanna change this document to not talk about brand color, since it's better addressed by using a custom theme than duplicating in screenOptions.

Maybe some other option would make sense here, like a custom back button.

@kacperkapusciak kacperkapusciak marked this pull request as ready for review June 15, 2021 10:49
@kacperkapusciak kacperkapusciak requested a review from satya164 June 15, 2021 10:50
Copy link
Member

@satya164 satya164 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I have only one change request and then we can merge

@kacperkapusciak kacperkapusciak requested a review from satya164 June 30, 2021 12:59
@satya164 satya164 merged commit f90842f into main Jul 1, 2021
@satya164 satya164 deleted the @kacperkapusciak/use-native-stack-instead-of-stack branch July 1, 2021 01:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants