Refactor SplitView options and make them work with Tabs (#4612)
The bottomTab settings were not being properly applied if a SplitView
controller was nested. Part of this seems to be that the 'options' for
SplitView were in their V1 form, i.e. they did not have access to the
full topBar/bottomTab/etc.
I refactored the options to be in their own subsettings. NOTE: the
settings for splitView are not being applied currently -- they weren't
before and they still are not now.
With access to the full options now, I was able to change
RNNSplitViewController to properly override
willMoveToParentViewController to get the bottomTab icon to properly
show up.
This pr adds support for changing tab initialisation mode. Currently bottom tabs are attached together and consequently, their corresponding react root views are created and rendered. This adds lots of stress on the js thread and hiders app start time.
To mitigate this issue, this pr adds support for three modes
* `together` (default, current behaviour) - all tabs are loaded together, adding unnecessary load on the js thread as we're loading invisible views, which leads to increased app start time.
* `afterInitialTab` - Initial tab is loaded first. After it is rendered, other tabs are loaded as well. This should shave a few hunderdish ms from app start time. Since other tabs are loaded after the initial tab is visible, the ui might be unresponsive for a few hunderdish ms as multiple root views (which are typically complex) are being created and attached to hierarchy at once.
* `onSwitchToTab` - initial tab is loaded. Other tabs are loaded when switching to them (tab click or programmatically). While this won't stress js thread after initial tab is rendered, there will be a flicker when entering a tab for the first time as it's ui isn't ready.
This fixes a bug which occurred when returning from background - sometimes the system would set
an unexpected elevation value which seems like the default elevation.
This commit checks if the new elevation value was specified by RNN before setting it.
Fixes an issue with ScrollView inside an Overlay. While down events were propagated to the view, move events were consumed by the overlay preventing scroll components from functioning correctly.
Played around with context api, tried to get the wrapped component to rerender after global context
was updated - this is what I came up with.
Note: this commit makes the playground app use a newer js core as the js core which shipped with RN on Android
is missing javascript Proxy.
Closes #4517
Apparently TopBar elevation property is animated. Meaning that if 4dp elevation is set, when the
view appears its elevation is animated from 0dp to 4dp.
This resulted in rare race condition where the onAnimationEnd callback was called after
we set the desired elevation value, and an unexpected elevation value was set.