Is "first item is not empty" faster than "count > 0"?

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},

… 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)


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.