Detach bottomTabPresenter from basePresenter (#5970)
Refactor bottomTabs options applying mechanism. Both bottomTab and bottomTabs presenters were part of the base UIViewController class which was wrong. This commits moves them to the BottomTabsController.
This refactor mostly contains the following
* Detach bottomTabPresenter from basePresenter
* Create tabBarItem appearance on presenter init
* Refactor bottomTabPresenter
* Refactor bottomTabPresenter
* Move appearance creation to bottomTabsController
* Merge child options with direct child controller
Add iOS support for `bottomTabs.attachMode`.
This property controls when BottomTabs children are attached to hierarchy and when their React views are created.
By default, RNN attaches all children at the same time which might impact loading time as a few screens are instantiated at once.
Using `afterInitialTab` or `onSwitchToTab` generally leads to improved start up time.
Break all the PRs :(
iOS and Android code base used different naming conventions - this commit aims to unify naming conventions. I probably missed a few properties here and there so this will be an ongoing effort.
* Enabled option was wrongly consumed after it was merged. That meant that the next time SideMenu options were applied, the wrong enabled value was applied
* supportedInterfaceOrientations didn't take default orientation value into account
* mergeOptions didn't save the new options in the ViewControllers current options
* SideMenu always returned the centre ViewController as the current child and didn't take open SideMenu into account
Fixes #5444
Merging TopBar title, buttons and status bar options is broken on iOS in 3.1.1.
Parent options aren't resolved properly and default options aren't regarded when they should be.
This approach is still not ideal as it assumes there's a visible stack somewhere in the Hierarchy.
It's better than the current implementation so I'm pushing it and will reiterate in the future if needed.
* bind viewController to presenters using bindViewController
* Merge options to the specific provided layout
* Moved custom titleView creation to RNNRootViewController
* Moved default options to presenters, moved options applying to presenters, resolved options in RNNOptionsResolver
* Fixes merge options
* Fixes topBar transition on pop
* Prevent titleView creation when react titleView exists
* Fixed unit tests
* Options refactor WIP
* Detach applied options from DTO - WIP
* Added option types and option parsers
* Unit test passes
* Added presenters for each parent type
* Fixes unit tests
* Rename StringParam to Text, changed bottomTabs.drawBehind and topBar.drawBehind default to false
* set layout.backgroundColor default to white
* Added unit tests for RNNViewControllerPresenter
* Set layout.backgroundColor default nil
* Fixes buttons color missing options
* Fix unit test
* fix button color parsing
* Moved default options to presenters
* default options fixes
* Fixes e2e
* Fixes unit tests
* Resolve child options on childWillAppear
* Recrusively setDefaultOptions on rootViewController tree
* Fixes default values
* Fixes tests
* Renamed RNNRootViewProtocol to RNNParentProtocol and added RNNLeafProtocol
* fixed unit test
* Better options resolving
* Revert "Revert "Refactor options (#3962)""
This reverts commit c266041b85.
* Revert "Revert "Fixes shared element transition""
This reverts commit 005f039f7c.
* Revert "Revert "Adresses #3963 - stack options applied to children""
This reverts commit be09cb0e9a.
* Revert "Revert "Added unit test coverage for RNNNavigationController""
This reverts commit 199cebd221.
* Merge stack options
This commits adds support for merging stack options by the stack’s componentId
Also while I’m at it - use fade animation when setting root
* Merge BottomTabs options
Merge BottomTabs options when calling mergeOptions with BottomTabs componentId
* Fixes options
[BREAKING] Call Navigation.events().bindComponent(this) to listen to lifecycle events
This commit introduces breaking changes to the way components listen to RNN events.
Background
Up until now, components could handle navigation events by implemented a set of callbacks:
* componentDidAppear
* componentDidDisappear
* onNavigationButtonPressed
* onSearchBarUpdated
* onSearchBarCancelPressed
While this worked fine for the most part, this was completely broken for HOCs as RNN invoked these methods only on the registered component (top most HOC), leaving it to the user to propagate these events down the HOC chain. See the discussion in #1642 for more details.
Solution
In order to support HOC use case, we're introducing a new api which will let any Component bind itself to receive navigation events:
```js
class LifecycleScreen extends Component {
constructor(props) {
super(props);
this.subscription = Navigation.events().bindComponent(this);
}
componentWillUnmount() {
// The subscription is removed automatically when components unmount, but they can be explicitly removed as well by calling `this.subscription.remove(); `
}
}
```
It's still the users responsibility to propagate the `componentId` down the HOC chain, but by binding a component to RNN, it will be able to handle events as expected. Multiple components can be bound for the same `componentId`.
Consolidate event names
* onNavigationButtonPressed -> navigationButtonPressed
* onSearchBarUpdated -> searchBarUpdated
* onSearchBarCancelPressed -> searchBarCancelPressed
Yogev Ben David
Guy Carmeli
Pontus Abrahamsson
N3TC4T
Guy Carmeli
Yogev Ben David
Daniel Zlotin