Hi @JeffreyWay
I was struggling with a clean way to render simple or regular pagination based on user's agent type (mobile/desktop), and I'm beginning to think that Laravel got it wrong. paginate and simplePaginate is something that should happen at render time (in blade where we call links()) not in the controller, because it's a presentation thing. Right?
@mskhoshnazar no it is not only a presentation thing it is also a "query thing". The simple paginate only checks if there is a previous or next page. The "paginate()" does a count of all records to see how many pages and how many records there are in total.
If you only want next/prev in all screen sizes: simplePaginate()
If you want next/prev only on mobile but the full version with page numbers on desktops than use: paginate() and with css you hide the page numbers for small screens
@click Well then the query part should be separated from presentation part.
The paginator is currently generating all the links, and even the "...", to be rendered later using links.
I think the cleaner way is to provide some raw data about the records and then decide what to do with it either in the items object with links and simpleLinks or even in the blade template.
My point is, there should be way more control over how pagination is rendered.
For example the addition of onEachSide was a good start. But you still can't control how many pages are shown after the first page and before the last page.
@jlrdw well for some reason displaying 15 buttons at the bottom of the page in a single line breaks my layout. Even if I use onEachSide(0) it's 9 buttons and it's still a bit too long for smaller displays.
@jlrdw you need to calm down my friend :) I did look at the link you provided.
If you read the op again you might see that I'm not looking for a solution or an explanation on how if statements work in php! I'm saying Laravel's implementation of pagination can be improved, and I'll be happy to hear your thoughts about that.
Also, be kind to show me where I suggested a built-in mobile detection. If you didn't manage to find this suggestion, take the time to read my discussion with click.
@cronix of course we can customize pretty much everything. But as I explained in previous posts, I think data and presentation are not well separated here.
About onEachSide, it just changes the number of links "right next to" the current page. But you have no control over how many links are there after first page and before the last page. So it goes like this:
onEachSide(3) //default
< last 14 13 ... 10 9 8 _7_ 6 5 4 ... 3 2 first >
onEachSide(0)
< last 14 13 ... _7_ ... 3 2 first >
@jlrdw again, please calm down. as you said, many others dig into the API, and I do too when I need to.
This is not about showing off how well we know Laravel API and how we can customize things. It's about improving the out of the box behaviour and making things simpler.
If you read the op again you might see that I'm not looking for a solution or an explanation on how is statements work in php! I'm saying Laravel's implementation of pagination can be improved, and I'll be happy to hear your thoughts about that.
