This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-07
Channels
- # announcements (2)
- # bangalore-clj (1)
- # beginners (88)
- # calva (1)
- # cljdoc (1)
- # cljs-dev (1)
- # cljsrn (2)
- # clojure (88)
- # clojure-berlin (2)
- # clojure-europe (2)
- # clojure-india (1)
- # clojure-spec (3)
- # clojure-uk (3)
- # clojurescript (9)
- # clojureverse-ops (4)
- # clojutre (2)
- # cursive (3)
- # data-science (1)
- # emacs (3)
- # fulcro (12)
- # pathom (4)
- # reitit (1)
- # rum (10)
- # shadow-cljs (9)
- # spacemacs (11)
- # sql (7)
- # tools-deps (16)
- # vim (14)
- # xtdb (3)
- # yada (1)
no, that's currently not supported, but its something I like to support in the future, for now what you can do to go around this is do a call to the parser from the inside of your resolver, so make the input just #{:workload/id :workflow/biz-factors}
, then inside the resolver you can run: (parser env [{:workload/biz-factors [:biz-factor/id :biz-factor/name]}])
(`parser` can be extracted from the env
)
note: if you are using the parallel parser, the return of parser
will be a channel, you need to read from it to get the result map
but depending on how is your resolver for biz-factors
, you may not need any of this, if there is only one entry for it, and you don't need something inside to be computed, you can just require the biz-factors and read from it
makes sense?