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
