This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-30
Channels
- # announcements (8)
- # babashka (102)
- # beginners (312)
- # calva (9)
- # clj-kondo (9)
- # cljfx (7)
- # clojure (128)
- # clojure-europe (52)
- # clojure-nl (2)
- # clojure-norway (2)
- # clojure-spec (5)
- # clojure-uk (4)
- # clojurescript (13)
- # conjure (5)
- # cursive (5)
- # datalog (18)
- # datomic (8)
- # emacs (1)
- # events (3)
- # fulcro (16)
- # graphql (2)
- # gratitude (1)
- # helix (16)
- # inf-clojure (17)
- # introduce-yourself (9)
- # java (11)
- # lambdaisland (3)
- # leiningen (3)
- # lsp (8)
- # malli (3)
- # membrane (7)
- # missionary (26)
- # nextjournal (1)
- # off-topic (19)
- # pathom (3)
- # polylith (13)
- # portal (16)
- # reagent (39)
- # reitit (2)
- # releases (23)
- # remote-jobs (1)
- # shadow-cljs (40)
- # specter (3)
- # sql (12)
- # tools-deps (8)
- # tree-sitter (1)
- # vim (3)
- # web-security (6)
- # xtdb (16)
In my Pathom 3 app, I have a resolver that reads and interprets an edn data file. Within that data file are pathom queries that should be resolved under the context of the loading resolver as part of its interpret operation. So, I reuse the resolver's env
when executing the data file's pathom queries. Are there any performance or functional implications of reusing the env
this way? The only (very minor) side affect of this approach is that the Pathom Visualizer sees the data file queries as separate queries.
its fine to use env in this way, one thing to keep in mind is that the env from inside a resolver will already contains some caches (both standard and internal ones) that you may want to elide when doing the next call, you can use the helper (pcp/reset-env env)
to get a hold of a clean version (in terms of caches and processing things) of the env