Each screen should be able to set properties on the device’s status bar, and the container defined in createNavigationContainer
should get the options on state change, and apply them natively.
9 thoughts on “StatusBar should be a configurable screen option”
Comments are closed.
I am planning to work on this during the weekend. If anyone else is willing to work on it earlier, please do! Otherwise, I am happy to send a pull request to it.
Additionally we probably need
StatusBar.addListener('translucent', () => {})
, then we can adjust padding of header automatically.Here’s an example: Sometimes something pushed into a stack will require the header to be hidden, and it may want to re-style the status bar. For example if you push a photo viewer screen, you want the status bar to turn to
light-content
when looking at the photo, or maybe hide the status bar.So your photo viewer would have the option:
Regardless of the current APIs in React Native, I still think this sort of component is a bad idea. I’m not saying we should introduce any contradictory docs or anything, but I’d rather use the imperative API from within the library.
As one example of where this component usage falls down: say I have a tab navigator and I want one tab to have a dark header and
light-content
status bar. When switching tabs, the status bar should change, but once they are both already mounted, the<StatusBar/>
component doesn’t cause the style to change. This is why I think we should usenavigationOptions
to define the status baragree with this. I like the idea of unifying more navigation concerns into the react-navigation configuration options.
I find it easier to think about navigation configuration as a separate layer from component implementations. For instance, I am using separate folders for navigators vs screen components.
I’m not too thrilled with the idea that I may have to add StatusBar setting into each of my screen components. would rather define that in my navigators configuration.
i’ve found the
onNavigationStateChange
#453 in 1.0.0-beta.6 serves my use case.example use case (modified code from https://reactnavigation.org/docs/guides/screen-tracking):
however, in this solution i must maintain a separate mapping (routeName to StatusBar setting). i’m thinking if StatusBar config was a screen navigationOption instead, then I would not have to maintain this extra mapping.
I’ve been doing some practical work on an app with a variable header color and a translucent StatusBar, and I’ve discovered another reason for StatusBar to be a navigationOption which simply using a translucent status bar doesn’t cover.
barStyle
and translucentbackgroundColor
When you use a translucent status bar and your header color shows behind the status bar you need to use the right shades for the status bar. If your header uses a nice dark solid color like a blue/navy/indigo you a translucent black and set
barStyle='light-content'
to ensure you get white icons on top of it. But when your header color is light light a white or has low saturation (like a pink or most material colors at their values <300) you use a translucent white and setbarStyle='dark-content'
to get black icons on top of it. Or in a few cases with a solid background color and no header you might set the status bar to purely transparent and apply the correctbarStyle
. The header color and correct shade can change from page to page,In
react-navigation
the color of the header is set usingnavigationOptions.headerStyle.backgroundColor
. So there needs to be some way to set thebarStyle
and translucent shade at the same time as the header color.So either this means at least partially implementing
statusBar
innavigationOptions
, or making the header responsible for theStatusBar
and telling everyone to use custom header components.(Reading back this might just be a better explained version of the issue @thurt had to work around)
TLDR; where we at with this?