Add support for non null type in pagination type

[jacobdekeizer]

Summary

• Add support for non nullable data in the pagination type.
• Fixes NonNull type for data in pagination and NonNull ListOf type #872
• Based on a previous PR by @do6po: Fix for non-null data list inside pagination type; #878

---

Type of change:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Misc. change (internal, infrastructure, maintenance, etc.)

Checklist:

• Existing tests have been adapted and/or new tests have been added
• Add a CHANGELOG.md entry
• Update the README.md
• Code style has been fixed via composer fix-style

[sforward]

Maybe a better solution is to make the type of the data field in PaginationType::getPaginationFields non-null?

[jacobdekeizer]

@sforward Yes, but in theory that is a breaking change. Maybe we can change that as default for the next major release. I've currently done the same in my own project by changing the 'pagination_type' in the graphql config file to my own pagination type with non null values.

Regardless of changing the pagination type or by providing the non null types in the query class we still have to use $fieldType->getWrappedType(true) in the SelectFields class, otherwise getSelectFields()->getSelect() in the resolve method doesn't work correctly (which is covered by the tests in this pr).

[99linesofcode]

@jacobdekeizer Since the type will become stricter I don't really see how this will break anything downstream.

Upstream, Laravel's Paginator returns a collection which will always be of type array. Never null. That has been the case since the getCollection() was introduced. In light of that, the return type of PaginationType is simply incorrect.

[mfn]

I can't make sense of the changes proposed in this PR, certainly not the methods touched in the GraphQL class.

I agree with @99linesofcode : the GraphQL types are wrong IMHO too.

They are a breaking change, because from one update to another in the 8.x branch the types change and could break further systems (practical example: sync the types to frontend code which generates Typescript types etc.).

I'm closing the PR because the approach taken here does not feel correct and any type changes need to go into master.

[mfn]

Here's my take on it, let me know what you think -> #1033