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.
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 
But the change makes sense - thanks!
I noticed that the other day. It was confusing at first since there was no announcement about it yet. Thanks for clarifying now. 
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.
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
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!).
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ā.
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.
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 
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. 
Consider the followingā¦
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ā¦
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. 
I second this.
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.
@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.
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!
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!
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ā¦
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
Could also add āshould evaluate toā¦ā to the tooltip when it doesnāt match the expected type.
