SafeAreaView doesn't respect padding property in style

[dani-mp]

Environment

React Native Environment Info:
    System:
      OS: macOS 10.14
      CPU: x64 Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz
      Memory: 34.00 MB / 8.00 GB
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 9.7.1 - ~/.nvm/versions/node/v9.7.1/bin/node
      Yarn: 1.2.1 - /usr/local/bin/yarn
      npm: 6.4.1 - ~/.nvm/versions/node/v9.7.1/bin/npm
      Watchman: 4.7.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.0, macOS 10.14, tvOS 12.0, watchOS 5.0
      Android SDK:
        Build Tools: 21.1.2, 22.0.1, 23.0.1, 23.0.3, 25.0.0, 25.0.2, 26.0.1, 26.0.2, 27.0.1, 27.0.3, 28.0.2, 28.0.3
        API Levels: 17, 18, 19, 22, 23, 25, 26, 27, 28
    IDEs:
      Android Studio: 3.2 AI-181.5540.7.32.5056338
      Xcode: 10.0/10A254a - /usr/bin/xcodebuild
    npmPackages:
      react: 16.6.0 => 16.6.0
      react-native: ^0.57.3 => 0.57.3
    npmGlobalPackages:
      react-native-cli: 2.0.1

Description

Applying padding to SafeAreaView's style doesn't work.

Reproducible Demo

https://snack.expo.io/@danielmartin/c2FmZW

[bartolkaruza]

renders nested content and automatically applies paddings

Seems like intended behaviour from the docs. Try adding padding to your view inside the SafeAreaView instead.

[dani-mp]

Thanks for the response, @bartolkaruza. I was wondering if it would be better if the padding applied by the consumer was added to the safe area one, instead of being overwritten. Thinking about it, the way the SafeAreaView component achieves its behaviour is more an implementation detail.

[bartolkaruza]

If the padding is added to the already in place padding that the SafeAreaView adds automatically, the next opened issue will be from someone asking why the padding value is not exactly the number of pixels specified by the style. Maybe someone would expect to be able to override the padding by using the padding style for some cases, which wouldn't work... Are the complexity and additional discussion worth it when the solution is putting in a containing view on which you can apply all the styles you want?

Perhaps a note in the docs specifying more clearly that the padding style property is ignored would save the next person some time? Maybe a warning message could take it even a step further. Feel free to open a PR for that if you have the time.

[dani-mp]

I wanted to share my thoughts regarding this because I found the current approach not ideal. I discussed this internally before creating the issue and people agreed with me that this was confusing.

If someone uses SafeAreaView I expect them to know that it will define new bounds and that all style properties applied to it would work in base to those new bounds (otherwise they would have used a View in the first place). The fact that internally SafeAreaView uses padding to accomplish this it's just, IMO, an implementation detail that shouldn't concern the consumer.

I thought the additional discussion was worth it and that's why I brought it up.

Adding a containing view is what we're doing now and it feels unnecessary, given that SafeAreaView already takes a View's style property. I also thought about the warning message, there are components out there that filter out forbidden properties and warn about their usage in dev mode, this could rise awareness about this particularity, but it wouldn't solve the underlying issue.

To add another argument, in native iOS you can create a constraint relative to the safeAreaLayoutGuide without having to create a containing view to do it.

I would love to find time to help improving this somehow, I just wanted to know what people think about it first!

[esr360]

Sorry but I'm a bit confused about this issue.

I have applied padding to a SafeAreaView component. In Android it is applied, in iOS it isn't. What is the reason, and what is the solution?

Thanks.

[dani-mp]

@esr360 Until this issue is solved, you need to add another view inside the SafeAreaView and apply your padding there, because SafeAreaView uses the padding style prop to implement its behaviour, overriding the one you pass to it.

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

[dani-mp]

:(

[JLWalsh]

Since this causes inconsistent behaviour between iOS and Android, I don't think that adding a simple message in the doc is enough, as it will falsely indicate that this behaviour is the same on Android & iOS. Whether the user provided paddings are applied or not, I think that the behaviour atleast needs to be consistent across all OSes.

[aldebout]

Wouldn't a contentContainerStyle prop be appropriate, to be consistent with KeyboardAvoidingView?

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

[esr360]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

Not been fixed, please don't close issues that are not fixed, I hate this bot. It makes things go away for project maintainers but does not help users.

[ianmartorell]

Definitely not been fixed.

[huangkaiw3n]

confusing behavior. could be improved as suggested

[gavin-gyle]

It took me a while yesterday to figure out why my padding wasn't working. Looked at the docs and saw SafeAreaView inherits View properties so I got even more confused. I would think add the padding to the calculated padding as suggested, or don't allow SafeAreaView to take in a style to remove the confusion.

[sekizlipenguen]

+1

[Teddir]

is it true that using SafeAreaView in android with Flatlist as its child will cause onEndReached prop to not fire? I am currently having this problem.

[christopher-caldwell]

Don't make it stale, bot! Still a problem.

[Aaqib925]

is it true that using SafeAreaView in android with Flatlist as its child will cause onEndReached prop to not fire? I am currently having this problem.

It doesn't cause any issue. Make sure your flatlist parent component is not scrollview, if not try using onEndReachedThreshold prop to value 0 in iOS or 0.5 in Android. This shall work.

[andrelfnavarro]

It at least should be similar to KeyboardAvoidingView, with a contentContainerStyle prop. So weird needing to add another view just for padding

[palcisto]

So what is the status of this issue amongst the authoring team? It appears to have gained almost no traction or attention from the team other than adding a note to the documentation since this issue was first created 3.5 years ago at this point.

[lautaroml]

Any solution?

[a-eid]

use https://github.com/th3rdwave/react-native-safe-area-context, it has a hook api and you can change the mode from padding to margin.

[Pat-Gekoski]

@esr360 Until this issue is solved, you need to add another view inside the SafeAreaView and apply your padding there, because SafeAreaView uses the padding style prop to implement its behaviour, overriding the one you pass to it.

this makes sense. @esr360 .....does it work with Android phones that have a notch too?

[abdulbari149]

Maybe this issue should be closed. Because the padding problem is resolved by react-native-safe-area-context. Just a suggestion

[magom001]

I personally would like to have an option to override the padding. E.g.: I want the default vertical padding but I want to disable the horizontal padding. The SafeAreaView from https://github.com/th3rdwave/react-native-safe-area-context has edges property that allows to achieve exactly that.

[phthhieu]

And if padding doesn't work, the style prop of SafeAreaView shouldn't accept the padding attribute, it would be more obvious and not take so much time on the investigation or go back and forth to find out this thread or the related documentation.

react-native/Libraries/Components/SafeAreaView/SafeAreaView.d.ts

Line 21 in 5d26cea

declare class SafeAreaViewComponent extends React.Component<ViewProps> {}

Should be sth like:

declare class SafeAreaViewComponent extends React.Component<Omit<ViewProps, 'style'> {
   style: AStyleWithoutPaddingAttributes
}

[ankitpunchh]

Dont know about the perfect solution but once i have added another view on top of SafeAreaView and gave the style to that View. Problem gets solved but yeah its weird as it adds one extra node.

[07kushalsaini]

I have use margin instead on padding in SafeAreaView.
and it;s working for me.

[07kushalsaini]

Still doesn't work. easily fixable with view inside. Slight confusion though. a note in the docs could help.

use margin it will work in SafeAreaView

[teja2495]

@07kushalsaini margin will affect the background color unless you wrap it in another view which is not ideal.

[NorseGaud]

Just stumbled across this issue myself what a strange waste of my time trying to figure out what I was doing wrong, only to be surprised.

[brunaporato]

sad to bump into this unfixed problem :(

[Mahmoudz11]

6 years until now

[andshonia]

My approach maybe will help you:

• Create simple custom container

 <View style={{  paddingTop: Platform.OS === "android"
      ? Constants?.statusBarHeight + 10
      : Constants?.statusBarHeight,}}>
 ...you code 
 </View>

[DDunc]

Based on how popular silently ignoring and overriding a style attribute has been with the react-native core team & community for the last six years, I think it would be worth rolling out this feature to more components.

Many components could benefit from the functionality and expressiveness SafeAreaView gives developers who would like to be able to safely store integer values inside of style attributes without the unwanted side-effect of applying layout changes on some platforms.

[tilltu-brian]

I'm confused about what the expected behavior is for padding in a SafeAreaView. I landed here because I have 5 pages, each set up exactly the same with a SafeAreaView wrapping some Text and a ScrollView. Each page has the exact same layout and exact same styles (imported from a shared file). Four of the pages respect the padding, one does not, and I cannot figure out why.

I was able to get padding on that page by adding an extra View and putting the padding on it, but everything else gets messed up because the shared styles weren't designed for that extra layer of nesting. After reading the comments in this thread I'm thinking I'll need to redo all of the pages to have that extra View within the SafeAreaView, which seems silly.

[shivang98]

This works for me!

Add a View inside SafeAreaView and provide styling separately, as shown below.

import { Platform, SafeAreaView, StyleSheet, View } from "react-native";
import { NavigationContainer } from "@react-navigation/native";
import HomeNavigator from "./App/Navigations/HomeNavigator";

export default function App() {
  return (
    <SafeAreaView style={styles.safeContainer}>
      <View style={styles.container}>
        <NavigationContainer>
          <HomeNavigator />
        </NavigationContainer>
      </View>
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  safeContainer: {
    flex: 1,
    backgroundColor: "#fff",
  },
  container: {
    flex: 1,
    backgroundColor: "#fff",
    paddingTop: Platform.OS == "android" ? 20 : 0,
    paddingRight: 20,
    paddingLeft: 20,
  },
});

[Kipperlenny]

as a beginner with react native, I had the same problem.... Thank you @shivang98

[aldebout]

It's been 4.5 years since we merged the PR that added the link to this issue to the official docs (facebook/react-native-website#1847).

I wanted to celebrate almost 5 years of getting notifications about this with my current solution to the problem: don't use SafeAreaView.

Unless you have a very simple app with basic routing (a hello world demo), you should go for flexibility and use useSafeAreaInsets from https://github.com/th3rdwave/react-native-safe-area-context (as mentioned by @a-eid and @magom001). It should help you avoid weird components wrapping when using tabs or drawers, background color issues and animation shenanigans.