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
```
Currently, when we define path patterns in the linking config, they ignore the parent screen's path when parsing, for example, say we have this config:
{
Home: {
path: 'home',
screens: {
Profile: 'u/:id',
},
},
}
If we parse the URL /home, we'll get this state:
{
routes: [{ name: 'Home' }],
}
If we parse the URL /home/u/cal, we'll get this state:
{
routes: [
{
name: 'Home',
state: {
routes: [
{
name: 'Home',
state: {
routes: [
{
name: 'Profile',
params: { id: 'cal' },
},
],
},
},
],
},
},
],
}
Note how we have 2 Home screens nested inside each other. This is not something people usually expect and it seems to trip up a lot of people. Something like following will be more intuitive:
{
routes: [
{
name: 'Home',
state: {
routes: [
{
name: 'Profile',
params: { id: 'cal' },
},
],
},
},
],
}
Essentially, we're treating patterns as relative to their parent rather than matching the exact segments. This PR changes the behavior of parsing links to treat configs like so. I hope it'll be easier to understand for people.
There is also a new option, exact, which brings back the olde behavior of matching the exact pattern:
{
Home: {
path: 'home',
screens: {
Profile: {
path: 'u/:id',
exact: true,
},
},
},
}
Which will be useful if home is not in the URL, e.g. /u/cal.
This change only affects situations where both parent and child screen configuration have a pattern defined. If the parent didn't have a pattern defined, nothing changes from previous behavior:
{
Home: {
screens: {
Profile: {
path: 'u/:id',
},
},
},
}
