Fork me on GitHub
#pathom
<
2019-01-20
>
hmaurer03:01:30

@wilkerlucio I just watched your Conj 2018 talk, https://www.youtube.com/watch?v=yyVKf2U8YVg ; very interesting 🙂 I have one question on your last demo involving the spacex and youtube APIs. You use “aliases” to make a connection between the launch video URL and a youtube URL, so that you can traverse the graph from the spacex data to the youtube data. What if, however, you had multiple youtube links? i.e. a launch video and a behind-the-scenes video. Is there a way to get to the youtube data for each of these?

wilkerlucio06:01:02

hello, thanks for taking the time to watch it. For the to-many would be very similar, you still do the alias in the same way, when we think about list processing, its no different from one item processing, its just the same thing many times, so if spacex had some list of videos, we could make so in pathom its a sequence of maps, example:

{:spacex.launch/all-videos 
 [{:spacex.launch/video-url "..."}
  {:spacex.launch/video-url "..."}
  {:spacex.launch/video-url "..."}]}
so in the previous example it has a list of items, which each has a video-url, so you alias this and that's it, makes sense?

hmaurer11:01:07

@wilkerlucio and thanks to you for taking the time to reply. Ha! I didn’t mean a list of videos. What I meant was two properties each pointing to a youtube url. For example, :spacex.launch/video-url and :spacex.launch/interview-url

hmaurer11:01:46

From what you said about aliases in the talk, it seems that at this point Pathom would not be able to pick which video to follow

hmaurer11:01:05

Unless there is some sort of join/other way around this issue

wilkerlucio12:01:38

ah, gotcha, well, you have some options in this case, in the example you sent now there not a single definitive way to link, so the api designer should choose, you could still point the video-url to translate to youtube as the default, and make a secondary join for the interview one, something like: {:spacex.launch/interview-youtube [:youtube.video/url]}, this way in the same level of the launch you get the main video, or join to this new name to get data about the interview part. You could make both depend on a join, this reduces the library reach but also reduces ability, the choice will depend on each case. A third option, in case there are two different variables that point to the same thing (maybe because some field got renamed for example), in this case you can implement resolvers for both cases, and pathom will choose which to use (and backtrack in case it fails, trying the other option)

hmaurer13:01:30

@wilkerlucio ah, thank you! That’s useful information. So I take it there is no feature in EQL to “alias an attribute to another” within a new context? I am not sure I am using the right terminology, but what I meant is that if, as per the example I gave, you have two youtube URLs in a context (assigned to different attributes), it seems like you should be able to write a query along the lines of “I was to traverse down that road by assigning this attribute to :youtube.video/url within a new context, and get :youtube.video/name, and similarly for the other youtube URL”

hmaurer13:01:37

Without a change in the API itself

hmaurer13:01:13

Would such a query feature make sense? Or is there something I am missing? (i.e. would it not work because of X and Y, or…)

hmaurer13:01:52

Your suggestion of changing the API design makes sense though, and if I have control over the API it seems sensible. I am just wondering if the approach I am suggesting above could be done

wilkerlucio13:01:04

the API doesn't really have to change, you can just write more resolvers on top of it and make more nesting, the connection between apis is supposed to be mostly in user control

wilkerlucio13:01:10

pathom actually does have an alias feature to change the output name of things, but that doesn't affect the connect process, its just about renaming some output (the use case is when you need the same attribute twice using different parameters, so you can alias one of then to something else, you can do it as: (:my-key {:pathom/as :output-name})

hmaurer13:01:29

Ah, I see. Still have to get used to some of that way of thinking. Thanks!

hmaurer14:01:49

Another question on Pathom: would this be the right approach for a parametarised query?

{:pc/input #{:pagination/limit}
 :pc/output [{:user/all ....}]}
And how would one write a resolver where some of those inputs are optional? (i.e. a query that can have a bunch of filters, but where most filters are optional and have some defaults)

wilkerlucio14:01:45

no, inputs and params are two different dimensions, the input is more like information to traverse, a dependency (a requirement of the operation to run, that might be available via some computation), its a blur line but from experience I can tell you pagination is usually a param, not an input, so the param you can declare using ::pc/param (be careful, your code is using a single : on the namespace, you need o use :: to expand the alias to get the real keyword, if you not familiar with fully qualified keywords check: https://www.deepbluelambda.org/programming/clojure/know-your-keywords)

wilkerlucio14:01:02

then, you can read the params with: (-> env :ast :params)

wilkerlucio14:01:36

the ::pc/param use the same syntax as ::pc/output, currently it does nothing to be honest, but in the future it will be used for auto-complete on the codemirror query editor

hmaurer14:01:54

ah yes, that was just a typo for ::. and thanks for the information on params. Can they be optional as well?

hmaurer14:01:19

ah nevermind, the doc seems to indicate there is no validation at the moment

hmaurer14:01:23

(as you just said as well)

hmaurer15:01:28

@wilkerlucio what is the syntax for passing params to a resolver? the doc only seems to mention params in conjunction with mutations

wilkerlucio15:01:25

@hmaurer you can find some docs for it in the EQL spec: https://github.com/edn-query-language/eql#parameters

💯 5
wilkerlucio15:01:04

and you motivated me to write the long missing docs about params in the pathom book, doing it now 😉

hmaurer15:01:45

@wilkerlucio unrelated but coming from GraphQL (which I use on some hobby projects) I particularly liked the part of your talk on interfacing multiple domains (i.e. spacex + youtube). That was a big questionmark for me in GraphQL; how to do schema stitching. Pathom’s attribute-level approach feels a lot more natural for this

😄 5
hmaurer15:01:31

@wilkerlucio is there a section of the documentation that discusses how to best represent “soft” errors? (such as a validation error on a mutation). I was just reading https://wilkerlucio.github.io/pathom/#_error_handling which seems more suitable for hard, non-user-caused failures

hmaurer15:01:42

(I am using Fulcro)

wilkerlucio15:01:39

there is nothing fully done for it, but you can expose extra data in your errors, pathom supports a ::p/process-error fn that you can use to customise the output, what I usually do is expose a map so I can attach extra info, so if you have validations that can only be done on the server, you can add something to error to tell the UI to represent accordingly

hmaurer15:01:28

@wilkerlucio ah thanks! Do you know if this works in conjunction with Fulcro’s fallbacks? (http://book.fulcrologic.com/#Fallbacks). Either way I’ll try it right away

wilkerlucio15:01:27

it does, the fallback will cover you from network errors (500, network timeout, etc...), so not a lot of info available, but at least you can tell the user

hmaurer15:01:51

@wilkerlucio ah, but I meant as a way to pick up the validation error and transact some state (i.e. an error flag + message on the approriate field)

hmaurer15:01:01

well anyway I’ll try this out 🙂

wilkerlucio15:01:40

the fulcro fallback will only trigger if the remote responds with errors, pathom will never respond with an error (unless something had fail big time)

wilkerlucio15:01:35

so, I'm just getting you aware that to handle the "soft" errors from pathom, the best thing you can do now is using the pessimistic mutations from incubator: https://github.com/fulcrologic/fulcro-incubator#pessimistic-mutations

wilkerlucio15:01:42

this way you will have a nice way to handle those

wilkerlucio15:01:21

the fallback is still useful, but for other reasons (major failures, like having no internet to hit the parser endpoint, or something crashing bad)

hmaurer15:01:33

ah ok, makes sense.

wilkerlucio15:01:15

Add new docs for how to use parameters in resolvers https://wilkerlucio.github.io/pathom/#_parameters @hmaurer

hmaurer16:01:38

that was fast! thanks 🙂