Maybe I am missing something, but it doesn’t seem like there is an easy way of returning nested data to a user when building a plugin.
It would be useful if in a plugin we could define data types similar to the data tab and then actually set the data when building the plugin.
Any plugin builders have a standard way of doing this?
Server or client side action? If client sided, using an element? And can you tell more about what you want to achieve?
Client side and yeah likely using an element.
The most basic example I could think of would be an plugin that wants to return a list of contacts. There would be a list of contacts and each contact would have a name, phone number, etc.
It would be pretty cool if we could define contact in the plugin editor and the fields that are part of the contact. Then when a bubble app has the plugin installed you could reference the element and the fields of the plugin similar to how we currently reference data in the bubble database.
Have you considered using states? Through instance.publishState you can run some javascript action and then publishing a value to the element state, thus making it accessible to the app maker.
Yeah, that’d be great. Perhaps a simple text field for defining a JSON object would suffice. Then, in the Bubble editor, the user could navigate the object properties just like a built-in data type - e.g. “Contact’s Vehicle’s Model”.
Seems it’d be useful for any plugin that wants to expose data which doesn’t need to be saved in the Bubble DB.
It’s similar to what I inquired about here. All I needed at the time was an associative array, but being able to construct an arbitrary hierarchy would be better. Even being limited to primitive data types (for the object properties) would be fine.
Yes, that’s exactly what I’m trying to achieve. I wanted an element of my plugin to publish a list of structured data types, it could be JSON to be a data source of a repeating group. I don’t think ot can be done with publishState right @vini_brito?
I see there are two things going on here, one about publishing a list and another about programmatically creating key value pairs… well, for the first one we can use the returnfeature from a server side action and then return a single or a list of key value pair(s), with the value of a key being a primitive and also each value can be a list, check it out:
Can be a single value
Can be a list
Can be any primitive
They’ll be available as “Result of step X” in the workflow, solving @marcelo’s demand.
Since we can’t loop to create a key through our code, only by clicking that button in the plugin editor, the first won’t happen, but the current solution is already pretty good, I believe that there’s a workaround to @sudsy’s issue through this one, since you can pass lists too.
Thanks, @vini_brito. I’ve done similar with SSA, but what I need is a way to expose internally-generated structured data through a published state client-side. Or maybe I’m misunderstanding what you’re proposing?
You’re getting it right.
It seems like there could be a tool similar to defining custom data in the API connector.
We could give it a sample JSON response and those data types would appear in the apps using the plugin?
That’s pretty much what I was thinking.
So Bubble allowing us to structure the app’s database via plugin installations. Hmmm… 
That would be interesting! I’m sold on it 
This wouldn’t be very Bubbly don’t you think? Why not allow that as a WF action?
If you need to run it from a plugin you could fire anevent and run the action.
No, it feels Bubbly because it happens automagically. You install, bam, everything in place.
Anyway, via workflows would be great too! Also quite Bubbly.
Well, Bubble does not let us modify the database via a plugin so none of this is Bubbly at the moment. Things (custom data types) exist only the database and must be defined by the programmer user.
Also, you can’t create a Thing in a plugin (as Things do not exist in the abstract – this is where the “data type” analogy breaks down, I guess), so you can never return a newly-minted Thing, even if you do know its fields. All we can do is stuff like “given a list of Things, return some individual Thing(s)”.
This is kind of a buzzkill, but to allow this opens the door to Bubble malware. (If we can create Things, we can flood the database with Things. If we can modify Things, we can change all User’s names to “Butty McButtface”. If we can delete Things, we can wipe the database.)
Aside: I greatly desire such features. 
Well we wouldn’t need access to create things in the database or modify the things or data types the user has set.
All I am asking for is similar to accessing data from an API, nested data could appear in the dynamic data fields of the bubble editor.
Hi @vini_brito. Thanks for the response, but what I need is a client way of doing that. It would be awesome if Bubble recognized a javascript Object as a data structure just as it does with text, date, number, etc, so I publish a state with a list of Object(s) and access them in a Repeating Group
@marcelo It would. Just yesterday I was thinking on how we could make our apps much faster with client side objects/things… I’ve tinkered a lot in the past weeks with performance optimization and client side objects would be a godsend!
I feel like this feature is a must-have.
What about being able to achieve something similar to the SQL Connector plugin? It creates “things” according to the parameters and/or returned fields. These things aren’t declared in the Bubble database, but are still usable everywhere in the app.
Is it because that the plugin’s made by the Bubble team that we can’t seem to reproduce something similar?
