My experience is that such conditions ARE faster than :count. I believe that, the way Bubble works, if you have a condition that is testing for that state, that state will evaluate to true as soon as the list being tested reaches the non-empty state. (That is, if you are evaluating :count, bubble must wait until the entire search or filter or whatever is done to establish the count. But if you’re just checking for non-zero list length it does not have to do that – as non-zero list length is established as soon as any item populates to the list.)
Note that, for certain types of things, you may have to test for list’s:first item’s some_field is not empty.
Specifically, this is an issue for lists of complex (multi-field/multi-key) data returned via the API Connector. Like if you have an API that returns a list of people and their birthdays, like:
{first name: John, last name: Smith, dob: 12/18/1972},
{first name: Jane, last name: Doe, dob: 11/04/1943},
etc.
… those things are not saveable/searchable (in Bubble parlance – see my various whines about the “API Ghetto” data type) and one side-effect of this is that a filtered list of those things cannot be evaluated at the list level, but can be evaluated at the field level.
So, in this case, you might test for something like:
API List of Things:filtered(some filter criteria)'s first name is not empty
Of course, you can do this anyway whether not you’re required to.
ONE INTERESTING THING I have noticed if you’re doing this (or have to do this because of what I describe above): There seems to be a difference in how fast various data types can be evaluated as empty!
For example, I have an API List like this that has fields like:
Start date (a date), end date (a date), description (a text)
Evaluating:
List of that Type’s:filtered:first item’s description is not empty
seems to be faster than evaluting:
List of that Type’s:filtered:first item’s start date is not empty
It’s interesting.