Improvement suggestion - First render should always include safe area insets

[iway1]

I've had a lot of problems using this library in situations where there are components using the safe area view or components rendering at the same time as safe area view have to rerender quickly. Not sure if this has to do with the fact I'm using react-navigation.

The SafeAreaView just does not apply insets on the initial render sometimes. I run into issues pretty frequently where my layout flickers because the children of the safe area view component are first laid out without the safe area insets, and then they flicker to the correct position where they should have been on first render.

In multiple places in my application, I've had to outright remove <SafeAreaView edges={['top']}> because the layout flickers and replace it with useSafeAreaInsets. That works fine a lot of the time, but there are situations where it's not an option (Such as in a TabBar component used with React Navigation). And in those cases, I'm left to try hacky things.

For example, I have a new user profile screen that queries the profile data. On the initial render, there is a loading indicator rather than the profile itself. When the profile is fetched it is displayed. In the demo version of the app, the profile fetching happens immediately, and therefor the screen rerenders immediately. I have a bottom TabBar that uses a <SafeAreaView edges={['bottom']}>. On the initial render, the tab bar doesn't have any insets at all!

This only seems to happen when the component is immediately rerendering in this case (but in other cases it just happens for no reason). If I make the fetch user profile function sleep momentarily with a timeout with 0 ms, the flickering doesn't happen. It's a hack to deal with the fact that this library allows renders without insets.

I just feel like the safe area view should never allow for a situation where it can render without the insets. If it were able to always render with insets, layout flickering would be impossible.

I'm really not sure how the insets aren't getting applied on first render, but they aren't. It seems like they should be based on the code for SafeAreaView.

[jacobp100]

Could you give a bit more information about your setup?

SafeAreaContext takes an initialSafeAreaInsets prop, which you can set to initialWindowMetrics.insets (which is the insets when the app launched).

I did notice a few things that might be interfering with some setups, but would be good to hear what your setup is so we can do the right fix.

[danilobuerger]

@iway1 is this fixed for you with #229 ?

[danilobuerger]

@jacobp100 @janicduplessis Another thing I noticed which might be related to this: Whenever adding a SafeAreaView on iOS the children will get the same size set as the SafeAreaView on the first batch layout as its not attached to the window hierarchy yet and doesn't have access to the proper safeAreaInsets. As soon as didMoveToWindow happens, the shadow view gets the safe area insets and then on the second layout the children will get the inseted (proper) size. Sometimes it seems (only on device) that between the first and second layout the whole thing gets rendered thus appearing on screen without any insets. A potential fix (see below) might be setting the display = YGDisplayNone in the shadow view until it receives its first safe area insets. However, I am unsure if that makes sense, so I wanted your opinion before opening a PR with it. With the diff below the children of SafeAreaView will not get their frame set until it has received the first insets.

diff --git a/node_modules/react-native-safe-area-context/ios/SafeAreaView/RNCSafeAreaShadowView.m b/node_modules/react-native-safe-area-context/ios/SafeAreaView/RNCSafeAreaShadowView.m
index c4afdae..056879a 100644
--- a/node_modules/react-native-safe-area-context/ios/SafeAreaView/RNCSafeAreaShadowView.m
+++ b/node_modules/react-native-safe-area-context/ios/SafeAreaView/RNCSafeAreaShadowView.m
@@ -35,6 +35,7 @@ - (instancetype)init
       _paddingMetaProps[ii] = YGValueUndefined;
       _marginMetaProps[ii] = YGValueUndefined;
     }
+    self.display = YGDisplayNone;
   }
   return self;
 }
@@ -95,6 +96,8 @@ - (void)updateInsets
     return;
   }
 
+  self.display = YGDisplayFlex;
+
   UIEdgeInsets insets = _localData.insets;
   RNCSafeAreaViewMode mode = _localData.mode;
   RNCSafeAreaViewEdges edges = _localData.edges;

[jacobp100]

I wanted to rework getting the sage area insets directly from the provider rather than relying on UIKit to propagate it to subviews (see #92). I think the fix for that would also fix the issue you just mentioned

[jameswilddev]

I'm seeing similar behavior. I think most apps have a single SafeAreaView for the entire application so this effect is hard to notice, but this one I'm currently working on needs a bit more of a customized approach and I'm noticing a 1-frame hitch in which the safe area insets are not applied any time a new SafeAreaView is mounted.

[neiker]

We recently migrated from react-native-safe-area-view and the solution there was to use forceInset but I found is not possible on react-native-safe-area-context and using edges is usually ignored while transitioning to a new screen

Also related: #219

[egorkhmelev]

This is pretty unpleasant bug which makes nearly impossible to use SafeAreaView, which is suggested by this library as a main way to use this library. Personally I see this flicker every time I force reload the app.

[jacobp100]

We need more information about what your setup is - really with a minimal repro - to fix the problem if it's a bug, or tell you where you're going wrong if it's not

[egorkhmelev]

@jacobp100 thank you for you comment.
Simple repo here: https://github.com/egorkhmelev/safe-area-bug

What I've noticed, the more complex screen structure the easier to reproduce the issue, with simple structure its almost unnoticeable, however if you record simulator screen and reload multiple times, then analyse video file frame by frame it can be spotted even though it was unnoticeable by the eye. I have easier times to spot it on real device versus simulator with the same project (sample and own). I've tried two different structures: simple and more complex (as per example for native stack in lib repo), reproducible on both.

Even though useSafeAreaInset() hook doesn't lead to the same issue on the test project, it does on real project with complex structure even if all screens is wrapped with withProvider helper (wrapped in SafeAreaProvider)

Below are two sets of two frames, screenshot was made from recorded video file.

SafeAreaView for both top & bottom view:

useSafeAreaInsets() for top view and SafeAreaView for bottom view:

Would be great to hear your thoughts what is wrong in setup/configuration of the project and/or lib and how this issue can be fixed. Thank you!

[jacobp100]

What happens if you set follow the instructions here for this

[egorkhmelev]

@jacobp100 Change added and committed. Bug is still reproducible both on test project and own project for SafeAreaView case. Cannot reproduce for test & own project with useSafeAreaInset() hook instead of SafeAreaView with initialMetrics configured.

[egorkhmelev]

Further test showed that the only configuration which avoids this issue with react-navigation and native stack is to use useSafeAreaInset() hook instead of SafeAreaView with initialWindowMetrics for root SafeAreaProvider and also with withProvider wrapper (without initial metrics) for each screen.

Maybe it will be useful for other folks here as a workaround for now.

[jacobp100]

The hook has a slightly delayed response to changes compared to SafeAreaView. SAV is done purely natively, so we skip the bridge. But if something else has a delay, sometimes it’s good to match that so there’s less flicker.

[egorkhmelev]

@jacobp100 not sure I understand what you mean exactly. I do understand the difference of SAV vs hook (and bridge) and that's why I am really curious to make SAV works correctly without flicker in our app. Is there anything we can do to make it work correctly? Or this needs to be fixed in the lib?

[jacobp100]

To be honest, you should only use the hook when you absolutely have to - when it updates, it lags behind SAV. I think the problem for you is your navigation library is using it