Fork me on GitHub

Before Pathom was around, when doing df/load, one of the options you could set was :params. Not sure the equivalent with Pathom as the way I've got it set up it is a :parser (in one of the wrap-api keys), and as such only receives queries. I know that queries can have parameters, but then df/load! constructs your query for you from a component's query. How should I get a parameter across to Pathom so that it is injected into the graph, as if there was a global resolver for the value of the keyword I want to send across?


@cjmurphy (-> env :ast :params) should have the params from load!. The top-level key that starts the query will be where the params appear. E.g. (load! :x ... {:params ...}) will have params in the resolver for :x


The way I've setup the middleware, there's only one thing that can be in the Pathom parser's env, and that's a thing called db-q. Looks like I need to read the docs to set up Pathom so it is more integrated with Fulcro...


Yeah, my setup usually uses server/handle-api-request, with pathom as the parser


by assuming you’re passing the query through unmodified, it should just work


the params are part of EQL [(:prop {:param 1})]


Thanks - I'll try the standard way. Looks like what I want to follow is in the docs at:


The wrap-api in the above code is from com.fulcrologic.fulcro.server.api-middleware, so is already calling handle-api-request. But I did notice that the params passed were appearing in the query. So for the call on the client of (df/load! @mount/app [:bank-line/id 1] ui/Unmatched {:params {:customer/kw root/our-customer}}), the params appear in the query at (-> query first second). So for now I'm putting that in the Pathom parser's env.


actually, wrap-api is fine, that’s what I meant


pathom should be passing the ast node of each query element to its resolver, but the params are only attached to the ident-based one in this case




so that’s where the ast will have params


but yes, if you want them to just be in env as a constant you could pull them out at the top level and put them in env yourself.


Might need ::pc/params [] on the resolver not to be empty so they are included...


as far as I know, that’s for autocomplete/documentation only…it doesn’t prune the query


you can also throw an atom into env, and update it along the way


@cjmurphy params are just for docs as tony pointed out, just make sure you are not hitting this case:


@wilkerlucio I’ve read the issue, and I don’t understand why the params don’t show in the resolver. You allow for :pathom/context param, but there is no place else for it to show up:

(eql/query->ast `[({([:person/id 1] {:n 1}) [:username]} {:n 1})])
{:type :root,
 :children [{:type :join,
             :dispatch-key :person/id,
             :key [:person/id 1],
             :params {:n 1},
             :query [:username],
             :children [{:type :prop, :dispatch-key :username, :key :username}]}]}


the join node in the AST is all you’ve got


is that just an oversight in pathom ident reader, and if so, why not add that to the reader as a default behavior?


@tony.kay the problem is the place were the params are been sent, in this example, the params are sent to the ident query [:person/id 1], if you look for params while processing it (which is the ident-reader) you will get the params, but a resolver will run against :username, which doesn't have any params


that's why @fatihict end up using load-field, because then the param goes in the field itself instead of the ident join, makes sense?


Ah, I thought you were saying the ident resolver would not see the params


@tony.kay to clarify, there are no resolvers involved in ident processing, it just forwards that ident as a part of the data for the inner context, to get the params in the previous example you have to have a custom reader for instead of the default pc/open-ident-reader