Fork me on GitHub

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


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


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


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


so you can't have that open


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.


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


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


@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


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


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


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