-
Notifications
You must be signed in to change notification settings - Fork 49
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
change the name of pagination fields. #345
Comments
Hmmm, in fact now that I think about it this should be possible for the devs. I mean you can do something like this: import { ID, ObjectType } from '@nestjs/graphql'
import { FilterableField, PagingStrategies, Relation } from '@ptc-org/nestjs-query-graphql'
import { TodoItemDTO } from '../todo-item/dto/todo-item.dto.ts';
@ObjectType('Test')
@Relation('todoItem', () => TodoItemDTO, {
connectionName: 'todoItemsConnection',
pagingStrategy: PagingStrategies.CURSOR,
})
@Relation('todoItem', () => TodoItemDTO, {
connectionName: 'todoItemsOffset',
pagingStrategy: PagingStrategies.OFFSET
})
export class TestDTO {
@FilterableField(() => ID)
id!: number
@FilterableField()
title!: string
} Although I cannot see how I can flag one of the |
Just had some discussions in the GraphQL Discord serve and the outcome was just do not get overboard and just develop you API. When the time comes to introduce a breaking change follow this pattern: https://discord.com/channels/625400653321076807/1322503283117654079/1323001563840516331 @TriPSs Do you have any comment on this? Because if not I am gonna close this issue since it does not make sense as of now to me anymore 🙂. |
@TriPSs lemme know what you think, I am bit short on ideas. |
I believe no answer means no idea. Thus I believe I will close this issue for now. We can discuss it again later if it made sense at that time. |
Sorry for the late reply:
By providing different |
Is your feature request related to a problem? Please describe.
It is a really good idea to rethink and potentially change our naming conventions for naming fields. In the GraphQL doc, in the best practices, under the "Complete connection model" it is worth noting that it is naming the fields like this:
For example it uses
friendsConnection
and notfriends
.Note
Unfortunately I did not where I read/heard for the first time that it is a good idea to add the
Connection
suffix to the name of your field that needs to have pagination enabled 🥲.Have you read the Contributing Guidelines?
Yes.
Describe the solution you'd like
I guess it's gonna be fairly simple, instead of
todos
we're gonna havetodosConnection
. And then we can let devs to use one over another (I mean now we can have the normaltodos
field to do an offset pagination or alternatively we can addOffset
suffix to these fields as well).This gives us the ultimate flexibility that we need. Think of it this way, you're now developing a GraphQL API, and your in love with the concept of not having to deal with versioning anymore. So with that in mind now you've implemented the cursor based pagination and so far everything is cool but then you need to switch to offset pagination for some unknown reasons. So now if we switch from cursor based pagination to the offset base pagination as describe in the docs with
@QueryOptions({ pagingStrategy: PagingStrategies.OFFSET })
you're gonna introduce breaking change.And this is not a desirable outcome. Let's also forget about the fact that we have
@deprecated
directive just to enable our clients to have a much smoother transition to the new API.Describe alternatives you've considered
I am not sure and have not tried it yet I could always go with
@Relation('todoItem', () => TodoItemDTO, { connectionName: 'todoItemsConnection' })
.Additional context
But my point here is our default behaviors, and possibly supporting two different kind of pagination strategy at the same time.
The text was updated successfully, but these errors were encountered: