Clojurians Log v2

Yeah, make sense; an authentication error could be considered the same class of problems as an arbitrary error thrown by a resolver. This can then be post-processed in multiple ways (show all errors, silently drop, etc). I guess the only wrinkle is you can't return a partial result (e.g. some connect attributes are OK, others forbidden), so you need separate resolvers for attributes that may be forbidden. That's probably not a bad trade-off to avoid complicating the code paths. 🙂 Thanks!

I think this is something interesting to consider about error handling in pathom 3, in the current only the last error remains, but I think could be more interesting to see all that happened, not just the last error

`[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

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 @wilkerlucio 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]}
  (go
    {:resource/db-item 
     (<! (db-get uuid))}))

(pc/defresolver sync-resolver
  [{:resource/keys [db-item]}]
  {:resource/foo (:foo db-item)
   :resource/bar (:bar db-item)})

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