You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It can be quite common to perform the same subquery in multiple queries. It's therefore desirable to be able to abstract this subquery away and be able to include it into different queries for reuse (and reuse of the typeclass instances of the result class - which we may already have if we're mapping into an external type).
The biggest choke point I see with this is how to get grackle to process obsQueryDocument. We could trick it somehow. Otherwise we would have to process the interpolated string within the scalafix rule, which means evaluating it, which I don't know how to do (maybe we could imitate mdoc?). But I think that other than that, we can get away with generating a reference to an external type (Target in this case, obtained from the SubQuery) and resolving the interpolated string only at runtime.
The text was updated successfully, but these errors were encountered:
@GraphQLobjectTargetFragmentextendsGraphQLFragment[Target] {
valsubDocument=""" | fragment targetBaseFields on Target { | id | name | magnitudes { | band | etc | } | }""".stripMargin
}
Type-check and generate output types for fragments (will grackle do this just for fragments?).
Extract the fragment name (should be easy, could be generated into a val in the GraphQLFragment.
As mentioned before, interpolating the string in scalafix. It should end up being a string that:
a) has ...fragmentName in lieu of $Fragment.
b) has the fragment document concatenated at the end.
So, maybe interpolation is not the right choice?
Inserting the type alias to $Fragment.Data in the correct position within the generated types.
It can be quite common to perform the same subquery in multiple queries. It's therefore desirable to be able to abstract this subquery away and be able to include it into different queries for reuse (and reuse of the typeclass instances of the result class - which we may already have if we're mapping into an external type).
I imagine something along the lines of:
And a string interpolator to insert the
subDocument
in aQuery
.An example of usage would be:
And then somewhere else, in a
Query
:The biggest choke point I see with this is how to get
grackle
to processobsQueryDocument
. We could trick it somehow. Otherwise we would have to process the interpolated string within the scalafix rule, which means evaluating it, which I don't know how to do (maybe we could imitatemdoc
?). But I think that other than that, we can get away with generating a reference to an external type (Target
in this case, obtained from theSubQuery
) and resolving the interpolated string only at runtime.The text was updated successfully, but these errors were encountered: