This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-24
Channels
- # announcements (2)
- # beginners (131)
- # calva (4)
- # cider (29)
- # cljs-dev (18)
- # cljsrn (8)
- # clojure (61)
- # clojure-czech (1)
- # clojure-europe (5)
- # clojure-italy (14)
- # clojure-nl (6)
- # clojure-switzerland (2)
- # clojure-uk (125)
- # clojuredesign-podcast (10)
- # clojurescript (25)
- # clojutre (15)
- # clr (4)
- # code-reviews (4)
- # data-science (1)
- # emacs (1)
- # events (2)
- # fulcro (12)
- # graalvm (4)
- # jobs (2)
- # keechma (1)
- # off-topic (1)
- # pathom (18)
- # re-frame (3)
- # reagent (7)
- # shadow-cljs (106)
- # spacemacs (33)
- # sql (12)
- # xtdb (5)
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.
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}
.
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
Ah, yep, adding p/elide-special-outputs-plugin
to my plugin list did the trick. Thank you.
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
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).
@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 🙂
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]}]))
(<!! (parser {:person/first-name "Brian" :person/last-name "Last"} [:person/full-name]))
@brian.rogers
I copied and pasted that. Are we trying to put that directly into the context map with your code there?
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
@brian.rogers I think you are looking for this: https://wilkerlucio.github.io/pathom/v2/pathom/2.2.0/sugar.html#_parser_context_interface
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
is this what you are looking for?
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).