-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configuring keyArgs for types rather than fields? #8021
Comments
I'm not sure this would make sense outside of your use case. GraphQL allows you to return the same type from multiple different places, each with its own unique set of arguments. It would be impossible to guarantee that the type will always have the same arguments. |
Sure but we could always still specify a specific
I thought pagination was pretty common, what is specific from my use case? |
@benjamn Hello, sorry to bother you with this ping. For now I've developed a graphql-codegen plugin to create the |
Having worked on pagination in the past few days, I'm not sure how your scenario would work. |
@LeonardDrs I see where you're coming from, but I agree with @dylanwulf and @sebastienbarre that the details don't quite work out. Another problematic case (simpler than pagination): what if you're replacing the value of an The I'd love to see that GCG plugin if you can share it! |
Hey, thanks all for your replies. I had dream that we could have specify
Keeping the default The GCG plugin was published under our private repo and fit our needs/api. |
type WhereQuery {
active: Boolean!
}
type Item {
id: ID!
children(first: Int = 20, after: String, where: WhereQuery): ItemConnection!
}
type ItemConnection {
edges: [ItemEdge!]!
pageInfo: PageInfo!
}
type ItemEdge {
cursor: String!
node: Item
}
Type Policy const itemConnectionTypePolices = {
...relayStylePagination(() => ["where"]), // without normalisation
fields: {
edges: {
fields: {
node: {
fields: {
children: itemConnectionTypePolices,
},
},
},
},
},
};
const memoryCacheOptions = {
typePolicies: {
Item: {
fields: {
children: itemConnectionTypePolices,
},
},
},
}; https://www.apollographql.com/docs/react/caching/cache-configuration/#disabling-normalization
Ideas
@sebastienbarre it should be the type of the field that would be the referring type, which at that point you could supply the args for normalisation / manipulation. |
Hey all 👋 Appreciate the discussion here but I'm not sure there is anything more to add so I'm going to go ahead and close this issue. Thanks! |
Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better. |
Hey,
I've seen that we can specify
merge
function for types rather than fields. But sincetypePolicies.Type.keyArgs
does not exist - which seems normal since we are talking about a type, not a query field - am I forced to useQuery.fields
for pagination?To be more precise:
I have an album containing multiple tracks with this schema:
When I want to paginate, I could use the following query:
with this
fetchMore
:and this
typePolicies
:Everything works perfectly.
But then, if I want to configure the
typePolicies
for type over fields, sinceAlbumTracksConnection
is always paginated, I'd try:which does not work as the
Album.fields.tracks
policy keeps its originalkeyArgs
value.I would then need to specify
Album.fields.tracks.keyArgs
to false in the typePolicies for the pagination to work. But then I would loose the benefit of being able to target types over fields name.So the question is:
Do we want to be able to handle pagination/keyArgs via type, like we are able to handle
merge
? It would ease the pagination for types.Or am I doing something wrong with the pagination?
Probably related: #7070 (comment)
PS: In real life, I'd use a
Paginable
type like so:The text was updated successfully, but these errors were encountered: