Earlier this answer was given for sorting
$sortedCards = $cards->sortBy(function($card ) { return $card->number; });
I don't see how this would work if thousands of results with pagination. Because in this case you already have an array of results.
You can store a collection before pagination in say a cache. Then when you trigger a sort you can resort the collection then pagination it. That way your sorting the collection before pagination get it. And redoing so with out hitting the database again and again
@jekinney so it works on a smaller resultset, but it's not good for thousands of results, is this correct?
It can be good with thousands too. Even the famous data tables JavaScript plugin sets it up server side to store the results on large sets then ajax calls the stored set for sorting and reset pagination.
The issue from my experience is grabbing to much data (* on query usually). Sorting and pagination all in one go. Then when a user clicks to sort we redo the entire process again. In stead I have had great results with caching the large queries, resetting the cache on create or update in an queued event. But only the collection. Then when it gets called to display is when I sort and paginate. And when a user clicks on a sort button it only filters the caged collection and re paginates. So all in memory and really faster then doing the whole procedure over and over.
Look at JavaScript, when it exacutes it stores all your data in memory (client side so even faster for the user) and filters that data on the fly as user input is exacuted. Imo that's the fastest way as php once it's done executing everything is dumped into garbage collection, so if you don't cache it you have to re-run the whole procedure again which obviously can be slow.
Thanks
Please or to participate in this conversation.