React-native-paper: Update react-native-safe-area-view dependency

[bareynol]

Environment

react-native > 0.60.5
react-native-paper 2.16.0

Description

react-native-safe-area-view is currently listed as version "^0.12.0". The implementation of the SafeView component in 0.12.0 uses componentWillReceiveProps, which on react-native 0.60+ displays a YellowBox warning of the following:

Warning: componentWillReceiveProps is deprecated and will be removed in the next major version. Use static getDerivedStateFromProps instead.

Please update the following components: SafeView

Learn more about this warning here

react-native-safe-area-view has released version 0.14, which no longer uses componentWillReceiveProps and thus avoids this Warning popping up.

However, more broadly, yesterday (September 26th), react-native-safe-area-view also just updated to version 1.0.0, which might also be worth updating the usage in this package

Reproducible Demo

Any usage of a component that uses safe-area-view should trigger this warning.

[douglaszaltron]

+1

[gdoudeng]

+1

[Trancever]

@echolocation Can you submit a PR?

[bareynol]

@Trancever I have been looking into doing just that, and I have some questions as to what exactly this dependency is being used for.

Quick notes for anyone looking:

React Native has provided a SafeAreaView component since version 0.50, however this component is only applicable to iOS 11+.
Link here: https://facebook.github.io/react-native/docs/0.60/safeareaview

react-native-community also implements a SafeAreaView component in react-native-community/react-native-safe-area-view. The docs for this are generally poor and do not state whether it is compatible with Android, or what versions of any OS it is compatible with.
Link here: https://github.com/react-native-community/react-native-safe-area-view

react-native-paper uses BOTH the react-native and react-native-community implementations of SafeAreaView

React Native SafeAreaView usage:

AppbarHeader: https://github.com/callstack/react-native-paper/blob/master/src/components/Appbar/AppbarHeader.tsx

Snackbar: https://github.com/callstack/react-native-paper/blob/master/src/components/Snackbar.tsx

FABGroup: https://github.com/callstack/react-native-paper/blob/master/src/components/FAB/FABGroup.tsx

react-native-community SafeAreaView usage:

Modal: https://github.com/callstack/react-native-paper/blob/master/src/components/Modal.tsx

BottomNavigation: https://github.com/callstack/react-native-paper/blob/master/src/components/BottomNavigation.tsx

---

Looking at Git blame, it looks like the react-native-community implementation was first brought in 8 months ago for BottomNavigation by @satya164, presumably to take advantage of the forceInset prop.
See: https://github.com/callstack/react-native-paper/commit/a07962638be6e5629de84385cd3520583f9e19fe

So before submitting a PR to update this dependency I have a couple questions, and maybe @sataya164 can weigh in here:

1. What benefits does the react-native-community implementation provide? (e.g. is there Android support? Does it handle the use cases better?)
2. If the react-native-community implementation does not provide Android support, what is the reason for requiring the forceInset prop in the BottomNavigation component? (I'm assuming this solves some jank)
3. If the react-native-community implementation is functionally better than the React Native implementation or required, should react-native-paper's usage of SafeAreaView be consistent and should AppbarHeader, Snackbar, and FABGroup be updated to use the react-native-community implementation?

[satya164]

The SafeAreaView from react-native is not very usable when you have screens that animate. For example, if you have a stack navigator which animates screen vertically, the safe area values will keep changing and the insets of stack navigator will keep changing as a result. For components which have onLayout, it will also trigger too many updates and sometimes infinite loops.

We pass forceInset by default to avoid delay in calculating the insets due to async onLayout.

That's the reason for using the community version. Yes, we should update other components to use the community versions as well.

[wesleyschneider]

+1

[github-actions[bot]]

Hello 👋, this issue has been open for more than 2 months with no activity on it. If the issue is still present in the latest version, please leave a comment within 7 days to keep it open, otherwise it will be closed automatically. If you found a solution on workaround for the issue, please comment here for others to find. If this issue is critical for you, please consider sending a pull request to fix the issue.