Great feature! Keep up the good work!
This is a truly great new feature. But I always wonder, has the Bubble team thoroughly tested all of the upside down and backwards way their users will use something like this? A teeny tiny understanding of data design goes a loooong way …
I am glad they implemented your suggestion. Hope it makes it easier for you guys to develop better apps!
“The reward for good work is more work.” I love how a great feature like this immediately gets the community asking for further improvements.
Hold on… can I use this for colors?
[runs to try it out on the editor]
 … and an option can have an attribute that refers to another option set.
Great feature ! Thanks
@cal one question: when you deploy to production the options are transferred with the new version or you should populate data as it happens with custom types ?
So I am trying to understand this new option. It seems like it could streamline some things for me.
I have tournament brackets in my site. I want o run tournaments with up to 64 (maybe 128) teams. My issue is that I need to create a lot of Fields for each tournament. As an example in a 32 bracket double elimination:
63 total games
Each game has (Player 1, Player 2, Player 1 Race, Player 2 Race, Player 1 Result, Player 2 Result, Table #, Stream (Y/N))
Winner (moves to new spot in bracket)
Loser (moves to new spot in bracket if 0 losses)
I am sure there i more I am leaving out.
So my question does this new Option Set give me the ability to simplify my Data structure in anyway or do I just need to build massive Data Types with tons of Fields for the larger brackets?
The options are transferred with the new version.
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?
- I guess it gets pushed to live automatically so that saves having to push it from test to live (or forgetting to)
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.
See this thread for more reasons Option Sets are awesome.
Does this do the same job as BDK global variables .?
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.