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
* Refactor peek and pop
* Rollback some XCode stuff
* Added tests for touchablePreview event
* Also fixing searchbarcancelpressed event
* Making sure tests work
[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
Summary: This adds a new event `onSearchBarCancelPressed` that fires
when the user presses the cancel button on the search bar in the
navigation bar. `onSearchBarUpdated` does indirectly fire when the user
presses cancel, as the query will be reset to an empty string, but it is
not possible to distinguish those events from the user simply resetting
the query. My use case for this is to have a view that appears on top of
the normal content of the view controller when the search bar is
focused.
Test Plan: ran `npm run test-js` and confirmed added JS unit tests
passed.
I also tested this with my app, and confirmed the
`onSearchBarCancelPressed` method was called when I pressed the cancel
button.
* Refactored backButton api
* Move StackController to separate package
Implement BackButtonOptions
* Somewhat simplify StackController creation in tests
* Pull backButton logic from StackController
* Handle all TopBar button options in TopBarButtons
* fix back button on iOS
Guy Carmeli
Yogev Ben David
yogevbd
Birkir Rafn Guðjónsson
Seth H Rogers
Dima Loktev
Daniel Zlotin
Ben Hiller