I have a an array of 6 items: [0,1,2,3,4,5] paginated using a connection field.
The user requests first: 3, and my nodes() function returns [0,1,2,3]. (1 extra, as described in the docs). and the user gets [0,1,2] as promised.
The user then requests first: 3, after: cursor:2, I return [3,4,5] (the +1 extra is missing, indicating that there is no next page, and should return hasNextPage: false, yet nexus returns hasNextPage: true.
I'm using the latest version:
"nexus": "^0.12.0-rc.13",
Configure who to be optional?
my code:
```export const allAppsQuery = queryField(t => {
t.connectionField('allApps', {
type: 'App',
additionalArgs: {
status: arg({
type: 'Boolean',
description: 'Returns only elenents with status blah',
required: false,
}),
},
extendConnection: t => {
t.int('totalCount', () => APPS.length);
},
nodes(_, { after, first }) {
const offset = after ? Number(after) + 1 : 0;
const results = APPS.slice(offset, offset + first + 1); // return +1 because nodes() require it
console.log(results);
return results;
},
});
});
```
I believe the issue is the >= in this line ought to be >: https://github.com/prisma-labs/nexus/blob/develop/src/plugins/connectionPlugin.ts#L830
The documentation also refers to a non-existent option, assumeExactNodeCount: https://github.com/prisma-labs/nexus/blob/develop/src/plugins/connectionPlugin.ts#L213
You should use a custom pageInfoFromNodes to determine the pageInfo based on how you prefer it to work. The >= is an intentional tradeoff for typical APIs where you're fetching the amount of rows you want given the pagination args, rather than amount + 1 just to fulfill the hasNextPage.
Agree the assumeExactNodeCount should also be removed from the commends - initially I had it, but realized it was probably too many options, when really we should encourage you just specify how you want it to work via pageInfoFromNodes.
As the current behaviour is a patch for legacy API, shouldn't you make than an opt-in and have the "correct" behaviour be the default? It seems excessive to have to implement pageInfoFromNodes.
@tgriesser is there any willingness to reconsider this decision? Making compatibility with legacy (REST) API the default behaviour at the expense of the "happy path" feels like an unfortunate tradeoff and will make usage much more verbose for simple cases.
Yes, I think I'm fine with making this change. Will take a look at merging #394 soon, just have been busy with some other things lately.
Most helpful comment
@tgriesser is there any willingness to reconsider this decision? Making compatibility with legacy (REST) API the default behaviour at the expense of the "happy path" feels like an unfortunate tradeoff and will make usage much more verbose for simple cases.