Fork me on GitHub
#pathom
<
2020-10-05
>
njj16:10:59

What is the typical way of setting up a resolver where you might not know all the outputs from the api response something like:

njj16:10:25

(pc/defresolver some-resolver
                [__ {:keys [resource/id]}]
                {::pc/input #{:resource/id}
                 ::pc/output [:id]}
                (let [resource (get-resource-by-id id)]
                  resource))

njj16:10:42

where I could still query other parts of the response like: `[{[:resource/id 1] [:id :name]}]`

wilkerlucio18:10:32

@njustice Pathom needs to know the output ahead of time, otherwise it can't figure the proper resolve to call an attribute

wilkerlucio18:10:37

so you can't have that open

wilkerlucio18:10:58

dynamic resolvers can be a bit more cherry picking on it, but they still need to know all possibilities ahead of time

Michael W18:10:42

You sort of can have it open, if you build a resolver by id, but have it return all data, you can then use something like filter to pull out what you need. fulcro-rad-demo does it with attributes that have a name starting with "all-". But pathom won't be able to query by any of that output unless it's in the output list.

njj18:10:33

@wilkerlucio in my example, I get back the :name w/o including it in the pc/output

njj18:10:29

I.e. `{[:resource/id 1] {:name "foo", :id 1}}`

wilkerlucio18:10:33

@njustice the problem is that this makes it a an implicit dependency, in a way its like getting it by accident. the problem is that if you don't ask for the id, you will never get :name. also, I like to discourage you from having unqualified attributes in the system (input or output) due that it will easaly collide with other things

njj18:10:16

so for any resource I have, if I want to use a field from it, I need to include it in the output

tvaughan14:10:47

Or stuff them all into a hash-map under one key. The contents of the hash-map under this key become arbitrary

wilkerlucio18:10:33

yes, you can think of it as your schema in a way