Fork me on GitHub

`[com.wsscode.pathom "2.3.0-alpha14"]` [com.wsscode.pathom "2.3.0-alpha15"] is out! Change to validate the options part of defresolver, so inputs, outputs, params, etc... will get validated at macro time now. Thanks to @souenzzo for helping me with testing and debugging the porting (and suggested the options keys validation)! edit: @souenzzo found a validation bug, please upgrade to alpha15 in case you are on 14

❤️ 12

do implicit inputs/outputs work for resolvers that return core async channels? Edit: Looks like it doesn’t; I’ll dig a little deeper to see what’s going on


inputs yes, outputs no, its important to take this message with care "only works when the last form of the defresolver body is a map", if you have (let [...] {:map 3}), the last form is a let, not a map, and wont work, implicit outputs are meant for only trivial output cases, the async problem is the same as let, the map is not the last form


it may support a bit more in the future, like let, but I'm holding on it, because in other cases like cond, if, etc... the answer is not as simple


Thanks @U066U8JQJ that makes sense to me!


I’m thinking of having an async resolver that just returns a top-level key another resolver that takes that as input and can fully utilize implicit outputs. Something like:

(pc/defresolver async-resolver
  [{:keys [db-get]}
   {:resource/keys [uuid]}]
  {::pc/outputs [:resource/db-item]}
     (<! (db-get uuid))}))

(pc/defresolver sync-resolver
  [{:resource/keys [db-item]}]
  {:resource/foo (:foo db-item)
   :resource/bar (:bar db-item)})
Is there some better way to chain these together?


I suggest don't going further just to avoid writing the output, think more like this: if I can get implicit outputs, great, but if not, write by hand, it doens't worth optimize for it

👍 6