do we still need to use // eslint-disable-next-line no-unused-vars after props is used?

Wondering if this ternary is short and sweet, see: https://www.notion.so/commapp/Diff-Review-Rules-addfc3a41b324c7d8ba636dd9dcefeba

typo

I mean it's literally just

headerProps.canGoBack
      ? (<HeaderBackButton {...headerProps} />) 
      : (<CommunityDrawerButton navigation={props.navigation} />),

but prettier makes it uglier...
But I suppose I could write any amount of code in one line, if I were not following the prettier rules, so this counts as multiple lines.

Using useNavigation hook would work, since "useNavigation() returns the navigation prop of the screen it's inside" (source: docs), but I would have to:

• Add a flow type for useNavigation that allows it to return DrawerNavigationProp (we only have it typed as function useNavigation(): NavigationProp<ParamListBase>;, that does not include openDrawer that I need from it)
• Use the button in screens that have a navigation prop of DrawerNavigationProp type

So I don't think the code would be much simplified since the navigation prop would still need to be explicitly typed by me in the Profile and Chat screens.
And I would have to spend a non-trivial amount of time trying to get the flow type right.

Should I do it anyway?

It still affects the left and right sides if applicable (possible values here include left and right). I thought I could at least remove the top altogether, but then when I close the app on calendar tab, and re-open it, there is a black strip between the 'CONNECTING...' bar and the header for a moment. This is due to components being displayed while some calculations are still in progress, and it is kind of described in the SafeAreaViews README (at the bottom). So I think this is necessary.

By looking at the code https://github.com/react-navigation/react-native-safe-area-view/blob/master/src/index.tsx#L174-L180 it seems like never should behave the same as not specifying the value, so in this case not using forceInset prop at all. If it works with the current approach and doesn't work otherwise, we can keep it, but it is surprising.

I think we can remove the SafeAreaView here entirely given we use react-native-orientation-locker to lock to portrait mode while on the Calendar tab

This is the only usage of this package, so it can be removed from the package.json. Can you please make this change before landing?