Fork me on GitHub
#fulcro
<
2019-07-16
>
cjmurphy02:07:40

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?

tony.kay03:07:18

@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

cjmurphy03:07:33

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...

tony.kay03:07:06

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

tony.kay03:07:31

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

tony.kay03:07:48

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

cjmurphy03:07:36

Thanks - I'll try the standard way. Looks like what I want to follow is in the docs at: http://book.fulcrologic.com/fulcro3/#_example_securing_a_normal_remote

cjmurphy05:07:12

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.

tony.kay05:07:15

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

tony.kay05:07:28

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

tony.kay05:07:33

:bank-line/id

tony.kay05:07:38

so that’s where the ast will have params

tony.kay05:07:53

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.

cjmurphy05:07:06

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

tony.kay05:07:56

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

tony.kay05:07:19

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

wilkerlucio14:07:53

@cjmurphy params are just for docs as tony pointed out, just make sure you are not hitting this case: https://github.com/wilkerlucio/pathom/issues/93

tony.kay15:07:55

@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}]}]}

tony.kay15:07:09

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

tony.kay15:07:55

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

wilkerlucio16:07:33

@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

wilkerlucio16:07:18

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?

tony.kay16:07:29

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

wilkerlucio18:07:46

@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