Refactor right buttons
This pr started with an attempt to eliminate button flickering entirely when updating buttons which contain react components via mergeOptions. While the attempt wasn't 100% successful, I dit get some insights in the process.
* It's not possible to add buttons at specific indices. Buttons contain an order property which determines the order of the button in the TopBar. To somewhat overcome this limitation, we can let users control button order via options.
* When a right most component button is replaced with another component button, the rest of the buttons shift to the right since the newly added component isn't measured when it's added to the menu and its width is zero.
We usually handle this situation with the `waitForRender` option but since buttons are measured with `MeasureSpec.UNSPECIFIED`, their dimensions are zero. Because of this, I've added options to set button dimensions.
* When updating buttons via mergeOptions, if a component button is already added to the menu with the same order we will not remove and added it again. This mitigates flickering in some situations.
* Textual button style properties were applied by traversing the view hierarchy and searching for the TextView corresponding to the button and updating its styles directly.
There was an inherent bug in this logic where if two buttons contained the same text, styles could have been applied to the wrong TextView. We now apply styles directly on the button using spans.
* Fix invalid popover enum value for modal presentation style
The correct enum value as defined in lib/ios/RNNConvert.m is "popover" not "popOver", in line with UIModalPresentationPopover.
* Add to documentation on modal presentation styles
Add popover value and link to iOS documentation.
Co-authored-by: Yogev Ben David <yogev132@gmail.com>
Merge v5 into master
Highlights of this release
* Easier installation
* autolink and reac-native link support
* Shared Element Transition - reimplemented from scratch and new API
* [iOS] showModal animation api parity
* [Android] Animation values are now declared in dp
* [iOS] deprecate topBar.drawBehind
* [Android] RNN is migrating to Kotlin
closes #5904
Fix native image resource for bottom tab icon (#5775)
bottomTab.icon accepts a string as well as required asset - this was not reflected properly in TypeScript and implementation was missing from Android.
closes #5759
Fix default modalPresentationStyle on iOS 13 (#5709)
* Set as default modalPresentationStyle
* Sets the system default modalPresentationStyle
* Fix tests
* Fix unit tests
* Fix unit tests
* Add modal.swipeToDismiss option
Allow to update props for a specific component (#5612)
This commit adds support to update props of screen or custom button/title via the mergeOptions api.
```js
Navigation.mergeOptions('myComponentId', {
passProps: {
text: 'new value'
}
});
```
# Changes
* Support RN 0.60
* Migrate to AndroidX
* Improve draw behind StatusBar (Preparation for #4258)
* Don't push BottomTabs when keyboard is displayed (Fixes #4005, #3424)
- It won't be needed to toggle the BottomTabs when Keyboard is visible
* BottomTab badge and dot indicator are not animated by default on Android (parity with iOS)
# Updating from v2
v3 is currently in alpha. To update simply npm install `3.0.0-alpha.11` - `npm install --save react-native-navigation@3.0.0-alpha.11`.
Breaking changes are outlined below.
## Layout system changes on **Android**
* Parent layouts (BottomsTabs, Stack, SideMenu) are always laid out behind the StatusBar.
* Components (`component` and `externalComponent`) are measured and offset according to the StatusBar.
In this release, We're changing the layout system in order to provide better support for immersive and full screen apps. In this release we've improved support for drawing behind the StatusBar, next we'll address drawing behind the NavigationBar.
Use the `drawBehind` and `translucent` options to control the StatusBar
```js
statusBar: {
drawBehind: true, // will draw a screen behind the StatusBar
translucent: true // Usually you'll want to have drawBehind: true when this is true
}
```
While this isn't a breaking API change - there are a few breaking side effects.
### How will my app be effected
1. When the keyboard is opened, BottomTabs will now be drawn behind the keyboard and won't shift upwards. This is in parity with the current behaviour in iOS. For the most part, this isn't a breaking change. Toggling BottomTabs when TextInput's focus changes won't be needed anymore.
2. While parent controllers are drawn behind the StatusBar, their background isn't.
This means that when transitioning from a destinations drawn under the StatusBar to a destination drawn behind it, the application's default background color will be visible behind the StatusBar.
If you application's theme is dark, you might want to change the `windowBackground` property to mitigate this:
Add the following to your application's `style.xml`
```xml
<?xml version="1.0" encoding="utf-8"?>
<resources>
<style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar">
<item name="android:windowBackground">@color/backgroundColor</item>
</style>
<!--This is your application's default background color.
It will be visible when the app is first opened (while the splash layout is visible)
and when transitioning between a destination a screen drawn under the StatusBar to
a destination drawn behind it-->
<item name="backgroundColor" type="color">#f00</item>
</resources>
```
## AndroidX migration
We've migrated RNN to AndroidX, please follow migration instructions in the react-native repo.
## Removed SyncUiImplementation
[SyncUiImplementation](https://github.com/wix/react-native-navigation/blob/master/lib/android/app/src/reactNative57WixFork/java/com/reactnativenavigation/react/SyncUiImplementation.java) was used to overcome a bug in RN's UiImplementation. This workaround was added to RN's `UiImplementation` in RN 0.60 (thanks @SudoPlz) and can be removed from RNN.
If you're using `SyncUiImplementation` your app will fail to compile after upgrading to v3. Simply remove the following code from your `MainApplication.java`
```diff
- import com.facebook.react.uimanager.UIImplementationProvider;
- import com.reactnativenavigation.react.SyncUiImplementation;
- @Override
- protected UIImplementationProvider getUIImplementationProvider() {
- return new SyncUiImplementation.Provider();
- }
```
## BottomTab badge and dot indicator are not animated by default on Android (parity with iOS)
Showing and hiding badge and dot indicator are now not animated by default. Badge animation is now controlled with the `bottomTab.animateBadge` property and dot indicator with `bottomTab.dotIndicator.animate` property.
#### The following option will show a badge with animation
```js
bottomTab: {
badge: 'new,
animateBadge: true
}
```
#### The following option will show a dot indicator with animation
```js
bottomTab: {
dotIndicator: {
visible: true,
animate: true
}
}
```
closes #5228
I found the names used for the animation classes to be a bit undescriptive,
even though this might break a few users I think it’s for the best as a few
contributors were confused by these names as well.
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 property is used to set background color only for components,
unlike backgroundColor which sets color for every type of layout.
Motivation
When a view appears, its options are resolved according to its
currently displayed children. Basically this means that child options
are hoisted to the parent as children can declare options which effect
their parent.
This means that if a component has declared layout.backgroundColor or
if that property was declared in defaultOptions, each view will have a
background color, which might contribute to a significant overdraw.
Until now controlling drawers touch gestures was impossible, drawers received gesture opening touch from the entire screen and that causes collisions with other gestures (which are implemented on the javascript side).
This commit adding modes for how sideMenu drawers gestures will receive opening touch.
```
{
sideMenu: {
openGestureMode: 'entireScreen' | 'bezel'
}
}
```
- `entireScreen`: drawer gesture will trigger drawer opening from the entire screen
- `bezel`: drawer gesture will trigger drawer opening only from the center screen bezel frame
The default didn't change.