| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
chore: sort imports automatically | 3 年前 | |
feat: add an ID prop to navigators When we have nested navigators, we often may want control over which navigator should handle an action that we dispatch. This is often handled automatically, e.g. if you navigate to a screen named Settings, the navigator which contains the Settings screen will handle the action. But in some cases, it's not possible to figure out the navigator automatically. Some example cases: We may want to have nested drawers to have a drawer on the left, and one on the right - and still be able to open/close them. We can use getParent to achieve this: js navigation.getParent().openDrawer(); However, this is prone to error if we nest another navigator inside (e.g. a stack). So we need a way to distinguish between which drawer we want to target. An alternative way to distinguish different navigators is to specify the key of the navigator in the target field of the action: js navigation.dispatch({ ...DrawerActions.openDrawer(), target: 'keyOfTheDrawer', }); However, this has a few problems: - It's not straightforward to get the key of the navigator since the key is generated by React Navigation. - It's not type-safe. Nothing ensures that the key is valid. We may also want to call setOptions on a parent navigator. The options don't bubble up unlike the actions, so it's important make sure to call it for the correct navigator. We can use getParent in this case as well, but it's prone to the same set of issues as the previous case. There are also no alternatives for this unlike specifying key for actions. This commit adds a id prop to navigators. Example: js <Drawer.Navigator id="LeftDrawer">{/* ... */}</Drawer.Navigator> Then we can use it along with getParent as follows: js navigation.getParent('LeftDrawer').openDrawer(); No matter how many nested navigators are added, we can always find the correct navigator this way. To make this work with type-checking, we'd pass a third generic to our NavigationProp or ScreenProps types: ts type LeftDrawerScreenProps<T extends keyof LeftDrawerParamList> = DrawerScreenProps<LeftDrawerParamList, T, 'LeftDrawer'>; This isn't the best way to do this, for example, the id prop on the navigator itself isn't type-safe. But supporting it with a good API is a lot of work, so for now, I've decided to go with this alternative approach. | 3 年前 | |
fix: don't use BackHandler on web for drawer | 2 年前 | |
chore: add license header and format code style (#46) Co-authored-by: kongchuiyu <kongchuiyu@h.partners.com> (cherry picked from commit be79e1f359c63e5bc69880c4770a1774451aea40) Signed-off-by: ludeyin <2930650146@qq.com> | 9 个月前 | |
fix: drawerstatuscontext should be exported (#11041) **Motivation** DrawerStatusContext should be exported and available to the library's users. For example, someone might want to create a custom Drawer navigator using useNavigationBuilder and reuse this context. (Previous PR: https://github.com/react-navigation/react-navigation/pull/10976) | 3 年前 | |
fix: added close drawer accessibility tap area (#11184) **Motivation** Currently, a user can tap the Overlay next to an open drawer to close the drawer. This is useful in an Accessibility setting when swipe actions are not obvious to the user. Unfortunately, it is not obvious to someone with a visual deficit that this area can be tapped to close the drawer, as this overlay does not have an accessibilityLabel prop exposed. This PR exposes an accessibilityLabel prop on this overlay component and modifies existing accessibility props to allow for accessibility tap permissions on the overlay component. It then surfaces this prop at the Drawer level as closeAccessibilityLabel. **Test plan** Open up the example app with TalkBack (Android) or VoiceOver (iOS) enabled. Tap on the overlay next to the drawer and observe that it will now read out as "Close drawer". | 3 年前 |