* Cleanup and reorganise playground app
* Separated tests into three categories
1. Layouts - layout specific tests and feature showcase
2. Options - options related tests; interactions between static and dynamic options, merge options etc
3. Navigation - general navigation features; Orientation handling, events, Overlay etc
* Fixed a few Android bugs
1. testID wasn’t applied on TopBar react buttons
2. static options were disregarded when creating initial BottomTab options
3. Trying to open a none existent SideMenu would result in a crash
* Fix e2e tests
* Fix lint
* Few fixes + split push from SideMenu test into two tests
* Fixes e2e
On Android options were not updated when SideMenu was opened or closed
via swipe gesture. This caused bugs when trying to interact with the drawer again via gestures since
the drawer would immediately close or open according to the visibility in options.
When loading local image resource (images in Drawable folder), RNN mistakingly tried to load the image as a js asset even if it successfully loaded the local image.
Use autolayout constraints to set size of custom bar button item (#4732)
This fixes an issue where the frame for the custom view can be set to the incorrect y-offset upon setting the custom frame.
In iOS 11, this behavior changed, as UIBarButtonItem went from being using springs-and-struts for sizing, to using a UIStackView, and thus using Autolayout.
This lead to the superview of having a frame of (0, 22, 0, 0) at the first layout pass.
By moving to using NSLayoutConstaints, we can now properly size our custom view.
See also: https://gist.github.com/niw/569b49648f
See also: https://stackoverflow.com/questions/10988918/change-width-of-a-uibarbuttonitem-in-a-uinavigationbar
Using lodash.set caused issues when keys contained the dot symbol. _.set created objects inside the store, which is intended to be a simple key value dictionary -
In some cases, set would overwrite previously set values.
Doing `git clone -b v2 git@github.com:wix/react-native-navigation.git` gives me this:
```
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
```
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.