Do I have to import my Router everywhere? about ex-navigation

[msageryd]

Thanks.
I have actually done as in the example. But I still have to import the router to each and every screen which needs it for navigation. I'd rather inject the router into every screen than having to require it everywhere.

It turned out that it already was injected. So, now I'm wondering if it would be a bad idea to use _props.navigation.router instead of having to import the router?

[brentvatne]

Hiya folks,

@satya164 and I discussed this today and it seemed like there is no harm in supporting an API that lets you push / replace routes without importing the router as it is fairly trivial to implement. You can try this out in 1.5.29 (d51ce4d)

Either of these work now:

this.props.navigator.push(AppRouter.getRoute('another', { text: 'Some dynamic text!' }));

this.props.navigator.push('another', { text: 'Some dynamic text!' });

The only downside of using the approach without AppRouter.getRoute right now is that I wasn't sure how to implement typechecking on the route param, so you'll lose out on that. If someone knows how to make it compatible with this approach too, that would be great :)

@MichaelSWE - does this solve your issue?

[msageryd]

I found the router in props.navigation._router. But since I haven't found any documentation stating that I should use it I hesitate. Is this a safe way of getting the router?

gotoProfilePage = () => {
  this.props.navigator.push(
    this.props.navigation._router.getRoute('profile')
  );
}

[chirag04]

you can put all your routes in one file and require that file to get your routes.

gotoProfilePage = () => {
  this.props.navigator.push(router.getRoute('profile'));
}

Refer this example:
https://github.com/exponentjs/rnplay/blob/master/navigation/Router.js

[steida]

I think app specific stuff like routing belongs to the context.

[msageryd]

I'm sorry, I don't quite follow you. What do you mean by app specific? Are there apps without navigation? All apps needs routing as far as I know. And the _route object is already "injected" via the props.navigation object.

Should I use the injected _route or should I import my Route everywhere?

[plougsgaard]

I won't claim it's best practise or anything, but I just import my router wherever it's needed. I can see why it might feel wrong - but really, it's fine. Hopefully there'll be bigger problems to solve! 😄

[msageryd]

Great!
Exactly what I thought earlier today. Seems odd to be forced to make two calls when props.navigator knows everything needed to consolidate to one call, but I didn't dare suggesting it because of the silence from @brent in this matter :)

Why the need for type checking? It seems that spelling the route wrongly would be a much likelier error. To solve this, one would need to setup constants for all route strings. This would clear any potential type error as well.

Would it be a bad idea to let the users be able to register their route constants with the navigator as well. This way we wouldn't even need to import our constants module.

I.e.

this.props.navigator.push(this.props.navigator.routeconsts.ANOTHER, { text: 'Some dynamic text!' });

[brentvatne]

Why the need for type checking? It seems that spelling the route wrongly would be a much likelier error. To solve this, one would need to setup constants for all route strings. This would clear any potential type error as well.

Sorry that's what I meant by it -- it can't validate that you spell the route name correctly with this style.

Would it be a bad idea to let the users be able to register their route constants with the navigator as well. This way we wouldn't even need to import our constants module.

Hmmm I don't see what the win is from doing this

[msageryd]

Aha, ok. I didn't realize that you checked the strings. What will happen if I misspell a route with the new approach?

The win would be one less import (my constants). But I haven't actually put my routes in constants yet, so it's not a problem for now.

[brentvatne]

Aha, ok. I didn't realize that you checked the strings. What will happen if I misspell a route with the new approach?

You won't be warned by flow, you'd just get a runtime error when you try to push it.

The win would be one less import (my constants). But I haven't actually put my routes in constants yet, so it's not a problem for now.

I personally would not put them in constants, I don't think that helps to make it any more readable or maintainable. You could just use whatever constant name as a string and accomplish the same thing :) 'ANOTHER' instead of Constants.ANOTHER

[msageryd]

Aha, again. I didn't know that Flow could do such cool checks.

I know too little about Flow, I guess. Why doesn't the check work with the new approach? The only difference is that ExNavigationStack.push makes the call to getRoute() instead of me doing it explicitly. How can this break the Flow checking?

[msageryd]

I see now. I suppose routeName: $Keys<RC> does not work when different types are allowed as params. I'm sorry, cannot help with this. I would gladly accept a breaking change (getting rid of the getRoute-call). But I understand that many would be upset.

[brentvatne]

@MichaelSWE - @skevy can look at making that work later if you want to create another issue. I think this one is solved though!