I don’t know if it’s a bug or not, but here is my problem.
I’m making a simple plugin to concatenate two lists of texts, buy when I try to add a bubble thing or app type into it, it stops treating it as a text/string as soon as I try to do anything with it.
Here is the code:
function(properties, context) {
let size = properties.first_list.length()
let first = properties.first_list.get(0, size)
let second = properties.second_list.get(0, size)
let result = first.map((element, index) => {
return element + properties.separator + second[index]
})
return {
resulting_text: result
}
}
This return results such as “[object Object]”, but if I change the return of the “map” function to something like:
let result = first.map((element, index) => {
return element
})
…then I get the proper string (e.g. the unique Id of an thing in bubble).
I can’t seem to get what’s wrong… can anybody help?
[object Object] is what you get when you try to use an array or an object as string. Based on what I see here, the variable result will always be an array in both cases (because it is the result of your array.map function, which can only return arrays).
What’s the full output of the function when you replace the return of the array.map function in your second example?
The output is whatever I give it. For instance, if I give it the “unique id” of a thing. It goes without any problem.
But when I try to do the “+” operation with the strings, I get the [object Object] problem.
Another important fact. I tested to give the result of another action (that outputs a text) as an input to this plugin action, and there was no problem, even if I do the “+” operation.
Actually, when I tryed to concatenate the “unique id” of a thing with this text output of another action, I got “[object Object]-correct_text” as an output. That’s why I think there is something wrong in the way the plugin code treats the “element” in the map function, or in the way it treats an input that is a “thing” in bubble.
I’m also seeing something either weird, or new (or new to me) here.
In my case it seems linked the nature of the list of strings being imported - specifically I am bringing in a list of Unique ID’s and what I’m receiving inside the plugin is a list of objects, just as if I had brought (instead of strings) brought in objects from the database.
@sudsy or @vini_brito - have you come across this… text fields that arrive as objects inside of a plugin?
Hi Edward! Unique ID’s are interchangeable with bubble objects, so check the workflow if it is passing things (as in User) or these things’ unique id’s (as in User’s unique id).
So it would be expected behaviour that a plugin field like the one above would actually import objects if the strings happened to be unique Ids…? Until now I thought the only way to bring objects into a plugin was via an App Type field + a dynamic field of that type.
This doesn’t happen with single value / non-list fields, only with lists.
It makes bringing a vanilla array of Unique IDs into plugin scripts a faff… to get around this I am joining the list into a single, comma-separated string inside the workflow, and then splitting them back out into an array inside the plugin.
Sorry probably wasn’t clear - I’m of course fetching the List in the normal way via .get() and .length()… per your snippet above. But where strings that happen to be Unique IDs are concerned the response I’m getting from .get() method is not an array of strings, but an object array with the normal methods that come with a Bubble object .get().
I could theoretically then call down the unique id properties from object array, but it feels weird as I was transacting in strings / texts only.
A field directly beneath this one also fetches a list of texts (but some random data) and it’s performing normally.
Yes I was wondering the same thing - if you could break the connection between the string and the Thing at the point of input. But bringing them in as a single text of comma separated values and then .split(',') works fine too.
Oh, ok. Sorry, I’ve always been a bit slow on the uptake.
In that case, I think @vini_brito hit the nail on the head. His comment aligns with my experience, which is basically that any time Bubble knows (or can determine) the type associated with an id, it will return the Thing itself - i.e. the id is just a proxy for an instance of a Thing. That’s actually behavior I’ve come to expect.
Anyway, sounds like you’ve found a workable solution.
