pathom 2023-11-13 | Slack Archive

In my fulcro application, I had a helper to call the pathom2 parser from inside a resolver. It looked like this:

(fn [{:keys [parser] :as env} context query ]
   (let (-> (parser env `[{(~eid {:pathom/context ~(into {} others)})
                           ~query}])
                    (get eid))

basically, grabbing the parser from the env, and calling it with a context and query I'm trying to migrate to pathom3, and cant seem to figure out the right way to do this in this world. I tried something like:

(fn [{:keys [parser] :as env} context query]
   (parser env context query)))

strangely, this returns an empty map in my resolver, but if i tap> the parser, env, and context and run the query outside of the resolver it works fine? maybe some weird cache issue? Is there a way i can make my parser-in-resolver fn compatible with pathom3 / a bettery way to call the pathom3 process fn from within a resolver?

wilkerlucio12:11:02

hello Tyler, in Pathom 3 there is no parser, but you can trigger a new call using p.eql/process from inside your resolver, like: (fn [env input] (p.eql/process env {} [:query]))

Tyler Nisonoff16:11:11

Thanks wilker! I tried that as well, but for some reason, It fails to resolve in certain scenarios. I think it must have something to do with the fulcro datomic integration? If i have a "design" entity, with an attribute :design/named: thats auto-resolved by fulcro's RAD pathom integration, and :design/type that has a hand-built resolver,

[{[:design/id  #uuid "ffffffff-ffff-ffff-ffff-000000000607"] [:design/name :design/type]}]

will return the right data But

[{[:design/id  #uuid "ffffffff-ffff-ffff-ffff-000000000607"] [:design/type]}]

fails to resolve type :thinking_face: Thought maybe it was something i was doing wrong in terms of calling process, but maybe i have to look elsewhere

wilkerlucio23:11:14

humm, this might be a bug, can you make a repro setup that demonstrastes this behavior?

Tyler Nisonoff23:11:48

will try to get one going! I was able to fix the bug by filtering out pathom-related keys (minus the resolver-cache*) from the env before calling back to my processor that rebuilds the env with the appropriate plugins and what-not, but would be nice to get a cleaner solution

wilkerlucio23:11:52

there is something you can try: use the (pcp/reset-env env) helper before doing the nested call

wilkerlucio23:11:19

this will restore the original env, but keep in mind that in case of mutable things (mostly caches), they will retain the current state

Tyler Nisonoff23:11:58

ooh nice, so that'll reset most things but the cache will stay in tact?

Tyler Nisonoff23:11:02

will try that

wilkerlucio23:11:49

yes, pathom stores the original env map at the beginning of the process, this fn reads it back

Tyler Nisonoff23:11:57

will try that tonight and report back! thanks for the help

Tyler Nisonoff17:11:07

sadly reset-env didnt work, but that helps narrow down where the issue is

Tyler Nisonoff17:11:22

going to try to create a minimal repro

🙏 1

2023-11-13

Channels