Closed aappddeevv closed 5 years ago
Agreed. We could introduce a helper function Route.parse()
which returns an intermediate representation. The pattern matching block would then look as follows:
Route.parse("/user/hello?show=false") match {
case details(a :: HNil) => // ...
// ...
}
So routes will not match on strings anymore, only on the return value of parse()
.
I'd be Ok with that.
I would like to be able to map my own "string" into it though. My router has an interface that produces a semi-parsed data structure already so as long as I can map into whatever is used that would be great. Not critical though, just trying to avoid full parses. I have ~50 routes (small app) and I'm trying to avoid that on ever route render. I know its not huge but I'm watching my renders and processing everywhere on the critical path.
On Mon, Feb 11, 2019 at 2:26 AM Tim Nieradzik notifications@github.com wrote:
Agreed. We could introduce a helper function Route.parse() which returns an intermediate representation. The pattern matching block would then look as follows:
Route.parse("/user/hello?show=false") match { case details(a :: HNil) => // ... // ... }
So routes will not match on strings anymore, only on the return value of parse().
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sparsetech/trail/issues/25#issuecomment-462237436, or mute the thread https://github.com/notifications/unsubscribe-auth/ABIOaaCdJnq_q0HxIx787cDHNuEg23Zwks5vMRspgaJpZM4azIgJ .
I have overloaded all user-facing functions with a Path
parameter. This allows you to populate the Path
case class with your own data.
Thanks will give that a try!
It looks like each unapply that is used to for a route parses the url independently of others. While I don't think this is a huge burden, if this is true, I'm claiming it would be nice to have a way to parse the url string once and then re-use that parsing in each unapply (case statement).