A way to extract graphql queries when tagged template literal is not available?

[jfrolich]

I like to create bindings to Bucklescript for Gatsby.

However it's not possible to output tagged template literals in Bucklescript. Is there a way to extract graphql queries with gatsby without using tagged template literals?

[vladar]

Sadly, this is not possible at the moment. Tagged templates are a convenient way to extract data from JS AST at build time and we rely on them heavily. Technically, we could provide a way to override the default parsing, but it will have significant maintenance costs.

Also, other client-side GraphQL libraries also rely on tagged templates to extract persisted queries. So I guess it makes sense to request interop support for them in Bucklescript. Or maybe try using existing escape hatches?

[jfrolich]

Why is it a tagged template literal (as a string is just being passed in)? Would be nice to be able to do graphql("query") instead of ```graphql`query````. The interpolation is not being used I believe? (or is it?)

[vladar]

We don't execute this function. Queries are extracted from JS sources during the compile step to perform validation, fragment insertion, deduplication, etc. In fact, executing it is treated as error.

We use tagged templates for several reasons:

1. They are a language construct, meaning that they exist in JS AST as a separate node type which makes it trivial to extract them in compile time

2. They help to indicate that this is not really a simple function call and that query string must be a literal value so that Gatsby could do its work. Using function would be also confusing because people would assume they could do something like this:

const query = `{ foo }`
export const result = graphql(query)

While in reality, they can't - we need an argument to be a literal value (which is precisely why tagged templates are such a good fit here).

[jfrolich]

It would be nice to -- as an escape hatch -- allow graphql(string), you can in the babel plug-in even assert that a string literal is being passed in and raise an error otherwise. I also opened an issue on the Bucklescript compiler to support template literals (rescript-lang/rescript#4070), but that can take a while before it upstreams, and I'd like to build Gatsby integration for ReasonML/Bucklescript. But I understand if that is not a priority. If not are you open for a PR?

[vladar]

I think we can accept a PR that would enable this if it doesn't add too much complexity. Thanks for suggesting this!

[jfrolich]

Actually I dove in the internals, and the TaggedTemplate literal is used everywhere to identify graphql queries, so I think this would be tricky. I guess we need to wait for Bucklescript to adopt tagged template literals in some way.

[muescha]

since the tagged template literal is just a helper to extract the (first/last/only one) query text from the js via the JS AST.

maybe an other idea is: save the graphql query in an separate file with the same file name and the .graphql file extension?

src/templates/blog-post.js
src/templates/blog-post.graphql

[sidharthachatterjee]

@jfrolich It isn't likely that we'll be adding support for graphql(query) because like you correctly identified, we rely on tagged templates pretty heavily and supporting graphql(query) would add a pretty large maintenance burden for what looks like a fairly niche use case.

I would suggest the escape hatches that @vladar linked to.

Thank you so much. Let's close this issue.

[jfrolich]

@jfrolich It isn't likely that we'll be adding support for graphql(query) because like you correctly identified, we rely on tagged templates pretty heavily and supporting graphql(query) would add a pretty large maintenance burden for what looks like a fairly niche use case.

I would suggest the escape hatches that @vladar linked to.

Thank you so much. Let's close this issue.

Yes I figured that out. There is actually a hacky way to generate tagged template literals in Bucklescript, and I opened a ticket to have proper language support for generating tagged template literals. I think that indeed makes most sense! Thanks for engaging.

[ghost]

This is one the only things that makes bucklescript with gatsby less attractive than bucklescript with nextjs. How does typescript deal with this?