Improving Performance: Allowing Assignment of Expressions to a State

Hey Team Bubble…

I know performance is at the top of your list of priorities at the moment. It is mine too as my app gets more complex, and I want to make the maximum use of States to help this. However States are very limited as they can only be assigned a value and not an expression.

** EDIT **
What I am really saying, is that you do not get repeated access to the nice little blue “Insert Dynamic Data” option in the Set State action that we have when assigning to fields, text boxes, etc. Which means, as far as I can see, you can’t do text concatenation, which is what I have been wishing to do. From a Bubble usability point of view, it also feels like an inconsistency.
** END EDIT **

How easily can you remove this restriction for us? It would be really helpful. :slight_smile:

Thanks for all your work to support your growing army of Bubblers,



So there are 2 ways of achieving this:

  1. Use a group instead of custom state. There you can assign a expression in data. The limitation is that the group is accessible only from its parent element and not from within a reusable.
  2. Use the env variable plugin. Simply check the box ‘Set this variable automatically’ and put in your expression. Can be accessed from anywhere.
1 Like

Hi there @gaurav - thanks for your Sunday afternoon response!

  1. I’m not clear what you mean by “use a group”. Could you explain this in more detail please?

  2. Yes, I see you have just created this plugin, which sounds cool. However as I will be supporting many many users when my app launches, I have made the strategic decision to be dependent on as few other developers as possible, so I will only be using someone else’s plugin if I absolutely need to.

I’m really looking for a good solution from Bubble! :slight_smile:

1 Like

Basically you can create a empty group that’s super small and define the data type and content just like custom state. In that content field there’s no restriction around expressions.

Sure, although I’m not sure what you mean by depending on other developers. Once a plugin is published a developer can never pull it back from you. You’ll always have access to the varying versions published.

1 Like

Option 1 has a caveat if you’re already in a parent group passing data to the elements. Adding and intermediate group will stop you from passing the parent’s group data to the elements, if you want to add an expression.

Why does the group need to be an intermediate group?
It can be placed in any corner of a page

So it’s not required that the elements be children of the group?

Nope its not

Just tried and it works well! Thanks!
Just a few gotchas:

  • it can’t store a list
  • it can be as small as you want, but interferes with responsiveness

In any case, its a very useful trick

For list, either use the Easylist element from bdk utilities plugin, or use a repeating group in similar fashion.
The trick to address responsiveness is to make the minimum width zero and place the element with x=0 (and y=0 if you’d like that too). I usually have a group in my app which is hidden but solely is used to hold all such elements


I’ll test that too. It would be like having functions, super useful

Custom states can be defined as lists as well, BTW.

Not dynamic lists

Not true… this is what plus item / minus item are for (I think there’s also an :add and :remove list version of those operators, too). Just like you can do a = a+1 if a is an int (but currently empty), you can also do a_list = a_list:add item another_item (even if a_list is empty). That’s the reason for these (what may seem mysterious) list operators. See my video about Amazon Product API – see around the 16 minute mark here:

Edit: some further info. I did just go suss this out and (as in RGs) custom states that are lists have :plus item and :minus item (basically push and pop a single element of the correct type), but do not have operators called “:plus list” / “:minus list” feature.

HOWEVER, you will note that merged with is available in such expressions. So that’s the equivalent of a “:plus list” item (which, in the typical Bubble way, would not allow dupes).

ALSO, :filtered by Advanced is available… so you can use that as a proxy for “:minus list”.

So, if you have some-list-of-texts (for example) and some-other-list-of-texts, you can do:

“Add one item to the list” (to subtract one item use :minus item):

“Add one list to another”:

“Subtract items from another list from current list”:

The nomenclature is obtuse, but the functionality is there!

Of course all of this is possible in workflows. If you’re setting it everytime using a workflow action the whole discussion is moot.

I believe the entire conversation above was about using dynamic expressions in the spot where you define custom state.

You mean the state’s Default Value? Well there’s a good reason that can’t be dynamic. The default is stored in the editor. So it can only be a stringified representation.

Yes precisely. That’s what the original question was about. Hence my suggestion of using an empty group or repeating group to make life easier in those situations.

OK, now that I “get” what @antony suggesting (which is NOT obvious from the original Idea post), I will agree that there are times when one desires the ability to construct an expression in the “Default” field. (This would be helpful when using custom states to initialize values in a reusable element, for example.)

But I want to stress to @antony (in case he doesn’t realize), that of course custom states can hold any sort of value and in the “Set State” operation, one has access to any expression that one can build anyplace else. (Just because the default field is not an expression editor sort of field, does NOT imply that custom states cannot hold expressions/dynamic values.)

I’ve written a ton about this and all of it is too subtle to share in text. I guess I’ll have to make a video, but the long-story-short version is: “Don’t get wound up about this. If you need to initialize a custom state, just do that on page load. It’s not a big deal. Custom states’ values and Groups’ data source fields are essentially the same, but they are designed for different purposes and have slightly different interfaces. Relax.”

Hey there @keith and @gaurav

Wow, thanks for all your input to this post! It started out as a simple enhancement request and has turned into some pretty detailed debate. It’s great we have this place to share all our views.

As the originator of the post, here are my thoughts and replies to your comments:

Firstly, I was talking about the abilities we have in the Set State action, not in the Default Value field. However, I very loosely described how you can’t set “an expression”, which as you say @keith, is not strictly true. I apologise for that lack of clarity. What I am really saying, is that you do not get repeated access to the nice little blue “Insert Dynamic Data” option that we have when assigning to fields, text boxes, etc. Which means, as far as I can see, you can’t do text concatenation, which is what I have been wishing to do. From a Bubble usability point of view, it also feels like an inconsistency.

Some more feedback to you both individually…


Thanks sooo much for all your ideas. I like the idea of using the group, and I will work with that while we have the limitation on how we can assign to states.

Regarding plugins… I am developing a product which will sell to thousands of small organisations whose entire business will depend on the reliability of what I offer every moment of every day for, well lets say, at least the next 10 years. Hence I will only use technology at the core of my app which I feel I can totally rely on for that time period. It is a big leap of faith to put that trust into Bubble, and I’m not willing right now to also put that faith into plugin builders, as I don’t know if they are in for that kind of long term ride. I hope you can understand that.


Thanks for your input too, for clarifying how the “:operation” type of operators can be used, as it is easy to forget they are there and how useful they can be. Also, thanks for for helping me to see my imprecise wording in the original post.

I do sometimes find an irritation arise in me when I read your words, and I want to share this with you as I feel it important to give this kind of feedback… I think it is around you using such phrases as “don’t get wound up about this”, and “relax”. I would really value the content on here being focused on Bubble.

Best wishes for a wonderful 2019 with Bubble,
Antony. :slight_smile:

Ofcourse I totally understand. Wasn’t trying to push plugins. Was just sharing from experience the utility of groups and repeating groups when used in unconventional ways :smiley: Learnt this first-hand having built a lot of apps.

Btw, for a compilation of learnings I highly recommend you check out the best practices of developing a bubble app from Airdev. Could go a long way in building a scalable app. Good luck :smiley: