Forum Academy Marketplace Showcase Pricing Features

Selecting options from a static list

Hi,
I’d like to propose an enhancement to Bubble, which is something that the competitor products I know of already have in one way or another. I have not found a way to do this, so if it already exists, please let me know.

I would like to have the functionality of a new field type, let’s call it “Option List” for lack of a better term, that contains a static list of (typically) text elements. The most important feature here would be the ability of referencing the values of the option list field within the Bubble Editor without knowing its contents in advance.

Contrast that to today’s situation: assume I have a field that typifies a record, and that the field is of type Text . (The “list” option would not be selected, because the record will be of only one type). If now I want create a constraint to show only the records of a list of things that that are of a particular type, I have to know what the options for the type are, and type the one I need exactly the same way everywhere I’m using that type. If I decide to rename the way I call one of the types, for example, I’d have to remember all the places in my application where that type is referenced, something that Bubble does not help me with.

With a field type Option List, this problem could be treated rather differently. Assume that the Option List is represented as the aggregation of 4 parts: Value (text), Description (text), Active (yes/no) and Sort Order (number or text), and that the options the field has can be referenced within the Bubble editor.

I would create a new field, let’s call it Accessibility, in a table of things and define for it the 5 options below:

And that this Accessibility field was defined as part of a table of things called RESORT, that looks something like this:
Name (text)
Capacity (number)
Phone (text)
Accessibility (option list)

The experience with an option list field type would be significantly simpler. The following example hopefully clarifies what I’m looking for.

Imagine that I’m configuring a drop down list to show the resorts that are accessible via Automobile. The table below exemplifies the experience when specifying the constraints to the search after I choose my source of data:

The big difference is in the last step, when the Bubble Editor is showing the values assigned to the Option List.

As you may imagine, I would use the other parts of the Option List field if the field is used to populate the values of a dropdown widget to define how the options would be presented in the dropdown and what message would be displayed if I hover over the option.

Most importantly, if I went to the database and changed the definition of an element in the Option List, e.g. the value of the third option from “Automobile” to “Car”, nothing would change in the constraints I created or anywhere else. My updated constraint would not become Accessibility’s value is Car.

In contrast, today, if I had a field called Accessibility , it would be a field of type Text . If now I want create a constraint to show only the records of a thing that uses a particular type of transportation methods (say Automobile), I have to know what the options are and that the option Automobile exists and that it’s spelled the way I did.I would say, somewhere in the constraint: Accessibility 's value = Automobile and I would have to type the word Automobile.

If I decide to change the name of that option and rename it “Car”, I would have to go everywhere the field is used and change that, something that’s not too easy to do, because Bubble does not tell you where the field is used.

All this said, you may be want to achieve the same effect through a different path.
Say that there is a table of things called TRANSPORTATION METHOD, and in it, value, description and sort order are fields of type text in that table.

Say that my table RESORT now looks like this:
Name (text)
Capacity (number)
Phone (text)
Accessibility (TRANSPORTATION METHOD) (static options)

Note that I added an option to indicate that the options in accessibility are a static list. This would appear below the field type drop down in the popup that allows us to select the field type, similar to the one that already exists to denote that field is a list.
The Bubble Editor would have to pick that up and know to present the values of TRANSPORTATION METHOD. My query construction may have to indicate another constraint (Active = yes) and the rest would work likewise. The order of the options during construction is candy (no pun intended) so losing it here would not be a problem.

Let me know what you think. Many thanks for a great product!

Alex

I’m fairly new, and perhaps I don’t fully understand your question, but it seems to me that you could just have a dropdown or multi dropdown to solve this problem.

Hi Robert,
I’m new too and trying to learn as much as I can.
My suggestion deals with data typification (i.e. a field that qualifies a thing in a list of things, aka a record in a table).

A drop down is a visual element and yes, you can select options using it. But what I’m suggesting is a way to have the Bubble Editor show the options in field. I believe that I can’t do that using a drop down.

Hope this clarifies. Many thanks,

Alex

Hi Alex,

I don’t have a solution for you here, but I understand what you’re asking. I’ve encountered this scenario for a few apps that contain data types with a “status” field that is a text field. This field’s value will typically only ever be one of a few different text strings like “active”, “pending”, “closed”… or another example I run into a lot… a “type” field for values “customer” , “seller” , “admin”, etc.

And you’re right, you do have to keep track of these things. I use the notes feature for this exact reason, which I believe is a common practice for development documentation anyway in this scenario and others.

I think this “option list” type is interesting because you’ve proposed an entirely new dynamic option.

You did bring up an alternate solution which I would have also suggested, and that’s to create a data type dedicated to storing your option values. My suggestion would be that the potentially variable label for that option is the “front-facing” field, but then you can have a more “permanent” description field for use within workflows. E.g. “When Thing’s Accessibility is 1” , where 1 is always 1 in workflows, but its vanity descriptor can be car or automobile or anything else at any time. That way changing the vanity field won’t create any disconnect.

Hi Gaby,
Thank you for your comments. Your suggestion of of using a (simplified) Identity field is sound: it solves the problem of slowly evolving entities where key descriptors may change over time. I think it’s a great pattern to adopt even though I still have to remember that a “1” now means “a car”. If the classification list is long (say a list of cities) it may be a bit problematic but for most cases it will do. Still, my lazy brain would love Bubble to present the descriptors as options in the Editor :slight_smile:

Btw, the statements below from my original posting is incorrect:

Using the App search tool (pic below), I can find all the instances where a particular field is used.

1 Like