Custom header component

[piotrfalba]

Description

It would be nice to be able to use a custom header component.

Motivation

Then you could easily add a search field, avatars, buttons etc.

[WoLewicki]

One of the native-stack's main goals is to leverage the usage of native components for header. You can always specify headerShown: false and add your own component as a header. Can I help you any more with this?

[juice49]

We are doing exactly this for our project. The biggest problem we've encountered is that we don't seem to be able to access the screen title option inside our custom header component.

I can see the screen options are exposed to the navigator, but I can't find a way to access them inside of screens.

Does anybody know if this is possible without creating our own custom navigator?

[WoLewicki]

We don't expose the header option in native-stack, so the solution seems to be not to use the options. You can also create a PR with header component or add a patch to your project with the descriptor.options.title exposed.

[juice49]

Thank you for replying so quickly @WoLewicki! 🙂

That makes sense. I wanted to check I wasn't missing a way to do this.

For now, we have worked around the issue by passing the screen options down to our custom header component. The one downside is that programmatic changes to the title (e.g. via setOptions) are not reflected.

I will definitely think about whether this can be nicely handled in a PR.

Thanks again for the help.

[WoLewicki]

I will move this to Discussions since it is rather a feature request.

[charles-goode]

I'm probably in a fairly unique situation. I've put a lot of time into a highly proprietary header component that I've gotten working pretty well with the standard stack navigator from react-navigation 3.x (using Expo also). Ideally I'd be able to switch over to native-screens for performance sake alone. It would be really nice if the same header navOption from createStackNavigator was exposed on createNativeStackNavigator. I understand I wouldn't be able to use it until Expo picked it up too, but this is large project, and I don't expect to be able to upgrade to 5.x by then (also headerShown wouldn't work in my use-case anyway).

[charles-goode]

Also just to get this right, doing enableScreens without using a native stack navigator doesn't do anything? I'm really just hoping to get the performance upgrades.

[charles-goode]

I think I have a small hack. In my project I have a fancy header that accompanies a tab navigator (it changes in place as tabs are swiped). This tab navigator is within the initial route in the main stack navigator that the rest of the screens are on ( the tab bar disappears on those screens). So I wanted to make this main stack native, but it wasn't working for my custom header component on that first route. So I wrapped the first route ( the tab navigator) in a plain stack navigator and put the header on the single route and then no header on the navigationOptions for that stack. So I'm won't be getting any depth improvements from the native navigator on the tabs screen, but I should be getting improvements elsewhere.

At least on my older iOS devices it appears that header: null works in navigationOptions for the screens within the native stack (which is undocumented or maybe is a bug?).

[WoLewicki]

Also just to get this right, doing enableScreens without using a native stack navigator doesn't do anything? I'm really just hoping to get the performance upgrades.

Having enableScreens(true) has effect on all of the navigators, it enables native detaching of inactive screens. You can read more about it e.g. here: #8

[WoLewicki]

About the header: null option, in the previous implementation of native-stack, you could provide it to hide the header: https://github.com/software-mansion/react-native-screens/blob/master/src/createNativeStackNavigator.js#L136