Clojurians Log v2

Another question, is it common/encouraged to have system only resolvers? I have some system states that I’m thinking could be easier to debug/dev if they were represented with resolvers but then i’d need to prevent clients from requesting them directly. One idea i’m running through is having a resolver that returns the database model and then downstream resolvers could take the database model and convert to the application model

I have resolvers that returns db schema, jvm startup data and I'm working//planning resolvers that returns my #pedestal routes and many more (use pathom as a "startup/component" system) For my API, I just filter some keys

thanks! ya it seems like fully embracing pathom is very powerful

It's hard to code without pathom after use it for a while

you can do with a custom ::p/process-error:

(def mutation-parser
  (p/parser
    {::p/env     {::p/reader               [p/map-reader
                                            pc/reader2
                                            pc/open-ident-reader
                                            p/env-placeholder-reader]
                  ::p/placeholder-prefixes #{">"}
                  ::p/process-error        (fn [env err]
                                             (if (= :call (-> env :ast :type))
                                               (p/add-error (-> env
                                                                (update ::p/path p.misc/vconj (-> env :ast :key))
                                                                (dissoc ::p/process-error)) err))
                                             (p/error-message err))}
     ::p/mutate  pc/mutate
     ::p/plugins [(pc/connect-plugin {::pc/register mutation-error})
                  p/error-handler-plugin
                  p/request-cache-plugin
                  p/trace-plugin]}))

with pathom3, what’s the correct way to set data (like a db connection) on env context?

ah I see that smart maps and eql process both take initial data

was trying to use the built-in resolvers at first 😅

@wilkerlucio seems like initial data is not passed to data map argument that mutations take? For arity two, inspecting env context I do see the initial data, but not sure which way I’m supposed to be accessing it.

when create Smart Maps or EQL trigger, the first argument is the env, you should set the db connection there, same for mutations

like: (psm/smart-map (assoc env ::my-db ...) {:my.customer/id "123"})

makes sense?

so pathom-indexes/register creates an env (not just indexes), and we can assoc additional env values into it before calling smart-map or eql process

i’m trying this

(pathom-eql/process
   (assoc indexes
          ::ctx/conn (dc/conn))
   eql))

there are two maps, the env and params

hm i guess i have to use arity two to access it

to use env you need to declare the mutation with both

^ yeah, i thought since everything was namespaced it’d be in one map

(pco/defmutation mmmm [env params])

nope, two different contexts of information

parts of Pathom Viz integrated in Reveal

This is awesome!! :star-struck::star-struck::star-struck: