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',
},
},
},
}
# Why
When using the stack navigator on iOS, it takes a (too) long time before the `didFocus` and stack `onTransitionEnd` lifecycle events are triggered. The visual animation is typically completed well within 500 msec, but it takes around 1000 msec before the previously mentioned events are emitted. This causes problems with for instance `react-navigation-shared-element`, which relies on these events to fire in a timely manner(https://github.com/IjzerenHein/react-navigation-shared-element/issues/24)
# How
This PR updates the resting threshold so that the underlying spring settles faster. No visual differences or differences in smoothness were witnessed during testing.
## Before
Time to settle `didFocus`: **941**
Time to settle `stack.onTransitionEnd`: **924**
```
15:59:55.743 [ListViewStack]startTransition, closing: false, nestingDepth: 1
15:59:55.744 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false
15:59:55.745 Transition start: "ListScreen" -> "DetailScreen"
15:59:56.667 [ListViewStack]endTransition, closing: false, nestingDepth: 1
15:59:56.668 Transition end: "DetailScreen"
15:59:56.685 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1
```
## After
Time to settle `didFocus`: **529**
Time to settle `stack.onTransitionEnd`: **512**
```
15:55:00.686 [ListViewStack]startTransition, closing: false, nestingDepth: 1
15:55:00.687 [ListViewStack]willFocus, scene: "DetailScreen", depth: 1, closing: false
15:55:00.687 Transition start: "ListScreen" -> "DetailScreen"
15:55:01.198 [ListViewStack]endTransition, closing: false, nestingDepth: 1
15:55:01.199 Transition end: "DetailScreen"
15:55:01.216 [ListViewStack]didFocus, scene: "DetailScreen", depth: 1
