Is there a way to get a list of field names for a “Thing” given the “App Type” (type of Thing)?
I noticed that an App Type property in the editor’s property panel is available to a plugin as a string in the form “custom.apptype”. Can information about the structure of a Thing be retrieved using that string?
Specifically, I’d like to get the name and label for the fields comprising the Thing. I don’t need data values – just the field names (internal) and labels (user-facing).
Estoy buscando lo mismo, mi consejo es que por ahora utilices API connector y realices un get de tus datos (debes habilitarlo en settings/api)
https://myapp.bubbleapps.io/api/1.1/obj/field
https://myapp.bubbleapps.io/version-test/api/1.1/obj/field
saludos espero ayude
Also wondering about this. Bumping the thread in case anyone has solved this.
What I’m wondering about specifically is this:
This seems odd to me. If you field is “Name”, for example, you need to use “Name” with the data api. But if getting a user to specify Type/Field names, ie using the plugin to get App Type → Fields of app_type, you’ll get “name_text”, which you can’t then use to access the Data API.
Is there some other way to get the “proper” field names out via a plugin action? Or is the only way to do this by specifying specific records of that type, then using .listProperties() ?
Ohhhh…. Brilliant! I’ll check that out later. Thanks @sudsy !
Did you find a fix for this issue? I’m trying to basically fetch the data types of all the fields within the object specified by the App Type so that I can return the right kind of data. I receive null (from an API call being made in the plugin) in case these fields are empty and there’s no way to know whether it needs to be formatted as a string, as a number or an array
So you are trying to figure out given the app type what are the different types of fields used, such as text, date, number or date range?
If so, when running the get properties functions you should be receiving the field name and a prefix or maybe a suffix that would indicate what type of data field it is.
What is the use case?
That’s right
I just receive a string of the app type. For ex: If it’s an option set, on printing the property holding the app type, I get a string saying option_set.<some_value>; similarly api_connector.<some_value> for custom types and so on
I’m getting data from an external DB and the dev has an option to specify the return type. Now, when data is being returned from the DB, it returns null for those fields that are empty. Which means, null for primitive as well as arrays, jsons etc
If I publish the value, I get an error from Bubble saying that the value is not iterable. If I knew that the field is defined as a list, I can replace null values with empty arrays for those fields.
I saw that the Xano plugin too has this issue as shared by @eli on the Forum, but was wondering if there’s a way yet to do this
the api_c2 is for api connector objects, which if the data you are receiving is from an external database connected to bubble app via an API, that is not a custom data type (ie: a data type created in the Bubble database), that is instead an api object.
When you initialize an api call in api connector, as you have likely done for the api to the external DB, you will specify what type of values those correspond to within your Bubble app, which can be option sets, basic types (text, number) or plugin data types (encompasses both api connector objects and plugin objects), but it is not possible to initialize those as a custom data type (we literally do not have our custom data types as options to choose from).
When you initialize the payload can have the values properly formatted to be null of the correct type of data.
And then choose from the right dropdown what type of data it is. That is how Bubble will know when a plugin fetches a list of that type of api connector object what type of data it is.
If your source is sending just an empty string, that I believe is where the fix needs to be, which is to say that you either send in the correct form of empty values for that type of data or just know when initializing the api call and to set the value to the right type during initialization.
Once you do that, then anytime in Bubble, anywhere you use an expression to reference that type of api connector object (ie: the values coming from the external db api call) and you want to feed it into your plugin (the one you need to know the type of data for), you do not need the plugin to do the heavy lifting of figuring out what type of data is it, and instead let Bubble do it via the dynamic expression and for some types of values you’d use ‘formatted as json safe’, but unfortunately, Bubble doesn’t provide that formatting option for numbers which is a pain as we are then forced to do ridiculous things like provide a ‘inline conditional’ to determine if it is empty or not so we can use the yes/no options inputs to format with ‘null’ or the actual number (formatted as json safe for numbers should exist so that if it is empty bubble sends ‘null’).
You are saying when you use your plugin to try and fetch the data, you get an error stating the value is not iterable as in it is not an array and can not be iterated on from one item to the next? If so, that might not be the issue of the type of data being known, it might be an issue with the plugin function and how it is attempting to fetch the data.
Yes, this is what I meant. I manually insert the API response and save that by specifying the primitive types for each field in the API connector; and then pass that to the App type parameter in the plugin.
This source sends back null only when the value there is empty. If it’s populated, it’s fine which is why the below comes up
Since the array field is empty for that record, it returns null from the source (unless, ofc, I set the default value to []), and null isn’t iterable, which is why I get this error. If I knew the data types of the attributes within the App Type, I could’ve handled this as an array and published to the plugin’s state accordingly.
Have you tried reworking your code to turn all returned values into an array and publish them as list states by default? So regardless if it’s a scalar or array the state is alwqys an array. Then retrive any scalar values with first item in Bubble.
Not sure if my point is clear haha.
I’ve defined the type of the fields as singular values in Bubble via the API connector. If I return arrays, I’ll get an error saying that Bubble was expecting a string or a number but got an object
The idea is for users to define their own datatypes so I wouldn’t expect them to convert all the attributes to be a list of things tbh
I think I’m missing something here. How is the API Connector interacting with your plugin exactly?
As hinted by @boston85719, If you’re taking the returned values from an API call wouldn’t you already know the schema of the JSON you’re processing in your plugin? 
Have you tried using the listProperties() method on a user property? Pretty sure the suffixes will state what type of data each field is.
Does that work for custom data types and api objects? I am not sure but I think only fields of a custom data type have the suffixes applied to denote what type of data it is.
How are the users defining their own data types? Is this supposed to happen in your plugin or be somewhere else and provided as a field value to your plugin?
In an app or in the plugin editor?
This is from ChatGPT
In JSON,
nulland[]are not the same thing:
"key": nullmeans “there is no value here” (the value is explicitly null)."key": []means “the value here is an array, and it currently has zero elements.”If your intent is to send an empty array, you should use:
json
CopyEdit
"key": []If you send
"key": null, most JSON‐parsers will treat it as “no array at all,” not “empty array.” Usenullonly if your schema (or your receiving code) specifically allows for “no value” rather than “an empty list.”
Which from my experience is how to initialize an empty array in api connector. The screen shot I shared in previous reply with list_text(list) was initialized with "list_text": [] in order to get the key initialized as a list of text.
So, my thought here is if your source is out of your control and the source provides just null then it would likely be safe to assume it is a single string and not a list, but if the source is providing those values properly, an empty list would be []from the source and understood properly by other systems as an empty list, I think.
