Currently, we can specify arbitrary selection on a given resource, if we write it as a fragment on that given resource. Fields selected in this fragment are then used to build the query that is sent to the server.
The goal is to take
fragment X on Y {
field
anotherField
}and produce a query
query Ys($where: YWhereInput $orderBy: [YOrderByInput!] $take: Int $skip: Int) {
items: Ys(where: $where orderBy: $orderBy take: $take skip: $skip) {
field
anotherField
}
total: YsCount(where: $where)
}This works well. I personally had a situation where I wanted to extract fields that are common in one and many fragments so I don't forget anything, like this:
const common = `
id
field
`
const one = gql`
fragment Xone on Y {
${common}
anotherField
}
`
const many = gql`
fragment Xmany on Y {
${common}
}
`This also works well, and allowed me to deconstruct the fragments into logical parts.
But then I ran into a problem. I wanted to have the types of the queries generated. In our case we use @graphql-codegen library which can scan files for export const something = gql.... objects and parses them and generates static types for them. The problem is, it needs to have everything available on compile time, so it can't process the previous example (explanation here). On the other hand, codegen can process GraphQL fragments, so if we were to rewrite the example with that, it would work:
const common = gql`
fragment Xcommon on Y {
id
field
}
`
const one = gql`
fragment Xone on Y {
...Xcommon
anotherField
}
${common}
`
const many = gql`
fragment Xmany on Y {
...Xcommon
}
${common}
`But then if we want to use one and many in our resource views, we run into a problem with the way we process the fragment. This is because one contains in this case
fragment Xone on Y {
...Xcommon
anotherField
}
fragment Xcommon on Y {
id
field
}which in code is a DocumentNode but with 2 definitions, and ra-data-prisma uses the first one, which would result in a spread of unknown fragment. AFAIK there's no way to combine the two approaches without duplication e.g.
At first I thought we could try to do the fragment "interpolation" manually (after all, the document is a JS object) but then again, we could miss something if there were many fragments combined. On a second thought though, we are in control of the outgoing query to the server, and if we were to supply all the used fragments outside of the query, it produces a valid GQL operation:
fragment X on Y {
field
anotherField
}
query Ys($where: YWhereInput $orderBy: [YOrderByInput!] $take: Int $skip: Int) {
items: Ys(where: $where orderBy: $orderBy take: $take skip: $skip) {
...X
}
total: YsCount(where: $where)
}This would keep the functionality intact if I'm not missing something, and allows us to freely use GQL fragments and in my case, the @graphql-codegen library.
Footnote: Not using fragments and directly specifying every field from the beginning works for both as well, but I think being able to use fragments would be nicer and more flexible.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent