pathom 2024-06-04

Is there a middle ground between https://github.com/wilkerlucio/pathom3-datomic and defining all the resolvers explicitly, and the boilerplate of writing all the resolvers calling d/pull, writing output attribute list twice, once in the pull pattern and again as an argument to defresolver? I might have some naive assumptions going into this, but pathom3-datomic seems a little too automated for me, I don't want to expose the native datomic attribute names to the end-user, and writing a 'protected attribute layer' seems like solving a problem I created. Plus I plan to make extensive use of derived attributes, i.e.. a lot of :xform . and :as On the other hand, writing a ton of resolvers + d/pull, there will be a lot of boilerplate. I would even consider just a simple utility to can take a pull pattern , extract out the :as parts of every attr-spec, and using that to generate the output attribute list. Just thinking out loud here... looking for any prior art if any. If not i'm sure i'll find my way.

@jasonjckn you can write resolver like this:

(def user-pull
  (pull-resolver
    {:id    :user/id
     :query [:user/name
             {:user/address [:address/street]}]}))
Where pull-resolver is a function that you write that uses pco/resolver internally Another option, is simply re-use the query from env
(pco/defresolver user-pull [env {:user/keys [id]}]
  {::pco/output [:user/name
                 {:user/address [:address/street]}]}
  (d/pull (:db env)
    (-> env :current-resolver ::pco/output)
    [:user/id id]))
(i don't remember the name of the key that returns the current resolver, but I'm sure that it is NOT :current-resolver. Added just as example) In both cases, you can transform https://github.com/souenzzo/eql-datomic, use EQL libs to assoc/remove extra parameters (like :as or :xform) and etc

🙌 1