When did Lists start exposing “is empty” and “is not empty” states? (And why this syntax is terrible

This is new, or at least new-ish, right?

And, while it’s useful, it’s syntactically messy, and confusing to skilled and unskilled programmers alike, is it not?

(Being able to map the items in a list to their “nullness” is great, but the syntax for that operation should not be “is empty”/“is not empty”.)

I get that the syntax is partially consistent with other list-oriented expressions. but this is one that’s gonna have to be explained over and over and over again.

“is empty” and “is not empty” should always return a scalar Boolean. So anything that returns something else should NOT be labeled with one of these special terms.

Shouldn’t the label for these be ‘s items are empty / ‘s items are not empty? At the very least, should there not be a colon in front of these to at least IMPLY that we will not get a scalar Boolean result?

Those labels would be much more in keeping with the actual nature of the operation going on (map each list item to its nullness).

I get that we don’t call out the “mappiness” of things like some_text_list:uppercase. But “is empty” and “is not empty” are Bubble for is null and is not null. Null is always null. Null is never an array of null. Null is null.

“Is empty” should not morph depending on context. “Is empty” should always resolve to yes or no. Always.

But in this case “is empty” and “is not empty” return a list of Booleans. That’s just a hat full of crazy. So on a zero-item list, these operations return ANOTHER zero-item list (which contains neither any yeses nor any no’s) and hence does not have a textual representation. This is exceedingly confusing in debugging. (Did anything happen? Who knows?)

Additionally, while it is silly to literally ask if a JavaScript object is null, it is not syntactically wrong to do so. (It’s just an operation that always returns true.)

The expression some_list is empty Is similarly silly, but ALREADY has a syntactic meaning in Bubble. If we are allowed to write this expression (and we shouldn’t be allowed to, because it’s dumb) it should resolve to no. Because that’s the correct answer to the question.

So these labels are really bad in this case.

Further, what the non-coder Bubble user wants is a quick and easy and human readable way to build application logic.

That user - and the advanced Bubble user - want rapid logic building. One of the most common things we must do with Lists is assess if they have any items in them.

“List is empty” as implemented here DOES NOT PROVIDE THAT, but any lay person or new Bubble user would assume that’s what it does.

An intermediate to advanced user might ask “what the heck does that mean?” and would likely assume that it must be a way to assess the state of a list’s having items or not and will next want to know how this compares, performance-wise, to other methods. Of course their entirely reasonable assumption will be wrong.

Some number of these will ask “what he heck does that mean?”, test it, and write this post relating how they appreciate this feature (though it seems of limited use) but pointing out that the interface for this is really misleading, even though it’s not entirely “incorrect.”

Basically, as presented, this isn’t going to make anybody happy and it’s going to cause a lot of confusion.

So “list is empty” / “list is not empty” is more of a time suck than anything else. What of easy ways to do the thing Bubblers actually want to do? (Namely, assess whether a list has items or not.)

WELL, the actual options for assessing the emptiness of a list are downright sadistic:

  • Some_list:count > 0 takes multiple clicks, plus typing to build.
  • some_list:first item… is not empty also takes multiple clicks

So, while we understand that “list is/is not empty” doesn’t do what we hoped it might, we look at the simplicity of that expression — two clicks, no typing… Damn, son — and wish for more operators like that.

It’s seriously stupid. Just add a :has items operator. Boom. Done. One click. (Don’t get me started on boolean negation in Bubble. Who thought THAT was a good idea, Vlad the Impaler? Seriously, just give us :not.)

ADDITIONALLY: An abstraction such as :has items would also have the advantage of ensuring that both inexperienced and advanced Bubble users do this common operation in the most performant way. Consider the number of times we see users do some_list:first item... is empty, unaware of the suboptimal nature of this evaluation.

Obviously, we need to be able to do the other, more granular comparisons, too, but a few QOL enhancements WRT rapid expression building would be hugely advantageous.

I don’t understand Bubble’s seeming stubbornness when it comes to offering alternative syntaxes where it makes sense. It’s like if in the next version of ECMA they said, “oh hai, we deprecated support for .map() and arrow functions because you already have FOR loops and the FUNCTION statement.”

Anyway, sorry for the rant, but Bubble nomenclature/syntax should be clear, consistent and at least give a hint about what to expect. “List is/is not empty” doesn’t fully pass any of those criteria and should really be relabeled.

2 Likes

tl;dr

  • “is empty” and “is not empty” on a list gives a list of booleans as result
    -> should be single boolean, or add :has items operator

I definitely support this.

3 Likes

Is this still the behaviour like this? It is quite a surprise. I have been using it at multiple places assuming it will return whether the list has items or not.

And if I remember right, it did resolve to a yes/no and not a list of yes/no. But now that I’ve seen this, I have to go check all the places where I have used “is empty” like this and see whether I intended it to get what I wanted or not.

And I have no idea how to do that.

Well, @mghatiya, now it’s relabeled to the much more sensible :each item is empty, which at least tells you what it does on the tin. Example from the editor and the runtime:


Runtime preview:

BTW, it still remains true that the most accurate and performant way to assess whether a list has any items in it in Bubble is:

some_list's :count > 0 (true if list has items)
some_list's :count < 1 or the equivalent some_list's :count is 0 (true if list has no items)

… even though they’re still rather a pain to compose.

Note that the commonly used :first item is empty / :first item is not empty is not accurate in every scenario.

(These expressions will work and be accurate for a simple Search for Things of Some Type, but imagine that you’re searching for some Thing that has a field Synonym on it, but not all of those Things have a value in the Synonym field… Search for Things :each item's Synonym will result in a list of Synonyms where some are populated and some are empty. Should the first Synonym in the list be empty, Search for Things :each item's Synonym :first item is not emptywould evaluate to false, but the list itself is not devoid of items.

And of course there are many other lists that we might create or be returned to us by plugins that might have empty values interspersed with non-empty values, so basically always assess a list’s emptiness by examining its count.

(This is the same thing we would do in JavaScript where arrays have a length property and we look at that to tell us if it has items or not. Additionally, in Bubble, Lists that are the result of a search have a similar length() method on them. In a plugin, this method can be used to tell us how long the list is even without inspecting any of the items.

Presumably, Bubble’s internals might also leverage this property if we do Search for Things :count (we didn’t ask for any Things, we just asked for how many Things the Search might return), but I don’t know for sure if it does that optimization or not.)

1 Like

Thanks @keith for detailed reply as always.

Yes, I do understand that checking emptiness of first item may not be the right way of checking whether list is empty or not. Thankfully I haven’t been using that I think.

I just checked and figured that in typical conditionals, List :is empty option doesn’t come and it is List: each item is empty like you said.

However, when we are doing a search for and have a constraint on a list item, we see a is empty option. I have been using it extensively I think to check whether list is empty or not. Now I wonder what it really means though. I’ll probably run some experiments to see what it is.

While we are at it, I also saw in recent past that in search for constraints, we also get <, > options for texts and option sets and I wonder how do they behave. There is no documentation on those. For option sets I intuitively thought (as discussed in some other thread too) that it might be based on sequence in the editor, but they are not. For text I intuitively thought it could be number of characters, but I haven’t tested it yet.

Oh it’s possible that simple searches have an :is empty option. Anyway there you are. None of what I did is anything you couldn’t have done for yourself. So whatever. (See how easy it is to figure stuff out?)