Clojurians Log v2

when the resolver can’t return the value, use ::pco/unknown-value as the value instead.

if the query requires the value, it will look elsewhere, or fail (which is what you want probably)

in principle, all output items are potentially optional, its better to say it can be there and not return than the other way around. because if you dont provide the info, Pathom wont know that path is possible, this is especially important for nested requiremnets, because Pathom 3 will look ahead to see if a potentional nested requirement is reacahble, and if not it will discard that path

@wilkerlucio ah righto. So {} is just as good as {:prop ::pco/unknown-value} yeah?

@caleb.macdonaldblack yup, the unknown value is useful when you have a conditional statement and wanna have the option to "dont provide the value", so you use the unknown value in such cases

btw, a good time to point out there is a little helper plugin to even warn you if you return something from a resolver that wasn't declared, because that usually means a misconfiguration: https://github.com/wilkerlucio/pathom3/blob/main/src/main/com/wsscode/pathom3/connect/built_in/plugins.cljc#L123-L147

@caleb.macdonaldblack to give a concrete example, this is a common scenario where I use unknown-value:

(pco/defresolver some-resolver [{:keys [input-thing]}]
  {:output-thing
   (if input-thing
     (str "modified" input-thing)
     ::pco/unknown-value)})

Ah, it’s more ergonomic than a when-some. Lets you return the map entry structurally, but as if it wasn’t returned

Makes sense. Not to be confused with:

(pco/defresolver some-resolver [{:keys [input-thing]}]
  {:output-thing
   (when input-thing
     (str "modified" input-thing))})

this way I can leverage the output inference, at the same time I can say that value is unknown, which is effectively the same as not returning that key (pathom will completly drop it). good to remember that for Pathom, a nil is different than a not defined value, a nil is considered a resolved value (Pathom wont try to find a way to get it anymore) while not having a value means an unknown, and if possible, Pathom will try to find a way to get it

I’m not sure in my particular case whether returning nil would be better. In a certain sense my resolver is probably terminal: if a pull doesn’t find it, it isn’t findable; otoh it makes resolvers less composable, because I couldn’t add one later that computes it another way.

it depends if you wanna short-circuit that attribute processing or not

returning nil is probably an anti-pattern

if you return nil is like saying: "I know this attribute is nil, stop here", while the other way is more like: "I can't respond for this attribute, if there is another way path to it, go try it"

@caleb.macdonaldblack not really, in the biggest Pathom project I know we do use it quite a lot, because there are many paths for many things, but in a lot of cases we do like to short-circuit it because we know in some cases its better to just stop, which makes the process faster

@favila sorry, I dont get the last question, can you give an example?

@wilkerlucio fair enough.

Say a resolver produces a deeply-nested value, e.g. from the result of a datomic pull. Then you want another resolver to produce the equivalent of {:denormalized-derived-value (or (get-in [:a :b :c ...]) ::missing)} The :input of this resolver would be [{(pco/? :a) [{(pco/? :b) [...]}]] which feels awkward.

will pathom exhaust every possibility of getting an input before calling a resolver where that input is optional?

anyway with datomic data expecially pco/? is essentially everywhere; only if your domain-model has some extra constraint can you remove it.

if its optional, then altough awkward its the right thing to do here. Pathom does the optional processing in a different "lane" then the main one, so it wont fail if those are unavailable. if you need it a lot like that, you can write some helpers to traverse the query and add the optionals, since its all data its quite trivial to implement

you can write a helper like: (make-all-optional query)

Ok, thank you very much. I’m still not sure which approach to take here, but I understand the tradeoffs better!

It’s especially good to know that providing widest-possible output expression is desirable all the time.