Problem
- For some reason, when testing on my older Android phone (Android v 6.0.1), my Expo SDK 36 app's header always has extra padding, looking too bulky, even though the phone has no top notch.
- Testing on an iOS 13.4 simulator for the iPhone 11 with a notch, it handles the notch correctly.
Some Debug Results
- When I traverse the component hierarchy in
react-native-debugger, I see that:
- the
<SafeAreaView /> in my Screen component from react-native-safe-area-view has the correct inset values from context, { top: 0, bottom: 0, left: 0, right: 0 }
- However, the
<Header /> component from react-navigation 4.3.7 has safeAreaInsets: { top: 'never' }, when I examine its props.scene.descriptor.options to look at its navigationOptions
- And further, if I go into
<Header/>'s children, when I get to <SafeView/>, its props.forceInset.top is 'always'.
- I upgraded
react-navigation today to 4.3.7 from 3.13.0, I'm wondering if there's bugs from earlier versions of dependencies like react-native-safe-area-context and react-native-safe-area-view, or bugs with them in general.
- In
package-lock.json, I notice that there's an @react-navigation/native package with a dependency of react-native-safe-area-view at version 0.14.9 exact, while I notice in package.json, I have react-native-safe-area-view at semver range ^1.0.0. I think I installed it via the expo install command for packages compatible with your Expo SDK, when first looking into the SafeAreaView instructions in the Expo docs
- My render method looks like this:
render() {
return (
<SafeAreaConsumer>
{(insets) => {
console.log("render -> insets", insets)
return (
<SafeAreaView
style={{
flex: 1,
backgroundColor: Color.white,
paddingBottom: insets.bottom,
paddingLeft: insets.left,
paddingRight: insets.right,
}}
forceInset={insets}
>
<View style={MainAppViewContainers.container}>
...
</View>
</SafeAreaView>
)
}}
</SafeAreaConsumer>
);
}
Possible Explanations Coming To Mind
- Could
<SafeAreaView/> fail to automatically detect and set the right insets? Here it says, "By default, the device's safe area insets are automatically detected."
- Could using the
forceInset prop on <SafeAreaView/> fail to change the forceInset prop on <SafeView>, which is a child of the <Header/> component automatically generated by react-navigation once you set the correct header-related navigationOptions on screens/navigators?
- Could there be some kind of dependency clash between the version of
react-native-safe-area-view 0.14.9 used by @react-navigation/native 3.7.11 which react-navigation 4.3.7 installed, and react-native-safe-area-view 1.0.0 installed by Expo?
