This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-12
Channels
- # aleph (8)
- # announcements (9)
- # babashka (15)
- # beginners (91)
- # calva (54)
- # chlorine-clover (3)
- # cider (25)
- # clj-kondo (9)
- # cljfx (4)
- # cljsrn (12)
- # clojure (40)
- # clojure-australia (2)
- # clojure-europe (77)
- # clojure-nl (10)
- # clojure-spec (22)
- # clojure-uk (9)
- # clojurescript (39)
- # conjure (12)
- # cursive (8)
- # datascript (17)
- # datomic (22)
- # emacs (2)
- # expound (6)
- # fulcro (25)
- # kaocha (7)
- # malli (9)
- # meander (5)
- # off-topic (13)
- # pathom (8)
- # pedestal (5)
- # portal (1)
- # rdf (58)
- # re-frame (65)
- # reagent (15)
- # sci (3)
- # shadow-cljs (50)
- # test-check (6)
- # testing (3)
- # tools-deps (1)
- # vim (7)
- # xtdb (10)
Is there some way of passing additional data with ::p/continue
? I'd like to have several resolvers with different authentication strategies try to resolve the same attribute (and ::p/continue
if they fail); and ideally I'd like to differentiate between ::p/not-found
and ::auth/forbidden
if they all fail. If this is currently not feasible, is this a use-case that can be considered for the upcoming new reader?
maybe using error instead of continue, similar to "continue", an error will trigger other options, and in a post-process you can convert those errors in forbidden, makes sense?
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
hello everyone, I wrote a post about some of the updates about Pathom 3, you can find it at: https://blog.wsscode.com/pathom-updates-01/
another news, I recently released [com.wsscode.pathom "2.3.0-alpha13"]
🎉, this version ports back the defresolver
from Pathom 3 to Pathom 2, this defresolver reduces the boilerplate required on some resolvers, it can make some inputs and outputs implicit, for example:
; before alpha13
(pc/defresolver full-name [env {::keys [first-name last-name]}]
{::pc/input #{::first-name ::last-name}
::pc/output [::full-name]}
{::full-name (str first-name " " last-name)})
; after alpha13, this can reduce to
(pc/defresolver full-name [{::keys [first-name last-name]}]
{::full-name (str first-name " " last-name)})
Check the defresolver
docstring for details of the syntax.there was a bug with implicit inputs on alpha13, please update to alpha15 to fix