@ahmedabdel3al not sure if you have seen, a similar PR #1997 has been submitted in the past.

Have a look at Caleb's comments on there.

I think for this PR to be successful, the trait must still work in the same way it did before (so those failing dusk tests should pass without any changes needed to be done to them.

I believe if you still have a $page variable in the trait, as the default, with $pageName pointing to it, that should allow it to be backwards compatible.

I would then revert the changes you made to test and insure it also passes, and instead add new tests for the custom page names.

The other thing to consider, is by adding $pageName and getPage() there is a potential for a breaking change for some users, if they have used the same property or method names in their components, they could collide. I know it won't line up neatly with the rest of the names, but potentially making them more verbose could minimise that, something like $paginationPageName and getPaginationPage().

Hope this helps!

@ahmedabdel3al not sure if you have seen, a similar PR #1997 has been submitted in the past.

Have a look at Caleb's comments on there.

I think for this PR to be successful, the trait must still work in the same way it did before (so those failing dusk tests should pass without any changes needed to be done to them.

I believe if you still have a $page variable in the trait, as the default, with $pageName pointing to it, that should allow it to be backwards compatible.

I would then revert the changes you made to test and insure it also passes, and instead add new tests for the custom page names.

The other thing to consider, is by adding $pageName and getPage() there is a potential for a breaking change for some users, if they have used the same property or method names in their components, they could collide. I know it won't line up neatly with the rest of the names, but potentially making them more verbose could minimise that, something like $paginationPageName and getPaginationPage().

Hope this helps!

thanks for your reply, but what do you suggest to fix this issue?

@ahmedsayedabdelsalam I think this PR had merit, not sure why it was closed. Just needs to change a few of the things like I suggested, to ensure it's not a breaking change.

But if you want a user-land solution, you could probably create your own pagination trait and make use of that instead of Livewire's withPagination.

Hope this helps!

thanks for your reply

@joshhanley it was closed because some dusk tests fail, we need to add the ability to live wire to override the pageName inside livewire components so we can add multiple table with pagination in the save page without conflict.

I think you've access to change things in this pr and make it works if you wish and this will be great.

@ahmedsayedabdelsalam just because they fail doesn't mean it needs to be closed 🙂 but it could probably have been marked as draft again.

Sadly, I don't have permissions do that. But I also don't personally have a need for multiple pagination in the same component.

I was offering suggestions of what could enable it to be approved and merged, so if you or anyone who has the need for this feature, could implement it and have a higher chance of it being successful. I'm happy to guide people to a solution though.

Hope this helps!

P.s. When making a PR, ensure the PR is not on the master branch in the forked repo, as @calebporzio can't edit them. For example this PR is on ahmedabdel3al:master but Caleb wouldn't be able to edit that. I'd recommend making a branch called something like ahmedabdel3al:multiple-pagination or something like that.