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
This commit adds a check to detect if the screen content fills the available body, and if yes, then it adjusts the styles so that scrolling triggers a scroll on the body which hides the address bar in browser.
Tested on Safari in iOS and Chrome on Android.
This behaviour can be overriden by the user by specifying `cardStyle: { flex: 1 }`, which will keep both the header and the address bar always visible.
Gesture handler doesn't work great on Web and causes issues such as disabling text selection even when not enabled. So we stub it out. It also reduces bundle size on web.
