Forum Academy Marketplace Showcase Pricing Features

Built in way to define categorical data types

Idea
#6

But not in the editor, which is what I think @zelus_pudding is going on about.

This is easy in one’s app, but there’s no macro type functions in the editor.

ZP’s suggestion is very similar to other ideas like having an expressions palette, etc, where one could paste and store hard-to-build, but frequently used, expressions specific to the development of one’s app.

(Faye has a similar one that was specifically about colors, but the general case here is that the editor has no facility to let you make app-specific shortcuts and stuff that would greatly speed development in some cases.)

1 Like
#7

Far too complex for something that should be easy for Bubble to do. I’d much rather @Bubble implements it the way @zelus_pudding has suggested. It would make a huge difference.

#8

The use case is to “categorize a user”. It doesn’t get much simpler than what I show in the video below. This is common database design.

You can play with it here: https://bubble.io/page?type=page&name=category_as_data_type&version=test&id=forumapp3&tab=tabs-3

#9

Nope it’s too long for me to setup. You’re better off creating notes on the datafield with the listed values and then copying and pasting them into your conditions (which is what I’m currently doing). That method has taken you at least 2 minutes to setup.

#10

Not sure what you’re going on about, but the OP asked how to categorize a user without the chance of making typos as you might in a text field. The way to resolve this is to make the “values” live in a database table and reference that table from any other table as a field.

#11

This is the original discussion for some context.

#12

What I provided is still the answer. You were on the rigth track for what @zelus_pudding wanted, but you made your field of type “text” instead of of type “category” – which actually means it references another table so there’s no chance of incorrectly typing something like “yEs” or “nO”, since Yes and No are already defined in your database table as “Yes” and "No.

#13

I’m not disputing that you’ve got a solution, I’m merely stating that having to create several tables and preloading several entries of data is time consuming. It would be much better (certainly for development speed) for Bubble to implement a boolean style feature directly in the editor.

#14

Again, ZP is talking about the editor. What he’s asking for is the equivalent of autocomplete in a code editor, basically.

But in the app side, creating system variables is where it’s at. In a sophisticated app, one will have many such things that you use as dropdown values, important constants, etc. Only you the admin will create them. Users will just consume them. To speed creation of such things, you might build admin interfaces for such things rather than doing it with the suboptimal capabilities of the Data tab.

1 Like
#15

I agree with the original poster, this would be much simpler and potentially safer (as in idiot proof, not security) than storing the Text values in the Notes section, which is what I commonly do.

Webflow does a good job with this exact scenario

3 Likes
#16

So basically you want the editor to read from your Data Type content. What if your data type has 100000 elements?

1 Like
#17

If I’m understanding your point correctly:

The editor wouldn’t nicely support 100,000 elements (from both the UX perspective in that it’s hard to pick from that many drop down elements and tech perspective in that having that many drop down elements could slow down or crash the editor)

I agree, there would be problems with supporting 100k categories.

Reasonable APIs typically don’t have more than, hmmm, let’s say 30 categories that they juggle internally for any given resource. Here are some of the most egregious examples I could find from 3 developer friendly APIs

  1. Google My Business - no more than 5 categories

  2. Github - no more than 11

  3. Stripe - no more than 13

So the path forward is to decide on a reasonable upper limit of categories - may I suggest 15 or 20 - to where if you can’t make it work for your application, you’re just going to have to make do with 14 or 19 specific categories plus a last one for catchall. For anything remotely near the hundreds of categories nothing would change… and if you really need to work intensely with that many categories you’d be better off making a python lambda function that leveraged pandas.categories.

#18

I think it justs adds constraints where they are not needed because what if I need 50 categories because I really need them.

Anyway, I do not have the problem of mistyping because I build categories based on numeric IDs/codes and not names. Sure those categories have a name field also but that is just for end users of the app.

All the logic is built around status 1, status 2 and status 3. Or user type 1 or user type 2. Yes those categories probably have names also, status active, status obsolete or status inactive. User standard and user admin.

But I can’t mistype admin as admino because for me it’s just a 1. Obviously if I write a “45” where I should write “1” it’s completely my fault for not paying the right attention.

Also another good thing of using IDs in the logic of the app and not names is that if I want to change the category name from inactive to Inactive I don’t have to go and change every single condition or expression.

Use Bubble Data Types for categories with at least 2 fields(Id and title/name/description) and use those IDs in Bubble expressions.

3 Likes
#19

That’s totally doable as well Jon. But there’s a really good reason why API’s from Google, Github and Stripe make these statuses textual - it’s readable and reasonable. 1 is arbitrary requires_payment_method is not. And this requested functionality doesn’t add constraints. You’d still be free to do it as you do now.

There’d also be nothing stopping one from chaining two or more categorical data types together to trigger unique app logic. For example, one could check the values of two categorical field types (@ 15 options) to trigger up to 15 ^ 2 = 225 unique workflows. At 3 data fields that could trigger 15 ^ 3 = 3375 unique workflows, etc.

By the way thank you for the polite discourse :slight_smile:

1 Like
#20

I agree completely. But those statuses are consumed by you and I, end users of the API. For Goggle and Stripe developers they are probably using an ID.

That’s what I meant with using IDs and Names. IDs for internal use(Bubble developers) and names for consumers(my users).

I follow that approach and it’s not mutually exclusive indeed with your proposal. Just sharing my strategy :slight_smile:

I do see some added value in your proposal in any case :slight_smile:

1 Like
#21

Adding this feature will not prevent anyone from doing it the way they were doing it before. All the workarounds I’ve seen so far are either time consuming or complex. The method you mentioned may only work for a few (certainly not me) because it can be very confusing - especially in larger, more complex applications.

#22

Hi ,
I posted a very similar request to Bubble more than a year ago.

I think there has been no action on it.

1 Like
#23

This is spot on Alex! Maybe heart the my original post as well as Neerja’s to help the bubble team gauge community interest.

#24

@neerja any updates on this? Am aching for enumerated types.

EDIT*: Is neerja still with bubble? Her account doesn’t seem to be valid anymore

[New Feature] Option sets
#25

@cal and the other Bubble engineers have saved us :slight_smile: we can now do this with Option Sets

2 Likes