Fork me on GitHub

@wilkerlucio is it a "undefined" behavior? If there is 2 resolvers to resolve :a, one is "global", the other need a input :i The pc/reader3 will prefer "the first one", where "the first one" is "the first inserted in the index" (aka the register order matters, with I think is bad) Sample case

(let [register [(pc/resolver
                  {::pc/input  #{:user/id}
                   ::pc/output [:user/name]}
                  (fn [_ {:user/keys [id]}]
                    {:user/name (str "user-" id)}))
                  {::pc/output [:user/name]}
                  (fn [_ _]
                    {:user/name "current"}))]
      parser-1 (p/parser {::p/plugins [(pc/connect-plugin {::pc/register register})]})
      parser-2 (p/parser {::p/plugins [(pc/connect-plugin {::pc/register (reverse register)})]})
      env {::p/reader               [p/map-reader
           ::p/placeholder-prefixes #{">"}}]
  {:parser-1 (get (parser-1 env [{[:user/id 1] [:user/name]}]) 
                  [:user/id 1])
   :parser-2 (get (parser-2 env [{[:user/id 1] [:user/name]}])
                  [:user/id 1])})
=> {:parser-1 {:user/name "user-1"}, :parser-2 {:user/name "current"}}


currently reader3 doesn't have a real algorithm to pick a path, the current impl will use first, that's a current incomplete part of it

👍 4

Is it tracked? Should I open something to track it? I'm not sure if how it should behave actually


I've never used Pathom before but it seems like a natural fit for my usecases to access a bunch of data in ElasticSearch. One of usecases is to serve autocomplete in the UI. I don't see any reason NOT to use Pathom for this usecase (except, possibly, performance). Am I wrong?


@markaddleman in the end pathom is just a glue to compose information across your system, I have used pathom with ES before, don't see any reason not to 🙂


Thanks for confirming! I'm looking forward to this little project