BREAKING CHANGE: This commit moves options from `drawerContentOptions` to regular `options` in order to reduce confusion between the two, as well as to make it more flexible to configure the drawer on a per screen basis.
This commit adds new `header` and `headerShown` options in drawer navigator to be able to show a header, along with a bunch of header related options similar to stack navigator.
Historically, we have suggested to nest a stack navigator inside drawer navigator to render a header. While it works, it's not efficient to nest an entire navigator just for a header, considering it adds a lot of additional overhead from the code to handle animations, gestures etc. which won't ever be run in this case. It also increases the view hierarchy which has negative impacts on performance on Android, and could cause content not to render on older iOS devices.
Another issue with the approach is that since drawer navigator is at the root in this setup, it's possible to open drawer from every screen in the stack navigator, which usually isn't the expected behaviour. It's necessary to write additional code to disable the gesture to open drawer in all screens but first.
In addition, users also need to add a custom drawer icon to the header manually to be able to toggle the drawer
If drawer navigator could render its own header we'd avoid all these shortcomings as well as make the code simpler.
For now, I have implemented a new `Header` component in drawer since it's way simpler than stack navigator header. Though we may consider creating a shared UI package and add such components there which all our navigators could use.
The `Header` includes a button to toggle the drawer by default, and supports customization options such as showing custom left/right/title components. For this commit, I have kept `headerShown` to `false` by default coz I wasn't sure if it'd be a breaking change to start showing headers in drawers. Probably we can toggle it to `true` by default in next major.
A lot of times, we want to prompt before leaving a screen if we have unsaved changes. Currently, we need to handle multiple cases to prevent this:
- Disable swipe gestures
- Override the back button in header
- Override the hardware back button on Android
This PR adds a new event which is emitted before a screen gets removed, and the developer has a chance to ask the user before closing the screen.
Example:
```js
React.useEffect(
() =>
navigation.addListener('beforeRemove', (e) => {
if (!hasUnsavedChanges) {
return;
}
e.preventDefault();
Alert.alert(
'Discard changes?',
'You have unsaved changes. Are you sure to discard them and leave the screen?',
[
{ text: "Don't leave", style: 'cancel', onPress: () => {} },
{
text: 'Discard',
style: 'destructive',
onPress: () => navigation.dispatch(e.data.action),
},
]
);
}),
[navigation, hasUnsavedChanges]
);
```
The PR changes a few things about linking configuration:
- Moves the configuration for screens to a screens property so that it's possible to specify other options like `initialRouteName` for the navigator at root
- The nesting in the configuration needs to strictly match the shape of the navigation tree, it can't just rely on URL's shape anymore
- If a screen is not specified in the configuration, it won't be parsed to/from the URL (this is essential to handle unmatched screens)
- Treat `path: ''` and no specified path in the same way, unless `exact` is specified
- Disallow specifying unmatched screen with old format
- Add support for `initialRouteName` at top level
- Automatically adapt old configuration to new format
The `devtools` package extracts the redux devtools extension integration to a separate package. In future we can add more tools such as flipper integration to this package.
Usage:
```js
import * as React from 'react';
import { NavigationContainer } from '@react-navigation/native';
import { useReduxDevToolsExtension } from '@react-navigation/devtools';
export default function App() {
const navigationRef = React.useRef();
useReduxDevToolsExtension(navigationRef);
return (
<NavigationContainer ref={navigationRef}>{/* ... */}</NavigationContainer>
);
}
```
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>
The `Link` component can be used to navigate to URLs. On web, it'll use an `a` tag for proper accessibility. On React Native, it'll use a `Text`.
Example:
```js
<Link to="/feed/hot">Go to 🔥</Link>
```
Sometimes we might want more complex styling and more control over the behaviour, or navigate to a URL programmatically. The `useLinkTo` hook can be used for that.
Example:
```js
function LinkButton({ to, ...rest }) {
const linkTo = useLinkTo();
return (
<Button
{...rest}
href={to}
onPress={(e) => {
e.preventDefault();
linkTo(to);
}}
/>
);
}
```
