Add end' combinator to support trailing slashes

[paulyoung]

As discussed on Slack. I figured it was a pretty common use case.

[paulyoung]

I originally put made Qux nullary and put it at the bottom but quickcheck was sometimes generating "qux" which would cause the tests to fail.

I know the order doesn't matter here but it does when using sum, and I thought it was best to keep them the same.

[paulyoung]

I'm proposing end' instead of index since it's kind of like end/

[paulyoung]

This should be “foo”

[paulyoung]

I don’t think this actually tests that end’ behaves as expected with trailing slashes but I’m not sure how to test that either current setup.

I could write some manual test cases (e.g. //, ///, /foo, /foo/, /foo//, /foo///) but quickcheck might do a better job.

[natefaubion]

Something to also consider is if you want to canonicalize to no trailing slash, you could use existing combinators with a pre-processing step which trims empty segments (via parsePath and runRouteParser).

purescript-routing-duplex/src/Routing/Duplex/Parser.purs

Lines 142 to 185 in a03a30e

	runRouteParser :: forall a. RouteState -> RouteParser a -> RouteResult a
	runRouteParser = go
	where
	go state = case _ of
	Alt xs -> foldl (goAlt state) (Fail EndOfPath) xs
	Chomp f -> f state
	Prefix pre p ->
	case chompPrefix pre state of
	Fail err -> Fail err
	Success state' _ -> go state' p
	goAlt state (Fail _) p = runRouteParser state p
	goAlt _ res _ = res
	parsePath :: String -> RouteState
	parsePath =
	splitAt (flip Tuple "") "#"
	>>> lmap splitPath
	>>> toRouteState
	where
	splitPath =
	splitAt (flip Tuple "") "?"
	>>> bimap splitSegments splitParams
	splitSegments = splitNonEmpty (Pattern "/") >>> case _ of
	["", ""] -> [""]
	xs -> map unsafeDecodeURIComponent xs
	splitParams =
	splitNonEmpty (Pattern "&") >>> map splitKeyValue
	splitKeyValue =
	splitAt (flip Tuple "") "=" >>> bimap unsafeDecodeURIComponent unsafeDecodeURIComponent
	splitNonEmpty _ "" = []
	splitNonEmpty p s = split p s
	toRouteState (Tuple (Tuple segments params) h) =
	{ segments, params, hash: h }
	splitAt k p str =
	case String.indexOf (Pattern p) str of
	Just ix -> Tuple (String.take ix str) (String.drop (ix + String.length p) str)
	Nothing -> k str

[paulyoung]

It’s not clear to me how to do that, unless you’re suggesting changing the implementation of those functions.

[natefaubion]

Parsing is just the composition of these two functions

purescript-routing-duplex/src/Routing/Duplex/Parser.purs

Lines 187 to 190 in a03a30e

	run :: forall a. RouteParser a -> String -> Either RouteError a
	run p = parsePath >>> flip runRouteParser p >>> case _ of
	Fail err -> Left err
	Success _ res -> Right res

I'm saying that it's possible to define your own version of this that just inserts a normalization step between the two, removing trailing ""s from the RouteState.

[natefaubion]

After thinking about this some more, I think that a preprocessing/normalization stage is the better approach. That is, I think that the combinators provided by the library should be bidirectional, and I don't really like the idea of exposing a combinator with a clear bias. Enough guts are exposed that it's very easy to implement your own bias if that's what you want. I would think that whether or not to accept a trailing slash is something you'd want to do across the board though, which benefits from a preprocessing step, and is something we could make easily configurable. Some options could be whether to remove duplicate slashes, or whether to add/remove trailing/leading slashes. Is this something you'd be interested in doing? Do you have a strong use case for ad-hoc slash handling?

[paulyoung]

I don't have a use case for ad-hoc slash handling, and would be interested in working on preprocessing/normalization although I'm not sure when I'd get around to it.