Skip to content
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

Closed
kasir-barati opened this issue Dec 28, 2024 · 5 comments
Closed

change the name of pagination fields. #345

kasir-barati opened this issue Dec 28, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@kasir-barati
Copy link
Contributor

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:

pluralNameConnection

For example it uses friendsConnection and not friends.

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 have todosConnection. And then we can let devs to use one over another (I mean now we can have the normal todos field to do an offset pagination or alternatively we can add Offset 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.

@kasir-barati kasir-barati added the enhancement New feature or request label Dec 28, 2024
@kasir-barati
Copy link
Contributor Author

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 @Relations as deprecated. I can see description and other options though.

@kasir-barati
Copy link
Contributor Author

kasir-barati commented Dec 30, 2024

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: postsV2 or whatever your Object type might be called.

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 🙂.

@kasir-barati
Copy link
Contributor Author

@TriPSs lemme know what you think, I am bit short on ideas.

@kasir-barati
Copy link
Contributor Author

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.

@TriPSs
Copy link
Owner

TriPSs commented Jan 21, 2025

Sorry for the late reply:

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 @Relations as deprecated. I can see description and other options though.

By providing different connectionName's is already possible, adding support for the depreciation field would be a good addition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants