I was looking at compojure again recently and found that, when defining a handler, it's possible to give a reference to a function rather than making a call. For example: (`GET "/things" req all-things)` (where all-things is a function that takes a request and returns a response)
What's interesting is that I can't seem to find this feature documented anywhere. All the documentation tends to steer me toward destructuring and putting the body of the handler inline:
(GET "/things/:id" [id] (find-thing id))
It doesn't seem an "accident" that the function works, as the Renderable protocol is extended to functions to make them work exactly this way.
What I'm wondering is, given there's really no documentation about it, is writing a handler this way unidiomatic? And if so, what's the Renderable support for functions for? Are there other use cases where one might write a handler that returns a handler?
Workplaces in the past have used it heavily, usually as var quote
Interesting. I would have thought that a big chunk of the value proposition of compojure was the destructuring and coercion of params. You miss out on all that if you just use a function, since it can only take a single arg (the request)
often you don't want to entangle routing and more complicated handlers
Isn't that a point in favour of leveraging compojure's destructuring and coercion? Then you can write handlers that take exactly what they need as input and produce the response they want to produce. Or are you suggesting it's often cleaner to "own" the entire req->res mapping, picking out the relevant pieces of the req in that function, and letting routing just be routing: find a match, pass the req along?
I'm with @hiredman here. I like the uniformity of handlers taking the request map. In addition, I think that mixing the argument destructuring and coercion with routes is just too much complecting.