It’s not pointless, and doesn’t use any more “compute time” then if it automatically created all of the records at the creation of the API initialization.
Just ignore those API data type fields in the menu for the time being, until the Bubble team verifies that they’re supposed to be there.
And you can modify the lists. You just have to go through the parent table (i.e. Calendar) to set list, add list, delete list, etc.
Hmm… Am I missing something essential about your technique for flatten/promote such items?
I’m reviewing very carefully what you first proposed. This sort of step:
… iterates iterates over a list of things returned by the API, right? I’m trying to AVOID that. In my case, if I want to “convert” the iCalFromURL Events to some parallel data type that’s in my app, I’d have to loop over all of them in this way. This takes time.
Like, we’re reading this one item from the one table and then we’re writing to the app database table and then Bubble imposes a delay before it will process the next one, etc. and so it can take lots of minutes.
This defeats the point of my API having put all the stuff into a nice list in the first place. Bubble is bad at making lists via iteration (I guess not BAD, but SLOW).
Hey K, YES, you are 100% correct about this. One can deal with the LIST. But one cannot deal with the individual objects inside it. This is what I think one should be able to do.
The individual objects are primitives or for-all-intents-and-purposes LIKE primitives.
To put a finer point on it: My API returns a list of JSON things. That list (basically a bundle of those individual things) gets associated with a field. And yeah, you can set/add/delete the ENTIRE LIST. You can also READ an individual item in the list (like Calendar’s iCal Events:item# n).
However, that’s where it ends. Let’s say I wanna modify item #n in that list. It can’t be done:
Calendar’s iCal Events:item #n’s Start (for example – and all other fields in that individual item) are READ ONLY. Because the entire object – keys AND values – is a primitive.
If you try to do this: Change item #n’s Start to item #n’s Start+days 2 (for example), the Issue Checker will tell you that this cannot be done because iCalFromURL is “not saveable”.
This is exactly the same thing that Bubble would tell you if you tried to change the integer 2 to the integer 4. A object in the app database is “saveable”. Saveable things can be modified. New saveable things can be created.
But the things in these lists returned by API calls are not saveable things. They are constants/primitives.
What you’ve pointed out to me is the likely reason WHY they appear this way. (That being, those objects are in some other table.)
Make sense?
Again, stop using iCalFromURL Event unless your calling your API. You need to change the Fields in your database like “Future iCal Events”.
The names of the fields don’t make any difference. THAT IS HOW I ACCESS THESE THINGS. They can ONLY be accessed that way. You can’t search for 'em.
And that’s the whole point of my initial post.
I think what you and I are discussing is you are saying, “Well, duh Keith, these values – the individual values themselves – are in some other table, not in your app database.” (Which is the part I was missing and I think your explanation must be the correct one.)
But then I’m saying, "But that’s really silly, right? I’m reaching out to an API to get these things and put them in my app database. I don’t WANT them stuck over in some other table. The solutions for parsing that other table and representing these ‘events’ in my app database (app table I guess) as native things that can be fully manipulated involve iteration INSIDE OF BUBBLE.
But the whole point of passing a LIST (array) of these events in the first place was to AVOID iteration inside of Bubble. It’s a “you just can’t win” situation."
(And that’s a bummer.)
Here’s the question: WHERE does this “Activities” table you have come from?
It’s not some other table, it’s a data type (I know you call these “tables” and that nomenclature isn’t incorrect in a sense) that is IN YOUR APP.
You created it, right? By iterating over the response from your API to essentially (in a very slow Bubbly way) flatten those nested parameters. Right?
You went from this:
To this:
Like you said in your first detailed response (which I greatly appreciate, by the way): “One way to populate these values is to flatten them into one table in the database.”
But that’s not a single-step operation. You had to loop over those lists (of “toRecipients” and “replyTo” lists) using an “API Workflow on a List”, correct?
I know this can be done. It’s just horribly, horribly not performant.
Of course, sometimes that’s acceptable. But in general, since Bubble really, really discourages iteration anything that can be done to avoid it is a plus.
My point is that WE SHOULDN’T HAVE TO DO THIS in this way. Over time, the added time to do this becomes huge. When really, API Connector should have a flattening option that can execute in a real server-side loop and just flatten required stuff in ms, rather than minutes.
The other thing I think you’re missing is that YOU DON’T have to do what you’re doing – IF YOU’RE WILLING TO LIVE WITH or work around certain problems.
For example, if you just took the return values for your API such as “toRecipients” list and “replyTo” list and shoved them into a field on Activity without flattening, you’d still be able to READ them just fine. You just wouldn’t be able to manipulate them directly “in situ” as it were.
An item in the “toRecipients” list would be like:
{“emailAddress name”: “Keith C.”, “emailAddress address”: “keith@synth.biz”}
And that thing would be of type “toRecipients”. It would be one of those “API Ghetto” types. You wouldn’t be able to make new ones, etc. But you read 'em just fine and even flatten “on the page” should your interface need to add other recipients. (Basically, you promote them to full data type things as you need them, rather than in bulk via an API workflow on a list.)
The deal with MY complex data type that comes back is that is slightly different than name/email address pairs. There’s more fields (more data to flatten/promote in each iteration = more slow), and I ping that API pretty frequently. And I kinda depend/expect a rather quick response from the API and I have interface elements (live calendars) that need the data quickly.
So I don’t really have time to wait for an artificially throttled API Workflow on a List to complete.
Here’s the thing that’s driving me crazy:
The way these lists come back is ACTUALLY perfectly fine for me. With the NOTABLE EXCEPTION that the DATA TYPE ITSELF is not accessible in the same way as user-created data type. THAT’s what causes the problems for me.
Another less than perfect approach is to duplicate the API connector call, on the second one receive the data as text instead of interpreting JSON as fields.
Then store the JSON text blob or a subset of it along with the interpreted result, and this can be modified and passed to javascript more easily. Just a pain when working with other Bubble functionality, so that’s why I’d use it on a partial result.
Yes, the Activity is a table (data type) that I created in my bubble.
I wouldn’t say I had to loop over the list, since the list is already related to a “thing”. I would think it’s added just as quick as the time it takes for you to initialize the API call, plus a little extra time to save it to the database.
In the video you can see how fast it is to modify it in the database. I assume the same is true, or very close, in creating the Activity from the API call.
Here’s the API endpoint workflow that’s creating the Activity, the list is just one of many fields – Look ma! No looping required 
.
There’s a lot of other steps for processing related items in that endpoint, but the first step is the creation of the Activity.
Yeaaah… well look at all actions on lists you’ve got launching:
There’s nothing quick about when those return usually.
I guess here’s my question about your use case: How soon after you hit your API are you expecting to be able to take action on the results?
Also, I do see this:
Do you or do you not ever decompose those into a native Bubble data type?
Because this is my issue in a nutshell. It takes way too long for me to decompose/flatten/promote all of my “events” things to full citizenship is too much overhead for the benefit.
All I really really really need at the end of the day is to be able to MERGE those things with a parallel data type at the app level. But this simply is not a thing that can be done.
Consider this: You create two data types. One is called Foo, the other is called Bar. They are identical but for those names. They are simple… in addition to the requisite Creator, Created date, and Modified date fields, they have but one user-created field:
“Number”: of type number
Data structure-wise they are identical.
Can you merge them? No. Why? Because even though they are structurally identical, they are different data types.
This is the problem with the API Ghetto lists. You can’t get at ‘em, can’t mimic them, all you can do is read them. Again: because the objects in them are treated as primitives even though we realize they are not that at all.
@mishav knows exactly what I’m talking about here. Help me out, bro, people don’t understand what I’m trying to explain here! 
There’s just no good solution to this and all signs point to “broken.” There’s NO WAY this is what Bubble intended. Have you ever discussed this with support?
I’m like 99% sure that something fairly simple is either incomplete or bugged. It makes NO SENSE for the things on these lists to have a data type but that this data type is not available to the user (the editor user).
It can’t quite be explained.
Hi @Kfawcett thanks for all the screenshot and info. I spent the last 2 days trying to figure out how to make this all work for my use case and it wasn’t till I found this post and your approach that I was able to solve it.
One question I still have:
After you pull in the data from the API the first time, you created the items in the Data Types (Tables) in Bubble. How do you make sure that when you pull in the data again from the API on a later date you only pull in any changes, new items etc, rather than creating duplicates?
I am sure there is a straightforward filter or something but can’t figure it out.
Each entry in the end has a unique ID so ideally, it would update any associates fields that changed from that ID as well as add any new line items for IDs that were created and didn’t exist yet the first time around.
Hopefully, this make sense.
The only way forward to seriously address the list ghetto of API calls is for Bubble to add a Data Type tab to the plugin builder editor. This way plugin authors could create and edit custom data types that would then be available in whichever app installs the plugin. Until then data types sent to and received from API calls will always be second class citizens.
I was literally having this same thought yesterday. There’s a lot of things about The Plugg and editor that could be improved and not having to use an API call to return an object would be great. Simply being able to define the data tape would make a lot more sense and make editing that data type easier
It is a HUGE weakness of Bubble that you can’t created a typed object (a Thing) in the page. It limits the nifty stuff you could do with plugins, for sure.
@nick.carroll Here is some more thread on the issue. Seems like its still not resolved and many users would benefit from being able to do way more with their apps
We’re talking about objects created by the API Connector.
