react-navigation/rfcs

Passing route params as first level props

mtnt opened this issue · 4 comments

mtnt commented

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?
}
mtnt commented

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.

mtnt commented

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.