-
Notifications
You must be signed in to change notification settings - Fork 99
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
Generate generic Pagination API for connections #639
Comments
@mbossenbroek - could you please take a look when you get a chance? |
@JLLeitschuh you're right - when creating the projections I was converting the type to kotlin first & then deriving the name of the projection by picking the innermost type. Obviously this failed if it found a mapped generic type & picked the inner type of the edge instead of the connection. This should fix it by looking instead at the name of the GQL type itself for determining the name of the projection, effectively ignoring the mapped types when building the client. I updated one of the examples to use the relay mapping as well to confirm the behavior: #642 |
@srinivasankavitha looks like the build passed on that PR; feel free to merge/release at your convenience |
Does Also, couldn't DGS automatically detect pagination structures and auto-generate the correct paginated API for the model types? |
I'm not sure I follow what you mean by this:
You can specify that you'd like to use that class instead of the generated ones & it will put it in there. As to whether or not it deserializes correctly depends on the json library you're using.
There is no specified "correct" paginated type as GQL doesn't specify that sort of thing. There are the relay types you found, which can certainly be used, but they have some faults of their own. Namely, they won't differentiate between explicit null fields and those that are simply not requested. Left alone, the code-gen will generate the appropriate pagination structures for a client without having to involve the relay classes. |
When attempting to simply using dgs for a code generator for API clients, there aren't great solutions for generating generic pagination APIs. Each connection type is unique, and there doesn't exist a common interface for all edge/node types.
If you enable
generateKotlinClosureProjections
but also attempt to do type mapping for simple list connections, eg...Then the projection's don't get generated correctly (you lose the projections for edges), meaning you can't request paginated elements.
Overall, this results in a less than stellar experience for trying to use dgs for pure client side code
The text was updated successfully, but these errors were encountered: