Add nodes field

[kervin5]

There may be instances in which a nodes field is expected in a connection field of a schema. This could also be useful in scenarios in which having access to the nodes field can be a little more practical on the frontend to make the code less verbose.

With this change, I'm proposing the addition of a nodes attribute as part of the object returned by findManyCursorConnection. Making the integration with plugins such as Nexus relay connection even easier.

Thank you for all the great work put into this package!

[queicherius]

Appreciate the PR! Looks good to me, going to be in the next minor release.

[queicherius]

Released as 2.2.0

[jonasschultheiss]

For my usecase it's unnecessary to have both nodes and edges. can I opt out of having these nodes?

[queicherius]

For my usecase it's unnecessary to have both nodes and edges. can I opt out of having these nodes?

What is your use-case, do you just pass the response back as-is? With GraphQL usually the response only consists of the defined fields, so if you don't add those to your schema the user cant request them.

[jonasschultheiss]

I use this library in various rest services. I know, that it is mainly made for graphql but this lib was recommended in an official resource.
I followed these resource when I started to implement our services:

• https://www.youtube.com/watch?v=mmbd5hcQUaY
• https://pris.ly/day2021-nestjs

[queicherius]

I use this library in various rest services. I know, that it is mainly made for graphql but this lib was recommended in an official resource. I followed these resource when I started to implement our services:

Interesting, thank you for the context!

Would a hasNodes: false option that turns nodes into an empty array work for you? This would be the easiest for maintenance, because completely removing the nodes requires a different type based on a deep option.

Alternatively you could run delete result.nodes before returning the result, but this would require an extra wrapper function on your end.

[jonasschultheiss]

Well, yes. But it's still a bit weird to have an empty unused prop on the return type.
How about you make this a low priority issue and I'll use the delete keyword in the meantime?

This isn't a big issue and I don't want to annoy you with a rest usecase for a graphql library. I'd be happy if the deep option would be implemented in the long run.

[queicherius]

Well, yes. But it's still a bit weird to have an empty unused prop on the return type.
How about you make this a low priority issue and I'll use the delete keyword in the meantime?

Sounds good, moved into an issue: #447