Fork me on GitHub
#pathom
<
2022-04-13
>
Brett Rowberry03:04:14

I'm just getting started learning about Pathom after listening to a few podcasts with Wilker as a guest published in 2020. How do people feel today about using Pathom 3 for new development?

jmayaalv04:04:28

We have been using pathom3 in production already for about 6 months and feel really happy about it. We didn't have any major problems. Performance is top notch, no major bugs or breaking changes. Only problem is that now clients are getting used to quick delivery times ๐Ÿ˜…

๐Ÿ˜„ 2
nivekuil04:04:27

the biggest problem with pathom is that once you've tried it, it is just painful to program without it

โ˜๏ธ 3
๐Ÿ˜„ 1
Brett Rowberry15:04:33

Thanks, that's good enough for me!

wilkerlucio19:04:07

glad to hear you got to those, there is a new podcast that was released last week as well, in case you want get more of those ๐Ÿ™‚ https://cognitect.com/cognicast/168

๐Ÿ‘ 3
sheluchin15:04:50

Is there a way to express that resolver x is the same thing as resolver y but with added params? Something to avoid reproducing the logic but still provide a new name. e.g. sub-rand is the same thing as sub {:n (rand)}.

::pco/input [`(:sub {:n ~(rand)})]
gets pretty close but that's compiled in and so the input isn't dynamic.

markaddleman16:04:11

If I understand your use case correct, you would have a single single resolver that optionally takes {:sub [:n]}

sheluchin16:04:11

I don't think so. I still want to have a separate name for the output attributes.

markaddleman16:04:31

Ah, I didn't catch that

sheluchin16:04:18

It's obviously a simplified example, but the long and short of it is that I want one resolver to contain a bunch of logic and some other resolvers to make use of that resolver by just parameterizing the logic within it. Like now->time-ago would be the flexible one, and then there'd be a now->years-ago and now->months-ago which would use the first one but fill in the :time-unit param and adds their own n.

markaddleman16:04:01

In that case, I think your best bet is to factor out the common code to a regular clojure fn and call that fn from the different results.

markaddleman16:04:14

You may be able to take advantage of ::pco/op-name from the defresolver macro

sheluchin16:04:14

I suspect you're right, but given that there are alias resolvers and other helpers that seem to get pretty close, I thought there might be a more Pathomic way.

markaddleman16:04:08

I've often wished for more defresolver attributes to perform more logic but I end up realizing it's just better to drop to regular clojure fn.

markaddleman16:04:36

One thing that does come in handy: resolvers implement IFn so you can use them like regular fns

1
sheluchin16:04:28

Hmm, that might help here.

sheluchin16:04:29

@U2845S9KL good idea. Thanks for the tip:

(comment
 (pco/defresolver sub
   [env _]
   {::pco/output [:sub]}
   {:sub (- 100 (or (:n (pco/params env)) 0))})

 (pco/defresolver sub-rand
   [_]
   {::pco/output [:sub-rand]}
   {:sub-rand (:sub (sub {::pcp/node {::pcp/params {:n (rand)}}} :_))})

 (p.eql/process (pci/register [sub sub-rand])
                [:sub-rand]))

๐Ÿ‘ 1
wilkerlucio19:04:52

this is an interesting thing to think about, how to transfer params over. one simple way is to use inputs instead of params, since they already flow. this makes me think that if you alias an attribute, the aliased version wont get any of the params used from the source attribute

wilkerlucio19:04:06

(also, quite confusing to read this thread when you both have the same profile pic, rsrs)

sheluchin19:04:59

@U066U8JQJ do you consider invoking resolvers directly like that as an antipattern? The docs mention direct invocation is mostly used for testing.

wilkerlucio19:04:13

not really, but you lose the auto-caching mechanism when you do it (also plugin invokation and etc, but in this case that may be desired)

wilkerlucio19:04:44

using a resolver in this way is pretty much as same as calling a regular function (which wont leverage any of the pathom running stuff)

wilkerlucio19:04:31

the situation makes me think that a proper way to transfer params could be nice

sheluchin20:04:10

It sounds like param routing is a recurring question in this stage of Pathom's development. I recall something similar coming up recently... Maybe there's a PR or something I read. Thanks for the feedback.

wilkerlucio20:04:05

I dont remember the other occasion, can you please refer to me if you find it?

wilkerlucio20:04:00

no, that's a different thing, this other one is related to transfering sub-queries to dynamic resolvers

sheluchin20:04:35

Hmm, but you do specifically mention in that post that in addition forwarding sub-query parts, thinking about forwarding params could be another side of it. I'm probably missing some nuance in the language and/or implementation. No worries. Thanks again @U066U8JQJ.

wilkerlucio20:04:33

to help clarify, the params I mention is for making possible to transfer the sub-query, because its not possible for Pathom to figure it out where it should append the sub-query on the target part, so the user must mark in the query where the sub-query should be injected, thats where the param comes in, in this case its a flag to help pathom (more like we use params to mark parts of the query as optional)

๐Ÿ™ 1
sheluchin20:04:05

Oh, ok. So more like a request configuration flag than the params we pass to resolvers to parameterize their internal behaviour. I guess it's like a meta param :)

wilkerlucio20:04:09

we can say so ๐Ÿ™‚

wilkerlucio19:04:07

glad to hear you got to those, there is a new podcast that was released last week as well, in case you want get more of those ๐Ÿ™‚ https://cognitect.com/cognicast/168

๐Ÿ‘ 3
Benjamin C20:04:36

(cross-posted from #fulcro, as it has to do with pathom) Is there a proper way to get the pathom env so I can run server-initiated mutations or queries? Digging through fulcro RAD's form code I found this:

(def save-form
     {:com.wsscode.pathom.connect/mutate (fn [env params] (save-form* env params))
      :com.wsscode.pathom.connect/sym    `save-form
      :com.wsscode.pathom.connect/params #{::id ::master-pk ::delta}})
Which seems to translate somehow into a callable function that calls the passed mutate fn with the env, but I haven't yet figured out where or how this happens. Edit: Solved! Turns out you can create your own env with whatever you need. Although I am still a little curious about how save-form works. :)

tony.kay22:04:27

In Pathom 2 resolvers and mutations are just maps. That is the definition of the mutation, which is then added to the pathom processor.

tony.kay22:04:32

form/resolvers is added in the call to new-parser (which includes the save mutation)

tony.kay22:04:37

That generic save-form function then looks in env for database adapters, and passes along the diff for actual savingโ€ฆso for example the datomic/pathom-plugin and form/pathom-plugin each add elements that are needed by that function to do the actual work.

Benjamin C23:04:51

Ah, that makes sense. Thank you!