Custom State list :plusitem when item is not (yet) in the database

Suppose I have a Custom State which is a list of Foos.
Suppose Foo data type is a date, a text and an amount.

Now I have input fields (date, text, amount) and I want to :plusitem my Custom State with a new Foo made of the input fields values .
(But I don’t want to create a new Foo record in my database at this stage).

Did not find a way to do this …:thinking:
(Works when Custom State is a list of single data, because you can :plusitem a input field value)

1 Like

You are right. When it is a data type rather than a primitive (text, number etc.), it doesn’t store in a custom state without DB persistence.

One way to overcome is to store the custom state list as text and each of these are a part of one single text separated by something (date|text|amount). Of course, this would create problems while actually creating them in DB and parsing it :slight_smile:


Thanks for your insight.
So there is no clean way of doing this ?

1 Like

I couldn’t find one. Maybe other more experienced bubblers know one? @mikeloc @boston85719 @adamhholmes

This is something I’ve struggled with for quite a while myself. You can use plugins like Floppy to create lists for each of your inputs. So in your case you’d have a list of dates, a list of texts and a list of amounts. When the user saves you can then create a recursive workflow to save item #N on each of these lists to a new thing. A few years ago when the Bubble DB was slower this made sense, but now I simply create new things in my database as my users do and mark them temporary using a boolean field (yes/no). If the user cancels instead of saves I just delete the temporary items. You can then create a scheduled workflow to cleanup any remaining temporary items after X days/hours. Obviously this all depends on how sensitive your app is to WU. If a lot of your users are creating lists and abandoning them this might be too costly for you.


An approach could be:

  • The date, the text and the amount will be for all effect and purposes handled as texts in the data base. Meaning the the list of Foos will be a list of texts
  • When a date is stored it is stored as a text (and added or removed to the foo list of texts) that will be later converted, when needed, as a number to be able to be handled as a UNIX timestamp. You can download one of the many UNIX conversion plugins that convert a number over to UNIX since Bubble does not have this action. Bubble does have an operator to :extract the UNIX timestamp from a date. You will recognize your unix timestamps because they have 13 characters.
  • When a number is stored it will be stored as a text (and added or removed to the foo list of texts) and later converted to a number using the :convert to number operator. Since it is stored as a text you can start your textNumbers with a zero and remove it while you are converting it from a text using the :truncated to 1 operator
  • When a text is stored … well it will added or removed to the foo list of texts :slight_smile:
  • You add or remove one text at a time from your foo list of texts … and deal with each accordingly.

Thanks for this.

Cmarchan : ok, but I took Foo as an example. My real Foo is somewhat more complicated, and this might work in the end but will be ugly …

blazej1 : I came more or less to the same bloating propect of creating a temporary record and swap / delete depending on the user validating or canceling.

I’m baffled such a simple thing is not possible without getting dirty …

Simple, if at no other stage you want to create a Foo. If at a later stage you want to create a Foo it becomes a bit more complicated.

To only focus on the main part of this situation, which is how to load a custom state with a list of Foo’s date, text and amount and allow a user input fields to add to the list of dates, texts and amounts without a need to create an entry of a new Foo in the DB.

3 Custom States; all 3 are a lists. 1 is of type text, 1 is of type date and 1 is of type number.

When you want to load the existing Foos from the DB into the custom states, if you want to have one source to reference instead of separate searches, then have a 4th custom state which is simply a list of Foos. When page loads, set the custom state of list of Foos with your search of the DB for all existing Foos.

Then once that custom state is loaded, to set the values of the other 3 custom states, for the text, reference the custom state list of Foos each items Text…for the custom state of date, reference the custom state list of Foos each items date, and same concept for the list of amounts.

Now, you have custom states that hold the relevant values associated with Foos from the DB.

Then when a user presses a button to load the values from their input elements, simply set the custom state values as such.

Custom state list of texts set value to custom state list of texts plus item input text value

Custom State list of dates set value to custom state list of dates plus item date pickers value

Custom State list of amounts set value to custom state list of amounts plus item input amounts value

Now, if you want to take those values and create a new Foo in the database…it’s dirty.

This will only keep unique text values, if there is any duplicate, it won’t keep it. Same for others. After some time, the three lists will have different counts :slight_smile:

Yeah, seems like once we set the custom state value with the list from the DB, that can contain the same text twice, it works, but the moment you run a workflow action to set the state, Bubble removes duplicates.

Bubble also doesn’t provide the operators that would be needed everywhere to achieve this, so we can not access the Do a Search list of things and format as text, we have no access to ‘this things item #’ so we can not add values to beginning of the name such as {1}RED, {2}RED…because of lack of access to operators within the format as text operator after a Do a Search for thing. One way around it is to add to the DB a field that is list item # and incorporate that into the setup.