I wonder if I am missing something? So what is the difference between this and doing what I guess we are already doing which is creating these options in a DB table and then doing a search for?
Is this a quicker lookup rather than a search for? My guess is not as this is still sat in the DB somewhere?
These options are downloaded to the browser on page load and are always immediate. They aren’t searched from the database. Which is why they say you shouldn’t put anything private in those options, as there is no way to keep this information private.
I’m my app this works well. I have buttons which are dynamic and needed to be searched in the DB each time the page was loaded. Now there will be no DB search to generate these buttons. This will speed up my app considerably.
This can keep other things like days of the week, cities, categories, and such.
Thanks Troy that makes sense - speed - we like speed
Hi @cal Thank you, but I’d really love if Bubble was faster when our apps search for private & secure data, as opposed to a new un-secure option. On the other hand, I’m sure we can all appreciate something new that can possibly help people get better performance and speed from Bubble.
Does this do the same job as BDK global variables .?
Great Feature 
I don’t think so. Everytime a set is updated, you need to reload the UI. It’s strictly for static options.
Great feature, you guys have been on fire lately 
.
Just want to clarify one thing though. I’m assuming this should NOT be used for user roles; an app with user roles determines what rights and data users have access to. Hence, my understanding is that making these roles visible in the browser is risky as one can simply edit their role in-browser.
I had hoped that we could edit these values from inside our app. A use case I wanted to try:
Have an option set for SEO values and Images that can be edited in a user’s admin portal and saved in the the option set.
So, we’d have an option set called indexPageAttr
Some fields would be: SEO Title (text), SEO Description (text), Hero Image (img)
Inside admin portal users could edit the SEO Title, Description, and upload a new Hero Image.
The index page would reference the option set for its SEO tags and its hero image.
This would be better than doing a search for this data on page load.
In my testing I’m unable to edit these option sets. Is it possible to edit these values from within the app?
You can definitely use them for user privacy roles. In that case, users could not edit their own roles on the User object (unless you set up a workflow for them explicitly to do that), so you should be good. In other words, making a “Role” option set with “Admin/Non-admin” being the options achieves the same security as making an “Admin” yes/no flag.
When I said that Option sets were not private, what I meant was not that they could be changed by anyone. Only that they can be read by anyone, meaning you should not put sensitive data as an option’s attribute. You can definitely use option sets to control sensitive data on things though, and that is a good use for them.
You can’t edit option sets from within the app while it is running. In order to edit them, you must edit them from the data panel and then push a new version of your application. This is intentional, as they are made for static (unchanging) data, and if you need changing data you should use custom types instead.
Thanks, Cal -
Wondering if there are any plans to include dynamic option sets attributes or app text values.
One use case would be to allow for faster page loads with universal data.
Right now, we have to do a search:first item for a database entry to load any dynamic SEO, images, text content, etc. It takes time.
If we had this data available without search via app text or option set, we’d be able to load faster and still have dynamic control of each page’s content and SEO tags.
The point of Option Sets is that they are not dynamic. They are for values that are not going to change. They are able to be fast for that reason.
For example, a drop-down with Monday, Tuesday, Wednesday, etc. It’s highly unlikely you are going to need to insert a value for Blarfsday. So that list will be super fast, since it’s static, and doesn’t require a database.
For everything else, create a table, optimize for speed as best you can, and when that fails budget (if possible) to upgrade your plan.
Option Sets are fast, and that’s great. So are App Text records.
Do a search takes time, even for tables with one entry- even on a dedicated cluster.
Allowing apps to dynamically access and edit the attributes would open the door to dynamic page content without need to do a search on page load.
So they’ll be able to read/see the role (i.e. “admin”, “superAdmin”) but unable to change it. Gotcha 
Making them dynamic defeats its purpose and would probably make it slow. They are fast because static data is rendered and Bubble doesn’t need to query the database.
This is probably outside the scope of this feature, but it does nudge on a next idea: allow use of option sets for styles (or something like it).
What do I mean? With option sets I can now list all my app’s colors to give myself the right amount of constraints:
But in the Styles tab, where I would most need this crutch, I don’t have access to them.
Is there a way to use Option sets with multiple options?
Looks like we only can choose 1 option or them all right now.
I’m trying to give users check boxes to select multiple options. Can that be done with this new feature?
Thanks and keep up the great work!!
