Fork me on GitHub
#reitit
<
2022-01-17
>
simongray10:01:01

So :query returns the same thing as :query-params ? I wonder if this a bug or intentional? From printing the reitit frontend navigate data:

#reitit.core.Match{:template "{*path}", :data {:name :delegate}, :result nil, :path-params {:path "/dannet/2022/search"}, :path "/dannet/2022/search", :query-params {:lemma "bygning"}, :parameters {:path {:path "/dannet/2022/search"}, :query {:lemma "bygning"}}}

Ben Sless11:01:48

You should be using the parameters map, query params are considered "raw" afaik

Ben Sless11:01:13

For cases where you have coercion, etc, it's all under parameters

Ben Sless11:01:45

The docs could be clearer

dharrigan11:01:02

Indeed, I believe :params is from ring/wrap-params if that is in the middleware stack somewhere.

dharrigan11:01:10

:parameters is the way to go 🙂

dharrigan11:01:29

(provided, as Ben says, they have been coerced)

Ben Sless11:01:31

Even sans coercion, I think

dharrigan11:01:58

Indeed, 'although they'll be raw, yes?

Ben Sless11:01:50

Yes, but that is equivalent to any other query params map. Why go there anyway? Regularity

simongray11:01:45

that still leaves me without a query string… it seems that some information is lost doesn’t it?

Ben Sless11:01:11

Oh! you mean you want the original query string that was sent?

Ben Sless11:01:34

Technically, the translation to query-params should be lossless

dharrigan11:01:42

It is there, in the request, should be easy enough to concat together, i.e.,

dharrigan11:01:53

:query-string "id=10",
 :remote-addr "127.0.0.1",
 :request-method :get,
 :scheme :http,
 :server-name "localhost",
 :server-port 8080,
 :ssl-client-cert nil,
 :uri "/api/query",
 :muuntaja/request nil,

dharrigan11:01:05

there is a :query-string and the :uri

dharrigan11:01:27

:query-string "id=10&foo=bar",

dharrigan11:01:45

http :8080/api/query?id=10\&foo=bar

simongray11:01:50

Sure I can concat it together, but why should I? The map has been parsed from the query string, not the other way around.

simongray11:01:21

That just makes me do more work, when I just want to be able to access what was already there from the beginning.

dharrigan11:01:57

Well, I can't answer that one for you.

simongray11:01:28

Just seems silly to me that information is removed

simongray11:01:45

Ring and Pedestal don’t do this, just reitit

simongray11:01:14

So if I want to delegate a request from reitit’s frontend router to my backend I have to reconstruct the URL it from all of the parts rather than just pass it on. It’s more work and more error-prone.

simongray11:01:54

Maybe my use case is just not what reitit wants to be. I only have

(def routes
  [["{*path}" :delegate]])
and then I simply translate this to backend requests in my on-navigate fn

simongray10:01:17

The the query string is ?lemma=bygning

simongray10:01:25

(sorry it this is a bit bitchy, but I just tracked down an annoying bug to reitit and I was surprised to find that there is no difference between :query and :query-params)

iGEL11:01:33

Hello everyone. Is it possible to constrain parameters? My frontend for example should match /users/:id/:tab, if tab is profile or security, but not if it's messages, which should rendered by the backend with a full page load for the moment. e.g.: /users/1/profile => rendered by the SPA /users/1/security => rendered by the SPA /users/1/messages => rendered by the backend

rovanion17:01:47

Is it possible to have different coercions defined for :get and :post for the same path?

ikitommi17:01:20

should be, just put the :coercion under the method

rovanion18:01:25

Ah, turns out I had only been using the shorthand of "func is automatically converted to {:handler func}". Thank you!

MikeE21:01:27

hi all - i’m pretty new to reitit (and clojure for that matter) and am trying to understand how to structure the data for a response that returns a map with a list of entities inside it. in this case “users” - my route is setup like this

["/users"
    {:get {:summary    "Get list of users for authorized caller"
           :parameters {}
           :responses   {200
                        {:body domain/user-shape}}
           :middleware [[collectivly-middleware/wrap-jwt]]
           :handler    handler/users-handler}
...SNIP....
and my user-shape is setup as data here
(def user-shape
  {:id         pos-int?
   :first_name string?
   :last_name  string?
   :image_url  string?
   :created_at inst?
   :updated_at inst?
   :user_xid.  string?})
when using this approach for the /users/:id route and setting the body response to be domain/user-shape it works as expected. I’m not sure what the syntax is to represent this output for the responses field.. ultimately the JSON response is:
{
   users: [
      { "id": 1, "first_name": "mike",  .... },
      { "id": 2, "first_name": "joe", ....}
   ]
}

wegi09:01:15

It seems to me that your data returned is a collection of users, but your route expects to receive only a user. So it needs to be a coll-of user-shape instead of the shape directly.

MikeE15:01:15

thanks wegi yes - I tried coll-of but couldn’t figure out the syntax

MikeE21:01:20

for the /users GET route I’m getting a spec error

"spec": "(spec-tools.core/spec {:spec (clojure.spec.alpha/keys :req-un [:spec$40768/id :spec$40768/first_name :spec$40768/last_name :spec$40768/image_url :spec$40768/created_at :spec$40768/updated_at :spec$40768/user_xid]), :type :map, :leaf? false})",
    "problems": [
        {
            "path": [],
            "pred": "clojure.core/map?",