Fork me on GitHub
#pathom
<
2021-03-23
>
markaddleman03:03:27

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?

markaddleman03:03:07

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

wilkerlucio15:03:12

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. 😕

😮 3
😵 3
😱 36
littleli21:03:20

Hammock time maybe?

3
p4ulcristian16:03:01

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 ?

jmayaalv17:03:33

@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

p4ulcristian17:03:18

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

royalaid17:03:21

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

p4ulcristian17:03:31

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.

royalaid17:03:37

But this is also probably me doing something wrong

royalaid17:03:58

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

p4ulcristian22:03:04

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))

souenzzo23:03:47

@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))
With this resolver, if someone ask for [:a :b], it wil return {:a 1 :b 2}, because #pathom will call my-f to resolve :a, merge it result to entity. When pathom tries to find b, it's already on entity, then return. If you ask for [:b], it will return nothing {}, because it can't find any resolver that delivers :b If you are working on a fullstack app, where you control the queries, you can be more "lazy", like me If you are writing an public API, you may decide to always declare all the keys.

👍 3
p4ulcristian23:03:57

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