## Motivation
Right now `headerMode: float` renders an absolutely-positioned header. To offset the content appropriately, it then measures the height of the header and compensates with a margin. This approach unfortunately doesn't work well for animations.
Before | After
:-------------------------:|:-------------------------:
<img src="http://ashoat.com/jerky_absolute.gif" width="300" /> | <img src="http://ashoat.com/smooth_relative.gif" width="300" />
## Approach
When rendering the header absolutely we want to render it above (after, in sibling order) the content. But when rendering it relatively we want to render it first (before, in sibling order).
The margin compensation code is no longer necessary so I removed it.
## Test plan
I used the `StackHeaderCustomization` example to make sure transitions between `headerTransparent` and `!headerTransparent` looked good. I added a custom (taller) header to test if height transitions looked good, and toggled `headerShown` to make sure that transitioned well too.
Would be open to any other suggestions of things to test!
The PR reworks history integration to better integrate with browser's history stack and supports nested navigation more reliably:
- On each navigation, save the navigation in memory and use it to reset the state when user presses back/forward
- Improve heuristic to determine if we should do a push, replace or back
This closes#8230, closes#8284 and closes#8344
Currently, if we don't have matching routes for a path, we'll reuse the path name for the route name. This doesn't produce an error, and renders the initial route in the navigator. However, the user doesn't have a way of handling this with the default configuration.
This PR adds support for a wildcard pattern ('*'). The wildcard pattern will be matched after all other patterns were matched and will always match unmatched screens. This allows the user to implement a 404 screen.
Example:
```js
{
Home: '',
Profile: 'user/:id',
404: '*',
}
```
This config will return the `404` route for paths which didn't match `Home` or `Profile`, e.g. - `/test`
Closes#8019
Co-authored-by: Evan Bacon <baconbrix@gmail.com>
User can pass a `ref` to the container to get current options, like they can with `NavigationContainer`:
```js
const ref = React.createRef();
const html = renderToString(
<ServerContainer ref={ref}>
<App />
</ServerContainer>
);
ref.current.getCurrentOptions(); // Options for screen
```
When doing SSR, the app needs to be aware of request URL to render correct navigation state.
The `ServerContainer` component lets us pass the `location` object to use for SSR.
The shape of the `location` object matches the `location` object in the browser.
Usage:
```js
ReactDOM.renderToString(
<ServerContainer location={{ pathname: req.path, search: req.search }}>
<App />
</ServerContainer>
);
```
Updated example: https://github.com/react-navigation/react-navigation/pull/8298
## Motivation
Some designs call for custom keyboard inputs, or other bottom-aligned views meant overlap over the keyboard. Right now the best option on Android for this case is to set `tabBarVisible`. However changes to `tabBarVisible` doesn't get animated currently, which makes the custom-keyboard-open experience a bit more jarring than the native-keyboard-open one.
## Approach
I basically cribbed the `Animated.Value` we were using for `keyboardHidesTabBar` and made it depend on both. Note that the offset height depends on which of the two uses cases we're dealing with, which is explained in the code.
## Test plan
I played around with the `BottomTabs` example, setting certain screens to `tabBarVisible: true` and making sure it animated.
I made sure 1.0 is backwards compatible with react-navigation, which means using rn-safe-area-context@1+ with older versions of react-navigation will still work.
The tests are being bundled and shipped in prod, this adds a bit of unneeded weight to npm installs. Now they won't be included.
```
@react-navigation/core
- before: 274 files - pkg: 211.0 kB - unpkg: 1 MB
- after: 238 files - pkg: 192.1 kB - unpkg: 827.3 kB
```
