[12.x] Allow rendering paginated data where cursor parameters are not in the response

[cosmastech]

If you attempt to render a CursorPaginator, but do not have the keys/aliases as properties on the underlying data, a warning is raised. On our production environments, this returns a 500.

Take for instance something like this:

User::query()
    ->orderBy('created_at', 'asc')
    ->cursorPaginate(10)
    ->through(function(User $user) {
        return [
            'uuid' => $user->uuid,
            'name' => $user->name,
        ];
    })
    ->toArray();

I do not want to expose the integer ID nor the created at timestamps in my response, but this will produce a warning. The reason the warning is raised is because through transforms the items, but AbstractCursorPagination::getParametersForItem() looks to find the cursor parameters as properties on the modified data.

With this PR's changes, I can now do this:

User::query()
    ->orderBy('created_at', 'asc')
    ->cursorPaginate(10)
    ->setTransformer(function(User $user) {
        return [
            'uuid' => $user->uuid,
            'name' => $user->name,
        ];
})->toArray();

This is particularly meaningful if I want to transform my data into Responsable DTOs (with something Laravel Data). While Laravel-Data does offer a paginated data collection class, it's not necessarily as easy to work with as the one that comes with the framework.
If I have a Responsable object like this:

class UserResponse extends Data
{
    public function __construct(
        public string $uuid,
        public string $name
    ) { }

    public static function fromModel(User $user): self
    {
        return new self($user->uuid, $user->name);
    }
}

Then cursor pagination will fail because there's no id field in the UserResponse.

Other possibilites

Change the through method so it does not immediately act on the collection, but instead only does it at toArray() time. This would potentially be a breaking change for users that relied on this behavior.

Additionally, the signature of through could be changed to:

public function through(callable $callback, bool $onlyBeforeRender = false)

Though this is a breaking change for anyone who has extended CursorPaginator. We could take the pseudo-argument approach where we check for a second argument being passed in, but not change the signature.

---

We could also create the cursor if one isn't set when the paginator is constructed. That could be done inside of setItems or directly after it. I am starting to think that this is cleaner.

[github-actions]

Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

[cosmastech]

note: If I were to call $p->toArray() it would produce a warning.

[cosmastech]

The more I think about this, the less I like it.

I don't like that the resulting shape of the response isn't included as part of the CursorPaginator's template. It feels like it might be cleaner to create a method to map the paginator into a new paginator, keeping the cursor values from the original.

[taylorotwell]

Closing if you don't like it. 😅

[dennisprudlo]

@cosmastech Just out of curiosity, couldn't the example use case you described be solved using either a specific "->select()" or a resource?

[cosmastech]

@cosmastech Just out of curiosity, couldn't the example use case you described be solved using either a specific "->select()" or a resource?

In the project I am working on, we have gone full-on Laravel Data, so we do not use Resources. They are not strictly typed (which has been a pain point in previous projects). Using a selective query doesn't really help unless we are just returning the Model directly, which we have avoided as a practice.