Clojurians Log v2

I have a situation where I'm pretty sure Pathom 3 is computing the wrong path involving resolvers at different priorities. I've been playing around with the new pathom-viz plan stepper but I don't know how to interpret it well enough to understand where things are going wrong. If I dump the index here in slack along with the query, will that be enough to track down what's going wrong?

I think I understand the problem well enough to create a repro case.

hello everyone, I like to give a heads up. my computer motherboard bricked, and due to some brazil forced holidays (due to corona) its expected to take 20 days before I get it back, until then I wont be able to do any progress in Pathom or other open source related stuff. I’ll still be responding questions here, but without my computer what I can try is limited. 😕

Hello guys! I always used wrap-reload to keep my backend code fresh. What alternative could I use in my code with connection to Pathom Viz? What I want to achieve is not having to restart my clj parser to see the change in Viz. Should I write something to manually reload my namespace with the env and resolvers ?

@paul931224 i normally have a viz namespace with the tracked-env, everytime i change smoething on the resolvers, i have to reload the viz ns, but no need to restart clj. i am sure there is a better way

Hmm, I'll try that, but I'll still search for the better way. Thank you :)

I generally end up having to refresh viz with crtl-r to get the changes picked up after reloading the namespace

But this is also probably me doing something wrong

Side note I am shadow-cljs and node land which may also affect things

For me, refreshing it doesn't reloads the namespace. But when route handling triggers my wrap-reload , pathom viz will pick up the namespace change aswell.

Hammock time maybe?

Do I have to list all of the keys [:account/id :account/email :account/password] in my ::pco/output ? What if my schema changes, do I always have to change the resolver? Even if the logic doesn't change?

(defresolver account-by-id [{:keys [account/id]}]
  {::pco/output [:account/id :account/email :account/password]}
  (filter-by-value :account/id id user-accounts-db))

@paul931224 no. I personally like to add the keywords "on demand" If for example, you have one funcion that returns (f x) => {:a 1 :b 2 :c 3 :d 4 ....} If I'm working on a task that says "display the value of :a on landing page", I will write a resolver

(defresolver my-f [...]
  {::pco/output [:a]}
  (f x))

Thank you very much for the detailed answer. It's just enough flexible for my needs.