Hi, is there a way to a custom data type and its fields dynamically?
For example, I’d like Bubble to create a new custom data type based on a provided json with a definition of the fields or a sample date. Bubble is already able to identify “API Connector” call response fields:
So in my scenario, I’d like the having the option of creating a new custom data type based on those returned fields.
Is it already possible in some way?
Thanks!
Creating custom types dynamically isn’t possible, but depending on what you’re doing you could have a type called Custom and manipulate the fields so that they accept values coming in from your API. One of your fields could be a label for what the Custom type is. Just a thought - really depends though.
Thanks for the quick response. What do you mean by
manipulate the fields so that they accept values coming in from your API.
Is there any automatic way of doing it?
Well, first - what are you doing? What does your workflow look like to retrieve the API data? You can automate saving values in a lot of ways, but I need a bit more info about your specific case.
I’m calling an external api using the “Api connector”. I get a structured json response of an object with fields, for example:
{
"id": "1",
"name": "bob",
"age": 20
}
Is there a way for Bubble to identify these fields and create a custom data type accordingly by “importing” those fields?
Right, no way to do that unfortunately. In general, there’s no way to dynamically create fields. What I was describing was, for example, if you can anticipate 5 fields coming in and their field types, you can structure a data type to have:
Field 1 label (text)
Field 1 value (anticipated type)
Field 2 label (text)
Field 2 value (anticipated type)
etc.
You could save the values coming in from the API response to the value fields and have your users label them accordingly. Doesn’t sound ideal, I know, but it would give your users some amount of flexibility for viewing the data at least.
Hey there 
Nice ideas @romanmg Gaby (as usual!)…
So here’s an idea:
So we have our tables in our Databases. We can’t really dynamically name the tables right? How about this?
Imagine we are a moving company and we have 10 boxes of different sizes. The ONLY identifier on the OUTside the boxes is a number. The person in charge writes down on a clipboard, all the things that get packed into which boxes… (Clipboard-o-items = Index card)
So Try running your DB that way. Just make several tables. Call them amazing names like, Table #1, Table #2, and my personal fav: Table #3. Throw whatever content you’d like in there… Oh yeah, You’d also need a Table el numero Zero. In it, you’d write Field 1: Type of content, Field 2: Parameter 1, Field 3: Parameter 2… yada yada yada…
This way, you have a fancy index. It says which types of things populate which boxes. Oh yeah, and in each ITEM of your Table Zero, you have your field labels.
There’s already an achingly elegant execution of this concept at my lil school… A robot with access to thousands of blank boxes (just like our plainly numbered database tables)… organizing the books at a library on my campus.
Here’s where I got this idea: (Please don’t read this… I talk too much! haha) There are many more ways to configure data with this flexible concept. (Props to the robot at my school library that lives in a HUGE hole in the ground where library books are simply thrown willy nilly into a container, completely unsorted, n the bot tracks the location of everything. This way, the BOXES (ie. Table Titles in our situation) remain static, while the content is packed 'n tracked in a shiny index somewhere in Bertha’s brain. The library bot doesn’t have a name, but that doesn’t seem very kind now does it?)
sincerely,
Ashley
Ashley, I feel like you and I could be great friends.
Gaby, I agree.
I love it. This is the best thing I’ve ever read in the Bubble forums.
Also, thank you Bertha for the inspiration!
Hey Philip,
Um, I’m flabberghasted and immensely honored by your compliment. 
a huge Bubblin’ fist bump to ya bro.
It doesn’t happen often, but it seems like this might be a current limitation with Bubble depending on the use case. Having the ability to dynamically create fields is important - imagine a project management application that has various roles for various people working on specific projects (example: 10 engineers, 4 designers, 2 project managers, 20 customer support agents, 5 business developers, etc.). The company using the Bubble project management app should be able to dynamically define roles (i.e. role #1, role #2, role #3, role #4, etc.). Then, when a new role is created by the company, a separate table (or “Thing”) containing all of the projects the company is working on, automatically adds a handful of columns relevant to the new role (“role1names”, “max role 1 hours”, “role2names”, “max role 2 hours”, “role3names”, “max role 3 hours”, etc.):
Table 1: rolename
Table 2: role1users, max role 1 hours, role2users, max role 2 hours, role3users, max role 3 hours, etc.
Without being able to dynamically add/remove fields in Table 2, it seems like the only option is to predefine a maximum number of roles (ex. 20 --> …role20users, max role 20 hours). This seems horrendous if there are many columns inside of Table 2 that correlate to each role entry inside of Table 1. Any ideas?
Table 1 = Roles
Table 2 = Projects (contains an entry for role participants + 6 additional entries per role)
Table 3 = Users
Sounds like a “many-to-many” situation to me. So a Project can have many Roles, and a Role can have many Projects.
So create a new table, ProjectRole
Project : Type Project
Role : Type Role
and then your colums that relate to this project AND role
That way you can add as many as you like ?
Or am I missing something obvious ? Do you want the role attributes to be variable per role ? In which case you can repeat the same pattern.
If the need to save the data from the API in the database is for display only, you could approach this problem differently. To make it simple let’s say you want to display the data in a text field. What you could do is to set a state for the text field and assign as a value the output of your API call. This way you wouldn’t actually need to save the data in the database, but you could display the data directly in the text field by searching for the values in the state of the text field. If the values in the output of your API call changes you still receive them in the state of the text input, so you don’t need to bother the database at all!
