Clojurians Log v2

hey I was just going over the pathom3 docs and noticed that env is quite often missing from the examples. I don't think its actually optional right? https://pathom3.wsscode.com/docs/resolvers

@thheller it looks like a multi-arity function in pathom3; with one arg, env is {} ; with zero args both env and input default to {}

@thheller @pithyless this is also ported on latest versions of pathom 2, the multi arity thing for defresolver

@wilkerlucio I know it's rude to ask for ETAs, but are mutations for pathom3 on the roadmap short-term or long-term? If it's not planned for the short-term, I may just try playing with a hybrid approach (trying out P3 resolvers and smart-maps and P2 mutations).

@pithyless why move into p3? I'm using p2 with all new features backported from p3 p3 still miss things like placeholders, which it my main "blocking" feature

I'm interested in some of the new user APIs; like the smart-maps interface and lack of explicit parsers. And I'd like to see if I can re-use some of the graph introspection logic for a slightly different use-case (which probably would be easier to base off of the new internals). But didn't know about placeholders; I guess that's enough reason to keep using p2 for existing code and only use p3 for the more experimental stuff. Thanks for the heads up!

(let [parser (p/parser {::p/plugins [(pc/connect-plugin)
                                     p/error-handler-plugin
                                     p/elide-special-outputs-plugin]
                        ::p/env     {::p/reader               [p/map-reader
                                                               pc/reader2
                                                               pc/open-ident-reader
                                                               p/env-placeholder-reader]
                                     ::p/placeholder-prefixes #{">"}}})
      process (fn [index tx]
                (parser (assoc index
                          ::pc/indexes index)
                        tx))
      index-a-42 (pc/register {} (pc/constantly-resolver :a 42))
      index-dyn-a (pc/register {} (pc/resolver 'a {::pc/output [:a]}
                                               (fn [{:keys [a]} _]
                                                 {:a a})))]
  {"from ctx" (process (assoc index-dyn-a
                         :a 55)
                       [:a])
   "static"   (process index-a-42
                       [:a])})
=> {"from ctx" {:a 55}, "static" {:a 42}}

hello, no worries, my rough estimation is to have something that I consider “featured enough” to use by the end of this year, and by this I mean reads, mutations, placeholders, batching, telemetry and tooling. prioritization is always tricky, so I may push async later to have something sync funcional first

Thanks for the clarification; looking forward to the improvements in P3! PS. @wilkerlucio Kudos for all the effort you're putting into EQL with you're writing/tech talks/podcasts/etc; it's important long-term work to get more people thinking critically about graphs and data-modeling.