Fork me on GitHub
#pathom
<
2019-09-24
>
cjsauer13:09:58

I looked into this, and even attempted to read the paper after it was presented at Conj 2018. It’s very cool, but something about it feels like using a sledgehammer to kill a fly. It’s likely that I don’t truly understand how it works, coupled with the fact that it’s implemented in a different language (Rust). That’s a fair bit of complexity to bring in to a “basic” application in my opinion.

cjsauer16:09:09

What is the intended result for an entity that is not found? For example, when I do (parser {} [{[:my/id 10] [:my/id]}]), I always end up with {[:my/id 10] {:my/id 10}}, which I’m sure is “correct”, but how do I express the fact that [:my/id 10] does not exist? I’d expect something like {[:my/id 10] ::p/not-found}.

souenzzo16:09:31

not-found can mean "1- can't find a resolver to this keyword" or "2- the resolver didn't return that key" on both cases, pathom will solve it for you, and you can attach a "elide-special-keys" plugin to remove that keys

cjsauer16:09:44

Ah, yep, adding p/elide-special-outputs-plugin to my plugin list did the trick. Thank you.

wilkerlucio22:09:57

one thing that is good to clarify around "presence check" is that Pathom works around the idea of attributes in the first place, so the real check must be per attribute (and not per entity), this is an important distiction, for example, you can have multiple endpoints hooked around some id like :customer/id, in some resolvers the result might be unknown and others may work, so I think its important to keep in mind this "attribute individuality" mindset

cjsauer12:09:14

That’s a really good point. Do you tend to use the elision plugin @wilkerlucio ? It seems the trade-off is more defensive/conditional code on the client, rather than nil punning on the results (not using the plugin versus using it).

wilkerlucio12:09:47

@U6GFE9HS7 yes, using elision is fine, I do most of the time too, I like to keep the default without it so people understand if you need this level of detail you can get it, but to be honest I'm still trying to find cases that I prefer not eliding, that default recommendation may change 🙂

👍 4
Brian21:09:23

How do I call the person-name-resolver found here: https://wilkerlucio.github.io/pathom/#_derivedcomputed_attributes in the second code chunk? I've tried as many ways as I can think of and can't seem to get it. My most recent attempt was (<!! (parser {} [{[:person/first-name "Brian" :person/last-name "Last"] [:person/full-name]}]))

Brian21:09:55

However that just returns a not-found

souenzzo21:09:15

(<!! (parser {:person/first-name "Brian" :person/last-name "Last"} [:person/full-name])) @brian.rogers

Brian21:09:28

@souenzzo that yields a "not-found" still for me

Brian21:09:55

I copied and pasted that. Are we trying to put that directly into the context map with your code there?

Brian22:09:15

How can I do it as part of the query instead of the context?

Brian22:09:19

Is that possible?

wilkerlucio22:09:57

one thing that is good to clarify around "presence check" is that Pathom works around the idea of attributes in the first place, so the real check must be per attribute (and not per entity), this is an important distiction, for example, you can have multiple endpoints hooked around some id like :customer/id, in some resolvers the result might be unknown and others may work, so I think its important to keep in mind this "attribute individuality" mindset

wilkerlucio22:09:31

you can also do it at query level using an ident query, that's described here: https://wilkerlucio.github.io/pathom/v2/pathom/2.2.0/connect/resolvers.html#_multiple_inputs

wilkerlucio22:09:36

is this what you are looking for?

cjsauer12:09:14

That’s a really good point. Do you tend to use the elision plugin @wilkerlucio ? It seems the trade-off is more defensive/conditional code on the client, rather than nil punning on the results (not using the plugin versus using it).