This section covers Option sets, used to store a static list of options in a database-like structure
Option sets let you set up different types of static options in a database-like structure, but without using the database. This is useful to store information like days of the week, marital status, colors, states, countries and other data that you want to load quickly and that's rarely updated.
Option sets can be used to store static options and use them around your app. In this example we have saved a list of colors as options in a set
This also means that Option sets cannot be added, edited or deleted by your users and require you to re-deploy your application before options become available in Live.
Option sets, unlike the database, are not encrypted and become a part of your application's source code. Option sets should never contain any sensitive information.
An Option set, as the name suggest, is a set containing options. To each set you can add a list of attributes that are similar to the fields on a data type. Attributes can be set to be one of the following types:
- date interval
- yes / no
- geographic address
- [other Option sets]
To summarize, each Option set consists of a collection of options that share the same attributes of one of the types above.
Just like data types, Option sets can be linked. For example, you could set up two Option sets called State and City and create an attribute on the City that links to the State option set.
In the example above, you see the Option sets on the left-hand side (1) and the attributes on that Option set on the right-hand side (2). The Display attribute is a built-in text field that identifies each option in the set.
Bubble doesn't require the value in the Display attribute to be unique, but it can still be a good idea to make sure that they are in case you need to filter the options by their Display value later. If you have duplicate values you may not get the results you want.
To create a new Option set, first access the Option set tab by going to Data - Option sets. The list on the left-hand side will be empty and showing only the New Option set box. To create a new set, provide a name and click Create.
After creating the new Option set (such as State), you can set up attributes on that set: in many cases you can use the built-in Display attribute to store the main identifier of each option. In this case this would be the name of the state, such as Massachusetts. You can create as many attributes on it as you need. For example, you could add a second text attribute containing the state code (MA).
After an Option set has been created and you have added the attributes you need to it, you can start adding the options. In an Option set like City, the options would be the different cities you want to list, such as Boston and Washington.
To create a new Option, pick the Option set you want to add it to, and type in a name in the New option field, then click Create. The name you provide will be stored in the Display field on that Option.
To edit the attributes on an Option set, click the Edit attributes link next to the Option set in the list. This is not visible until you have created at least one option. In the example above we can assign the City we have created to a State – see below on how to link the two.
To modify the attributes of an option, click the Modify attributes link in the lists of options.
You can link Option sets just like data types, by setting up the attribute on one or both of them to reflect the other. If we create an Option set called City, we can link that city to the State Option set:
In the example above, we are linking the two by:
- 1.Clicking the Create attribute button on the City Option set
- 2.Picking the State Option set from the list of available types
Just like with data types, the attribute can also be set to be a list, but this won't be necessary in the example with State and City.
When the two are linked you can use it to filter a list of Option sets (such as showing all Cities in the State of Massachusetts) or to display information in a page element, such as a text element showing Boston - Massachusetts.
Unlike Data types, you don't search for Option sets: they are all loaded on page load and you can reference them in elements and workflows as needed.
In the example below, we are using Option sets to display a list of Cities in a dropdown element.
- 1.We've set up a dropdown with the placeholder Pick a city
- 2.In the choices style we pick Dynamic choices, which lets you define the data source
- 3.In Type of choices we select the Option set Cities
- 4.In the Choices source we define what list we want to display. Note the difference between data types and option sets: we don't search for the options, we simply pick the All Cities to instruct Bubble to load all of them. If you want to filter the results, you can apply the :filtered operator after the data source, such as All Cities:filtered. In that filter you place constraints such as filtering the Cities by their State attribute.
- 5.In the Option caption setting we set which attribute to use as the option's caption in the dropdown. In our example we have saved the name of the City in the Display attribute. We could also extend it to show the City and State by expanding the expression:The example above would make each City be displaye with their State in the dropdown, such as Boston - Massachusetts.
You can also use an Option set as a data source in an expression and then filter or manipulate the result using operators.
In the screenshot above we are setting up a conditional expression on the dropdown element. To reference an option set, you can:
- 1.Select it from the list of options that appear at the top of the dropdown. Bubble knows that the Option set is City since we are referring to the value of the dropdown (which is set to be a City)
- 2.You can use the Get an option data source to access all Option sets and use operators to find the right value
... are part of your app's codebase and are cached in the user's device
... are part of your app's database and need to be fetched from Bubble's server every time
... are unencrypted and should not contain any sensitive info
... are encrypted can store private data
... are not protected by Privacy Rules
... are protected by Privacy Rules
... can link to other Option sets
... can also link to Option sets
... cannot link to a data type
... can link to another data type
... cannot be edited by your app's users
... can be edited by your app's users
... needs to be deployed for changes to be visible
... are dynamic and any changes are immediately visible
... can be referenced directly in an expression (such as referencing the Boston option without having to search for it)
... can only be referenced by way of a search or a field on another data type
To summarize, Option sets are insecure, static values that can only be changed by the app developer and data types are secure, dynamic values that can be changed by any user with access.
All Option sets are downloaded on all pages (or the cached file is used if the file has already been downloaded to the User's device). This means two things:
- To avoid having to download a lot of data, you shouldn't let your collection of Option sets grow too big
- You should never store any sensitive information in an Option set, even if it's not in use on the page, as it's still part of your app's source code file
You don't search for Option sets in the same way as data types, since they are already downloaded the user's device and not part of the database. You can list and filter Option set options or reference one option directly without having to search for it. You can read more about that here.
Filtering is done client-side