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

support simple pagination #715

Merged
merged 12 commits into from
Apr 5, 2021
Merged

support simple pagination #715

merged 12 commits into from
Apr 5, 2021

Conversation

lamtranb
Copy link
Contributor

@lamtranb lamtranb commented Feb 18, 2021

Summary


Hello, as #709 questioned, I think we should support simplePagination.
As Laravel doc mentioned here: https://laravel.com/docs/8.x/pagination#simple-pagination

However, if you do not plan to show the total number of pages in your application's UI then the record count query is unnecessary.

If we have a large table then this will be a problem.

Type of change:

  • New feature (non-breaking change which adds functionality)
  • This change requires a documentation update

Checklist:

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

Copy link
Collaborator

@mfn mfn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice @lamtranb !

Approach LGTM, can you check my feedback and also add a changelog entry?

PS: should phpstsan still complain, it's fine -> I can take care of that afterwards

Thanks!

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
{
return [
'data' => [
'type' => GraphQLType::listOf(GraphQL::type($typeName)),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this field can ever return null:

Suggested change
'type' => GraphQLType::listOf(GraphQL::type($typeName)),
'type' => Type::nonNull(GraphQLType::listOf(GraphQL::type($typeName))),

Copy link
Contributor Author

@lamtranb lamtranb Apr 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Type::nonNull seems not work with ListOf. ListOf can return an empty list. I will add a new test case for this. Or you mean this?
GraphQLType::listOf(Type::nonNull(GraphQL::type($typeName)))

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question!

Type::nonNull seems not work with ListOf

Oh, but it should!

In this case I meant that the value returned by resolve cannot be null, ever, because even the closure has the typehint Collection.

This means there will always be a collection returned, never null, so wrapping the existing GraphQLType::listOf(GraphQL::type($typeName)), into non-null like GraphQLType::nonNull(GraphQLType::listOf(GraphQL::type($typeName))), should be possible!

(sorry I see in my feedback I just write Type::nonNull which is usually the alias used, but in this class it's GraphQLType, so maybe that's why it may look confusing).

ListOf can return an empty list

Exactly! But "empty list" !== "null"!

Or you mean this? GraphQLType::listOf(Type::nonNull(GraphQL::type($typeName)))

I would love to (always good to avoid null values, if possible), but I think a collection containing null values is technically allowed (however unlikely), so therefore sadly no, didn't meant this one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mfn
Thanks for taking your time to review my code.

I updated the code into this:
GraphQLType::nonNull(GraphQLType::listOf(GraphQL::type($typeName)))
The tests failed.
I checked in the file tests/Database/SelectFields/PrimaryKeyTests/PrimaryKeySimplePaginationQuery.php
/** @var SelectFields $selectFields */ $selectFields = $getSelectFields(); $selectFields->getSelect()
only return posts.id. If I remove GraphQLType::nonNull, it will return posts.id, posts.title. I think there is a bug in src/Support/SelectFields.php or miss check somewhere. Can you help me? I'm not familiar with this. Thanks very much.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I've no idea.

I don't consider it a showstopper and I also didn't write the existing PaginationType which works exactly the same way, so I actually do feel bad for side-tracking this 😞

src/Support/SimplePaginationType.php Outdated Show resolved Hide resolved
src/Support/SimplePaginationType.php Outdated Show resolved Hide resolved
lamtranb and others added 8 commits April 4, 2021 22:58
Co-authored-by: Markus Podar <markus@fischer.name>
Co-authored-by: Markus Podar <markus@fischer.name>
Co-authored-by: Markus Podar <markus@fischer.name>
Co-authored-by: Markus Podar <markus@fischer.name>
Co-authored-by: Markus Podar <markus@fischer.name>
Copy link
Collaborator

@mfn mfn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From #715 (comment)

Anonymous function never returns null so it can be removed from the return typehint.

I guess the framework code itself is contradicting, see https://github.com/laravel/framework/blob/6319d94ccaf8169b103813a82139814573ddef09/src/Illuminate/Pagination/AbstractPaginator.php#L321-L325

    /**
     * Get the number of the first item in the slice.
     *
     * @return int
     */
    public function firstItem()
    {
        return count($this->items) > 0 ? ($this->currentPage - 1) * $this->perPage + 1 : null;
    }

The phpdoc (which phpstan obliges) mentions only int but in the code we clearly see it's possible to return null -> i.e. think about empty collections.

Same for to, in fact.

🤷‍♀️

Anyway, I "fixed" this one by adding it to phpstans baseline aka silencing it.

Can you look at the remaining feedback?

Thanks!

{
return [
'data' => [
'type' => GraphQLType::listOf(GraphQL::type($typeName)),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question!

Type::nonNull seems not work with ListOf

Oh, but it should!

In this case I meant that the value returned by resolve cannot be null, ever, because even the closure has the typehint Collection.

This means there will always be a collection returned, never null, so wrapping the existing GraphQLType::listOf(GraphQL::type($typeName)), into non-null like GraphQLType::nonNull(GraphQLType::listOf(GraphQL::type($typeName))), should be possible!

(sorry I see in my feedback I just write Type::nonNull which is usually the alias used, but in this class it's GraphQLType, so maybe that's why it may look confusing).

ListOf can return an empty list

Exactly! But "empty list" !== "null"!

Or you mean this? GraphQLType::listOf(Type::nonNull(GraphQL::type($typeName)))

I would love to (always good to avoid null values, if possible), but I think a collection containing null values is technically allowed (however unlikely), so therefore sadly no, didn't meant this one.

Copy link
Collaborator

@mfn mfn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you very much!

{
return [
'data' => [
'type' => GraphQLType::listOf(GraphQL::type($typeName)),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I've no idea.

I don't consider it a showstopper and I also didn't write the existing PaginationType which works exactly the same way, so I actually do feel bad for side-tracking this 😞

@mfn mfn merged commit 5013b86 into rebing:master Apr 5, 2021
@mfn
Copy link
Collaborator

mfn commented Apr 5, 2021

@mfn mfn mentioned this pull request Apr 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants