You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Controlling nested drawers
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:
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:
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.
Setting options for a parent navigator
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.
Proposal
An alternative solution would be to provide a name for a navigator, similar to screens. This will be a user-readable and type-safe string as opposed to the key. Example:
Then we can use it along with getParent as follows:
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 need to change our API to support name as well. So instead of an object type, user would need to do something like:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Motivations
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 theSettings
screen will handle the action. But in some cases, it's not possible to figure out the navigator automatically.Some example cases:
Controlling nested drawers
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: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 thetarget
field of the action:However, this has a few problems:
key
of the navigator since thekey
is generated by React Navigation.key
is valid.Setting options for a parent navigator
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 usegetParent
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.Proposal
An alternative solution would be to provide a
name
for a navigator, similar to screens. This will be a user-readable and type-safe string as opposed to thekey
. Example:Then we can use it along with
getParent
as follows: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 need to change our API to support
name
as well. So instead of an object type, user would need to do something like:Everything else should work as before. We would still support the old format, so it won't be a breaking change.
Beta Was this translation helpful? Give feedback.
All reactions