Welcome to one of my favorite topics in Bubble…
Indeed, @parker1, arrays (of objects) returned by the API connector are super-problematic. Which is why I’ve dubbed this, “The API Ghetto Problem”.
The array returned in this way is given a Bubble data type, tantalizingly called a, “List of [something]
” (a “list of friends
” in your example). But no scalar data type called friend
is created.
And so, in Bubble, your obvious array of JavaScript objects (an array of friend
s) is just… a big blob of data.
And this blob, while Bubble understands that it is an array of something
we can never quite get to a single something
. A something
is forever beyond our reach as there is no Bubble data type created for the something
.
And yet, paradoxically, our app knows about a fucking LIST of something
.
(Please note: The above description is the net effect of this problem. There is no reason for this problem to exist except that the Bubble team is seemingly incapable of grasping why this is a problem. I’ve explained it in many different ways, many different times, and they just don’t get it. It’s almost like Bubble is a low code platform created by a team that is itself… not that comfortable with computer science. Which I think is the problem here. BUT PERHAPS I DIGRESS…)
Anyway, though you can’t get an API_something
from this List_of_API_somethings
(what you desire to do @parker1 is simply to pass each API_something
to a recursive workflow or to a workflow-on-a-list), you can (frustratingly) STILL ACCESS the fields of that API_something
. It’s like there’s a phantom something
(and, in fact, the problem is that there IS a phantom something
, even though no there is no definition for the something
).
So, as you’ve discovered, rather than passing a something to your workflow, you must destructure the something into its component primitive data type parts.
At least you can still do this, right?
That is, using your case as an example:
List of API friends :item *n* :name
Will in fact return the value stored in the “name” field for the (entirely virtual mind you) friend
stored at index n. [Even though List of API friends :item n
resolves to… well, not what we want.]
(Thank the Bubble gods for small mercies, I guess.)
So you have to just suck it up and design your API workflow you want to accept a something
(a friend) to instead accept the individual fields of friend
as primitives.
I could go on and on about why Bubble does not fix this. (The first response would be, “Well, where would we stop?” Which is a good question. Because of course a friend could have a field on it that is itself another list of objects and then, should Bubble create a data type for those objects? This is a reasonable objection, but the fact is that something like 80%+ of use cases would be solved by going just 1 level down. And something like 99.9% of cases would be solved by going 2 levels down.
[At three levels down (a list of objects returned by an API has field(s) on it that are lists of objects that themselves have fields of objects on them) this gets ridiculous and at that point, there is likely a DIFFERENT API call we can make. Simply put, well-designed RESTful API’s don’t return vastly nested arrays of objects so the first objection is just dumb on closer examination.)]
But anyway, just try and explain this to the Bubble crew.
Note that all we are asking for above is for the “data type” (object representation) of a scalar component of this list to be created. I won’t continue about the phallacy that to create and store individual objects of this new type would consume massive amounts of compute. (Which is what the Bubble team would have us believe.)
(In case you can’t tell, I’m entirely unconvinced that it would take more than 2X the CPU power to store this “blob” as it would take to store individual, properly-defined Bubble objects, without requiring us to resort to Bubble’s quite-costly recursion mechanisms. But I will save that discussion for another time. Just let it be known that the value Bubble puts on server compute is several orders out-of-whack with what we expect today. And there may be good reasons for this, but those good reasons don’t change the fact that the Bubble value equation is pretty warped. BUT AGAIN, I DIGRESS.)