A common type for navigate and format?

[stroborobo]

Hey Zaid,

with the new format function I'd need to map my Route type twice to get a navigateTo and a toPath function. What do you think about a common type like Segments that contains the string list you're creating, so navigate and format could take the segments and the lib's users only need to map their Route to segments once?

Have a great day!

[Zaid-Ajaj]

Hello Björn, surely a Segments type can be added but it won't just have string list, because it would also need to contain the query string parameters and history mode. Moreover, you get different ways of doing the same thing which I want to avoid in this simple library. Isn't it easier for you to use a string array as a common type? Since both Router.format and Router.navigate can take it as input

[stroborobo]

Problem would be that I can't access the encodeQueryString* functions from the outside though, so I cant really do it myself without reimplementing those. Btw, I don't think it would need to contain the history mode, since it's only needed when navigating, not for format.

I understand that you want to keep the possible pathways to a minimum, but users would need to map their route twice, once to navigate and once to format, if they want both links and programmatic navigation. So wouldn't this just move the extra pathways to the user's code?

[Zaid-Ajaj]

So wouldn't this just move the extra pathways to the user's code?

It is not about path ways, it is more about the user having to choose which way to go: use direct route parameters in the navigate or format functions or use this Segments type.

If you want to avoid the duplication of toPath and navigate to, isn't it possible to use the output of Router.format as input for Router.navigate? i.e.

let toPath (route: Route) : string = Router.format(...)
let navigateTo (route: Route) = Router.navigate(toPath route)

[stroborobo]

Oh that does work, sorry m( Thanks a lot!

[Zaid-Ajaj]

No worries :smile: