-
Notifications
You must be signed in to change notification settings - Fork 16
What should happen when passing params to a navigator route? #43
Comments
I don't think the But at first we should let the child navigator to receive params. There is some issue in current version and I have made a pull request #4306 . |
Since it is Since I believe the navigator should be able to made as a HOC (without any scene changed inside itself), params should be available to be taken in |
@mtnt - they are props. |
@brentvatne I meant first level props - About your comment. As I already said, I think params should be passed into a navigation target screen only (without passing through). What to do with it further is the screen responsibility. |
this causes a lot of confusion - react-navigation/react-navigation#4811 we should document |
I have a use case where It would be helpful to me that any screen / navigator under a certain navigator gets a common param, and I really believed this would be the default behavior (passing down all params with the child always having priority when param names conflict). I will use a workaround by extending navigator and using react context in the meantime 😄 |
Hi @Titozzz If you need to build some kind of multiscreen stateful wizzard you can share state across those screens by wrapping the navigator. MyStatelessStackNavigator = createStackNavigator({})
// Forward the prop
MyStatefulStackNavigator = ({navigation}) => (
<MyStateProvider>
<SomeFancyWizzardStepHeader/>
<MyStatelessStackNavigator navigation={navigation}/>
</MyStateProvider>
);
// Very important otherwise MyStatefulStackNavigator is not considered as a navigator
MyStatefulStackNavigator.router = MyStatelessStackNavigator.router;
export default MyStatefulStackNavigator; This is a common pattern where you just wrap a navigator inside custom one to enhance it. Unlike global state based solutions, this one will actually reset its state when you navigate away from this navigator, which makes it more suitable for transcient state like multi-screen forms/wizzards... I think we should do a better job at documenting this kind of patterns with react-navigation. Will probably write a blog about it soon. Note you might be tempted to try to use "screenProps" here but actually this should only be used on root app container, and after discussing with Satya last year he suggested using context is the way to go for this kind of usecase, and maybe screenProps would be deprecated some day. Note if you are looking for an easy to use state provider to make your stack navigation stateful, I think unstated is a very decent option and anyone knowing React will understand how to build features with this very easily. Once it's setup you almost get no learning curve. Only difference is setState being async (which imho is a nice addition). And if you don't need a stateful wrapper, you can still use the trick above and add a simple React context to propagate a static value to all subscreens. |
Using react context wrapping my navigator is exactly what I did, sorry I did not give more details in my above message 😄. And once hooks land in stable react-native it'll get even cleaner to use. |
I was struggling with the same, and after almost a week of frustration finally used context and got what I wanted, demonstrated in react-navigation/react-navigation#5646 I think the mention of possibilities with the use of cotext api (though it is in parent platform i.e. react) in react-navigation documentation would help a lot. Should we / I open an issue for this on documentation site repo? |
@bhave-abhay - a docs page for that could be really great! you would probably be a great person to write it given the experience you've had, can you open a pr for it? |
Instead of passing the selected contest as a nav param to the nested navigation structure (tab + stack navigators), which is tricky because params don't propagate to child navigators (see react-navigation/rfcs#43 and react-navigation/rfcs#68), we wrap the navigator structure with a ContestNavigator that receives the current contest as a prop, and passes it forward to its navigation screens as a param. The RootView component tracks the current contest and renders either a ContestNavigator or (if no contest selected) a contest picker.
@brentvatne
One scenario for the routing is an app that shows a list of items in in the current implementation, we should pass all parameters to the
Not passing down the params causes we lose the above ability in tab navigators at least.
the developer must check both My suggestion The developer doing navigate to Tab Navigator:
the library should pass only the corresponding params to each Tab in the |
I need to pass same "userId" param to all Tabs inside Tab.Navigator I found following solution/workaround. Hope it helps somebody.
Navigation params pass from root stack-navigator to all Tabs |
@brentvatne getParam is undefined |
thank you so much for this. I was trying to solve this problem from last 2 days luckily i reached here |
getParentParam
or something?Related issues:
The text was updated successfully, but these errors were encountered: