Pattern with 2+ options where path is discarded

[jchavarri]

Pattern with 2+ options where path is discarded

[anuragsoni]

Oh nice! I didn't realize the /~ operator

This is currently not available in any published version though, but if you pin to f4a7fc9 (this also includes ksprintf which can be nice at times) you should be able to use it :)

[jchavarri]

I might not use bucklescript myself, but I wouldn't want to make any change in routes that breaks that usecase so i'd like to avoid ppxes unless absolutely needed :)

Awesome. Fwiw, at Ahrefs we are using routes in backend / OCaml, and for now just "compiling" in frontend / BuckleScript, but we might start leveraging pretty printing and other features soon :)

[anuragsoni]

Hmm, I think what would've helped here is an operator like skip_left / *> that'd allow you to define a pattern and still express that you'd like to skip the entry after a successful parse. Unfortunately there isn't a nicer way to write this in the current state of the library. I can see some ways forward that might help:

• Add support for something that allows you to express that you don't care about the trailing slash, so one can write a route that matches both
• Make the prefix addition a little nicer than what you can achieve today.
• Explore supporting a skip option in the api *>. (alternation could be nice too maybe, s "foo" <|> s "bar", etc). I'd only hesitate if this leads to an api that ends up being too flexible and starts to impact perf while matching.

With the current api, if your prefixes are limited you can do something like:

  let make_routes r = [ s "foo" /~ r; s "bar" /~ r ]

  let paths =
    List.concat
      [ make_routes empty
      ; make_routes (s "baz" /? nil)
      ; make_routes (s "baz" //? nil)
      ; make_routes (s "qux" /? nil)
      ; make_routes (s "qux" //? nil)
      ]
  ;;

This isn't that much nicer, but probably looks a little better than the first option you tried. I haven't looked at ppxes yet, but i wonder if we can provide a nicer more concise api with a ppx based solution that will take a more concise definition and generate the verbose list of routes needed for the library? 🤔 I'll need to learn how to write ppxes before I can see if that works well for routes :D

[jchavarri]

Oh nice! I didn't realize the /~ operator, that's exactly what I needed: a way to compose paths together, thanks! I think this solves this use case perfectly.

There's still the "don't care about trailing slash" part, but that was already part of the convo in #125 already. I am going to close the issue but feel free to reopen of course :)

---

Re: ppx, I would advice to consider really well if it is needed. A ppx will add significant maintenance costs (and probably add costs as well for users to get the lib configured). Plus, there's 2x costs in routes case due to double publication: BuckleScript / ReScript has some resistance to provide happy paths for ppx integration. Wdyt?

[anuragsoni]

Re: ppx, I would advice to consider really well if it is needed. A ppx will add significant maintenance costs (and probably add costs as well for users to get the lib configured). Plus, there's 2x costs in routes case due to double publication: BuckleScript / ReScript has some resistance to provide happy paths for ppx integration. Wdyt?

That has been my feeling too. I'd really like to avoid adding a ppx if I can provide a nicer api without it. And for the most part i've been able to get by with functions as helpers. I might not use bucklescript myself, but I wouldn't want to make any change in routes that breaks that usecase so i'd like to avoid ppxes unless absolutely needed :)