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.