-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add map and path prefixing to targets #121
Conversation
Hi @Chattered , Thank you for making the proposal. The technical changes itself seem fine, but i'm curious about the usecase they intend to solve. If possible would you be able to give some examples of how your project intends to make use of these functions? I only ask because while let make_route p1 p2 = p1 / p2;;
let r1 = int / str;;
let r2 = s "foo" / s "bar";;
let r2 = make_route r2 r1 /? nil On a similar note, the change to map seems technically correct, but I'm curious about how you intend to use it? One way i reuse routes with the current api is by using thunks when defining the routes: let r () = s "sum" / int / int /? nil;;
let sum_as_int = r () @--> fun a b -> a + b;;
let sum_as_string = r () @--> fun a b ->
Printf.sprintf "Sum of %d and %d = %d" a b (a + b);; The thunk looks awkward indeed, and I think adding an operator to make working with that easier would be nice. I'm mostly saying all this just to start a discussion and I hope you don't take this as me rejecting this proposal 😄 |
Hey @anuragsoni. In our setup, we've got 400+ endpoints, each partially defined by a record which has a field for the target. We later attach handlers, and after that, we do some namespacing of the endpoints by prefixing various paths. I suppose we could replace the target field with one of type The mapping is more of an issue, just because of the way we've decomposed this application. We've got targets like My personal philosophy is that if I can see how a type constructor is a functor (in the mathematical sense), then it's worth including the Thanks for the quick feedback! |
Thanks for the insight @Chattered
I think this is enough of a justification that supporting this in the library is justified :) Thanks for providing the examples of how you use it!
This makes sense. I don't see any problem with supporting a
I'm going to merge this PR in its current state, but I'll probably spend some time in thinking about the operators to see if we can come up with something different that might be easier to read.
Thanks for sharing this. I really appreciate getting to learn about your usage pattern as this sounds bigger than most applications i've heard of that use |
Awesome! Thanks again. |
Hi again!
We're making heavy use of this library, and these additions would help us, if you think they make sense (happy to think again about the choice of "/~" as an operator name).