Hi, some info…
- For a scrolling RG, Bubble will only load what’s needed to fill the slots on the screen, plus a few more in anticipation of the user scrolling. So you shouldn’t need an “items until” unless you want your user to have to hit a “show more” button or if you want to do a “next page” sort of thing.
- My guess is that “:items until” will apply to the whole search if you put it at the end of the expression, since expressions are read left to right. But you’d need to run a test to see.
- I did some experimentation with intersecting 2 server-side searches. The results were troubling: Bubble downloaded the ENTIRE results of each search, then finds the intersects client side (on your browser). What this means is if you have a lot of data (in the thousands), be prepared for really long waits and potential browser crashes. Here’s my post on that: Move complex search to backend - Need help / Database - Bubble Forum
- If you use an advanced filter to do the intersect, at least Bubble will only download what’s needed to fill the RG. So for example, if your RG has space for 20 records, and in order to find 20 results Bubble needs to download 200 records and run them through the advanced filter client side, then 200 records are what is being downloaded. It’s still not that scalable (OK for hundreds of records, but not for thousands), but it’s better than Bubble downloading the ENTIRE results of both searches and then doing the intersects in the browser.
My recommendation is to become familiar with the network tab in google dev tools – you can use it to see exactly what Bubble is downloading to the page under various search approaches. But the unfortunate news is that most searches that don’t fit in the standard “search for box” get kicked to the client side, and that won’t work for an app that has a lot of records.