Forum Academy Marketplace Showcase Pricing Features

Renaming list operators with :each item

Hi everyone!

We just deployed a small change to make the Bubble language more understandable. Whenever you use list operators that apply to each item in the list, these operators will be preceded by the prefix :each item.

We decided to make this change because these operators are often confused for returning one specific thing, when they actually return a list of things. This will not change the behavior of these operators.

foreach

12 Likes

I was staring at some old expressions for something like five minutes earlier today wondering how on earth I’d managed to somehow include the previously unknown each item operator all over the place without remembering :sweat_smile:

But the change makes sense - thanks!

8 Likes

I noticed that the other day. It was confusing at first since there was no announcement about it yet. Thanks for clarifying now. :blush:

3 Likes

Thanks for the heads up, @grace.hong. I’ll take a closer look when I’m back at my machine, but glancing at your screenshot, the only thing that’s potentially less clear is what’s meant by :each item:converted to list.

:thinking:

Thanks for the note, we applied :each item here because technically :converted to list also returns a list, but I agree it is a bit repetitive. I suppose it makes it more explicit. Perhaps something to consider to deprecate later down the line. @sudsy

1 Like

Hey @grace.hong generally speaking, how easy is it for your team to rename operators? For the most part I find things pretty intuitive but I spend an exorbitant amount of time trying to wrap my head around the double negatives in this dynamic expression (especially when I’m bubbling late into the night haha!).

image

Can we easily replace “Isn’t live version” with “Development version”? Then we could have have “Development version is yes” or “Development version is no”.

6 Likes

Hey @juicebox - if you have multiple versions, you need isn’t live version. I think that’s why it’s named like this. “Is Development Version” would mean just that one branch of the app.

Hey @davidscott.pal, okay sure, but technically aren’t all other versions that aren’t live, development versions? Sure they might not be named that specifically, but they are dev versions?

Otherwise, we could have ‘Live version is yes’ or ‘Live version is no’. That would be equally as easy to understand.

1 Like

Having worked with this change for a while now, I have to say that I’m not a fan. It makes my expressions longer than they need to be, clutters the UI with overly repetitively redundant :smirk: text; and as a result, I find myself actually spending more time and mental energy creating and deciphering expressions.

In short (for me at least), it has had the opposite of the intended effect. :slightly_frowning_face:
 
 

Consider the following…

ugly-bubble-expression

Can anyone honestly say that the above is more “understandable” than…

Search for Photos Slug :split by (-) :capitalized words :find & replace :trimmed

This is not at all a contrived example, by the way. I often do multiple text processing steps in an expression, and now they’re all ugly behemoths.
 
 

Bubble already has a perfectly good (and far less obtrusive) way to discern the “type” to which an expression evaluates at any point along the expression by simply hovering the mouse over it…

expression-types

In lieu of a syntax change, perhaps more users just need to be made aware of this capability. Mind you, I’m not against changes or additions to the “language” that genuinely improve the Bubble experience. I just think this one fails to do so.

Anyway, my Christmas wish is for this “feature” to go away. :neutral_face:

10 Likes

I second this.

6 Likes

I’m inclined to agree with this. Maybe it just because it’s new, but I’ve found myself being more confused by the longer expressions, taking longer to find the one I need when (at least for me) there was nothing remotely confusing about the existing language (if you’re operating on a list then of course the result will evaluate to a list unless you specify a particular item - seems obvious to me).

I know it’s not really a big deal, but if anything I think making the visual expressions longer just makes it harder to read and understand, and therefore actually slows down development work.

2 Likes

@grace.hong, just curious to get your thoughts on my post. Is there any chance you guys will reconsider this feature?

Not only does it clutter the UI (dropdown and expressions), but it truly seems unnecessary given the “tooltips” that appear when hovering over an expression.

1 Like

This is great. Does this work for when we have created a data field that is a list of things as well?

That always seems to cause issues for students when not knowing why their dynamic expressions are red ( because it is a list but the element expects a single value ).

Hi @sudsy, yup we acknowledge it’s cluttering up dynamic expressions a bit and are testing out some potential redesigns. Will keep you updated when we release those!

1 Like

Yup, if you have a data field that is a list of things, :each item should appear before the relevant list operators.

I second this - absolutely stupid move!

My Christmas Wish is for this change to disappear - you have made it less intuitive!

1 Like

Perhaps I’m misunderstanding, but Bubble’s “type tips” (for lack of a better term) seem to provide the information necessary to “make sense” of that situation.

For example, here I am trying to stuff a list of users into an element expecting a single user

bubble-type-tip

I just don’t feel that a language change is warranted to address these kinds of situations - especially one that makes expressions more difficult to read and compose.

I have a suggestion. Maybe a language change is not needed. Instead, try making the “type tips” more conspicuous. I think they’re under-utilized and under-appreciated; and part of the reason might be that folks are looking right past them.

They’re currently colored the same as the reference links, which is white on light gray; so two strikes: 1) not a lot of contrast, and 2) they look similar to another UI element.

Try another color and/or contrast combo - something that’s conspicuous on both a dark and light background. Here’s one possibility…

And you could even make displaying them optional if expert users would prefer to disable them.

Anyway, just a suggestion.

-Steve

3 Likes

Could also add “should evaluate to…” to the tooltip when it doesn’t match the expected type.

2 Likes