Fork me on GitHub
#pathom
<
2019-10-23
>
henrik09:10:48

Do I have to do something in particular to support :com.wsscode.pathom.graphql/aliased fields (add them manually to the index)? The query finishes the roundtrip, but the field shows up unaliased, and resolved to :com.wsscode.pathom.core/not-found. Checking the query with query->graphql, the query does resolve properly, with proper GraphQL syntax produced for the aliased field.

henrik10:10:12

This is the expression:

(:zd.Article/article_has_attribute
 {::pg/alias "has_fulltext_edn"
  :attribute_name "article_fulltext__hiccup_edn"})
The result:
{:zd.Article/article_has_attribute :com.wsscode.pathom.core/not-found
 …}
Dropping the alias results in:
{:zd.Article/article_has_attribute true
 …}

wilkerlucio12:10:31

@henrik hello, this is a current limitation when doing graph/graph communication, the way pathom figures the fields to send to graphql is by looking on its own query, but, it only looks at things that are directly visible (in your query) without looking for those things dependencies, in your case, the alias makes a dependency on a "hidden" field, and that's not picked up by pathom currently, if you query using both fields (original graphql name + alias) it will work

henrik12:10:53

Gotcha, so theoretically, the short-term fix should be

[:has_fulltext_edn
 '(:zd.Article/article_has_attribute
   {::pg/alias "has_fulltext_edn"
    :attribute_name "article_fulltext__hiccup_edn"})]

henrik12:10:54

Though I seem to end up with another attribute that is not found.

wilkerlucio12:10:49

oh, I may had got your question wrong, what kind of alias is that (I was confusing with connect aliases)

henrik12:10:16

Aha, sorry, probably my poor explanation. This is about aliasing GraphQL fields.

wilkerlucio12:10:31

click on the Aliases example

henrik12:10:10

That’s where I started, yes. This doesn’t in practice work when I do it through Fulcro Inspector.

wilkerlucio12:10:20

but I don't remember if that works with the connect integration, if what you want is to have a diffrent name on the EQL output, you may want to do this:

wilkerlucio12:10:51

(:zd.Article/article_has_attribute
  {:pathom/as :my/new-output-name
   :attribute_name "article_fulltext__hiccup_edn"})

wilkerlucio12:10:19

but in Fulcro that can get confusing, because the query will not match the output

wilkerlucio12:10:34

can you tell more about your use case for doing the aliasing?

henrik12:10:36

Sure, the API defines article_has_attribute as a way to check whether any particular field is present or absent on a particular article. Since some parts of an articule can weigh up to 10mb, this is necessary in order to know whether to show a button for downloading the full text of the article (for example), without actually retrieving the entire fulltext before the button is clicked.

henrik12:10:41

:pathom/as seems to produce the same result. Hang on, I’ll show the queries.

henrik12:10:28

(As such, article_has_attribute can show up multiple times in a query, necessitating aliasing for each)

wilkerlucio12:10:17

gotcha, makes sense, I'm not sure if that's currently supported, but I understand the need, today I'm pretty busy but I can take a closer look on how we can support that tomorrow

henrik13:10:14

Thanks a lot! Perhaps EQL should have a general aliasing syntax, rather than being Pathom-specific? It seems like it could be regarded as a structural concern of the syntax, rather than an application feature (although a converter from EQL->something else would still have to know how to deal with it in the target language, of course).

henrik13:10:14

Maybe it’s a bit wonky, maybe it interferes with other metadata concerns in EQL, but maybe something like:

{^{:alias :bar} 
 (:foo {:with "params"})
 [:something]}

wilkerlucio14:10:16

well, I like to try to thing of changes that has the least impact on the current things, that considered I think we maybe want something in the opposite direction, like: (:aliased-name {:pathom/source :original-name})

wilkerlucio14:10:48

because doing that would just work with Fulcro and other parts of the system that expect the final value to be the attribute source in the query, makes sense?

henrik14:10:50

Yes, that’s fair enough! It certainly looks better, and vaguely mirrors the syntax they choose for GraphQL (not that GraphQL necessarily is the gold standard, of course)

wilkerlucio12:10:02

so, computing all sub-variations can get expensive quickly, I'm currently working on a new query planner that I hope will make this better, because in the current state its hard to get "dynamic resolvers" right because of those implicit dependencies

henrik12:10:52

Without aliasing

henrik12:10:16

With ::pg/alias

henrik12:10:30

With :pathom/as