Passing route params as first level props
mtnt opened this issue · 4 comments
Current behavior:
If we call this.props.navigator.navigate("RouteName", {routeParams})
we will have to call this.props.navigator.params.routeParams
for get it inside the screen with "RouteName" route.
Actually it`s not a big trouble. But some inconvenient cases exists:
For example if we already have a screen component, that expect some outer data for work. We will have to rewrite its behavior. So it can be a reusable component and just one of usage case with navigation.
On the other hand, we can create a component and don`t know will it be a route screen or not.
Proposal
Remake the interface of params.
Pass params as first level props:
Passed the same way params: navigation.navigate("routeName", {param0: "foo", param1: "bar"})
Should be available to get: this.props.param0
benefits:
- it will make components more independent from a navigator.
- it will reduce interface overhead with getting params with default values by delegating it to the well known react way
Save navigation
prop with navigation methods
For backward compatibility and for those who makes exactly navigation scenes that should know about the navigator.
Think about changing the params
I still don`t know how to share data with header. But I think params passed by .navigate
method should not be able to be changed from inside a screen. An alternative way should be found.
I guess we need to save route params as is and make an independent way to crosspassing data between a scene and a header (something like outer state
of component).
If someone see any obstacles, pls tell it. We should to take into account all options.
with your proposal, how does this get passed into navigationOptions
?
static navigationOptions = ({ navigation }) => {
// how do I access params here?
}
I guess, it should be considered from a purpose point of view. So since I propose it for being able to create independently (from navigation) components, it is the purpose.
If someone makes the static navigationOptions
inside his component, so, I guess he don`t want to make that component independent from navigation. And params could be accessible from the navigation.params
or as navigation
sibling property - actually it does not matter.
However I still think that route params and scene outer params should be separated. So it would be pretty good to have static navigationOptions({navigation, routeParams, innerParams})
or something similar.
React Navigation 5 passes a route
object as a prop which makes accessing the params shorter (route.params
as opposed to navigation.state.params
).
Passing params as to-level props doesn't make components any independent of the navigation library since you still use the navigation
prop which is specific to the library. To make something really independent and reusable, we'd have to extract it out to a separate components, abstract these methods out and pass them.
Passing params as top-level props also means that we can't add any more props to screens in future since there's now a chance of conflicts.
Closing since this is not something we'll implement.