Actually, not only Advanced filtering is carried out client-side. There are some cases when the part that should be :filtered is too complex for Bubble to merge in 1 DB query. And in these cases even basic filter will be applied client-side. I haven’t faced such cases in my apps, but this is the info I got from Bubble support
Are you saying that Bubble support indicated that some search constraints are too complicated and so those constraints are filtered client side? What I mean there, is when filtering is done properly, the ‘filters’ are constraints put onto the Do a Search for, which all of those constraints/filters are done server side.
The only time a filter is done client side is if after the Do a Search for expression you then use the :filtered operator, and in that case, in which you use the :filtered operator, it is not just some that might happen client side, it is all that happen client side.
You can have a hidden repeating group to hold your search results from the DB, or a custom state, or use a Paid plugin like listshifter to hold onto the original search results from the DB.
Then in your RG that displays the results and incorporates pagination, you don’t use a :filtered operator, you use the :items from and :items until operators (note, this is in the event you do not use the Paid plugin ListShifter, which does actually make things easier, as the plugin has the ability to set the number of items to be displayed per page and has functions to go to next page etc.)
In my apps I use the ListShifter plugin. The more items you show on the page the longer the load…typically use pagination in such a way you use divisible by 1/2/3/4 for numbers are 12/24/36/48 etc.
In my apps I set the default value of items per page to 12, then give a dropdown to users to select the number of items per page to display in 12/24/48/96 increments, and when a user makes a change to go from 12 to 96, it is pretty snappy and the 96 items are visible almost immediately.
Hey @boston85719 we have a marketplace app that has > 500 products. Currently, we’re only using lazy loading and filtering them using daisy chain filters. We’re keen on adding pagination but so far have only agreed on creating a vanilla bubble pagination feature.
I’ve heard so much about @keith’s list shifter / floppy and I think it’s about time to ride the hype train.
Also, how much of a difference will it produce WU-wise if we were to use vanilla pagination compared to using list shifter pagination? Will it save a considerable amount of WU?
Would you be so kind to point me to the right direction on how to create a pagination feature using list shifter / floppy? I’m aware that keith’s plugin can amazingly do LOTS OF THINGS but we’re only aiming to implement the pagination feature for now. Will learn more about the other functionalities in the coming weeks or month.
Should just filter via the constrains, so much easier and better
This definitely depends on the usecase. For a simple static search, sure. For allowing users to select filters and then to stack all of those filters on top of one another dynamically, daisy chain is the way to go.
I can’t imagine how…have you tested this with a speed test using the computer and not just naked eye test?
Basically to set up a filter, it is always going to be faster via the Server, which if you put your constraints directly onto the Do a Search, will happen via the Server.
Additionally, you can use the little checkbox at the bottom of the search constraints to ignore empty constraints, so no worries at all about allowing the user to select filters and have those selected filters alter the search results immediately.
Plus, no need to run workflow actions to filter. I’m honestly not 100% sure how you guys have these set up but my assumption is there is either a new search performed on each workflow that is part of the daisy chain, or you are passing the values of one filter to another workflow action that uses the :filtered operator (which is done client side and slower than server side).
Lastly, so much easier to maintain and fix or implement new filters via the constraints as you don’t need to try and find a way to fit a new workflow action into the daisy chain, and instead just add a new constraint to the Do a Search.
I’m honestly very interested to hear how daisy chain is potentially faster than normal search constraints, or how daisy chain is easier for doing searches with filters the user selects. Always open to new ideas and improving the way I develop.
Keith isn’t known as “America’s Most Loved Bubbler” for no reason. ListShifter is scary good…and i’m a crappy programmer.
I would also strongly suggest looking into Scious Search. It’s a plugin that allows you to use server-side searching from typesense or algolia.
I would contact @zelus_pudding about getting access to the beta. It takes a bit of code to set up, but once it’s done, it’s literally like black magic. Scious + ListShifter are my fastest plugins by far.
If this marketplace scales into the thousands and more, I would strongly consider implementing scious.
Also, because it’s using server-side searching, it improved my app performance // battery life tenfold. Your browser doesn’t have to do much.