This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-13
Channels
- # announcements (1)
- # babashka (41)
- # beginners (194)
- # calva (14)
- # chlorine-clover (2)
- # cider (32)
- # circleci (9)
- # cljsrn (10)
- # clojure (110)
- # clojure-australia (1)
- # clojure-berlin (2)
- # clojure-dev (39)
- # clojure-europe (42)
- # clojure-france (3)
- # clojure-nl (19)
- # clojure-spec (22)
- # clojure-uk (23)
- # clojurescript (21)
- # conjure (41)
- # datomic (33)
- # depstar (16)
- # duct (46)
- # events (1)
- # fulcro (17)
- # graphql (14)
- # jobs (6)
- # jobs-discuss (9)
- # leiningen (6)
- # malli (29)
- # off-topic (21)
- # pathom (7)
- # portal (1)
- # rdf (81)
- # re-frame (3)
- # reagent (12)
- # reitit (2)
- # remote-jobs (1)
- # rum (1)
- # shadow-cljs (60)
- # specter (1)
- # sql (13)
- # tools-deps (23)
- # vrac (1)
- # yada (19)
`[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 @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]}
(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)})
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