hi @antony
Looks like you’re basically there… The below would be how I would use Server Side action to retrieve items from a list and publish them back. This works for “any thing”, provided you know the name of your object’s target field.
And if you don’t know the name of that field you can either:
get your user to specify it… add an ‘App Type’ field to your plugin action, followed by a ‘Fields of name of previous field’ field… this will force them to specify
work it out within the code… use properties.anythinglist.listProperties() to fetch all of the available fields then pick one
Anyway, here’s the code. It’s no different from what you are suggesting to be honest, but I can testify to this working.
let items = [];
let len = properties.list.length();
let listObjects = properties.list.get(0,len);
for (var c=0;c<len;c++) {
items[c] = listObjects[c].get('_field_name_')
};
return {
'key' : items
};
Hey @exception-rambler, thank you soooo much for taking the time to reply! I really appreciate it. I had been going round in circles, so near, yet seemingly so far from the answer. It all makes absolute sense now.
You may have seen I have started a beginner’s guide post to all of this, so I will add the details of your reply there with some explanation.
Best wishes,
Antony.
PS - would I be right in saying the properties.list.get(0,len) line should actually be based on len-1?
Re: len
Strangely, it is actually len, rather than len - 1. Although logically you are right. If you test both you will find that - 1 actually returns one too few items from your list. I think just an idiosyncrasy of Bubble’s get() function.
@exception-rambler, I didn’t know about / hadn’t explored the “App Type”, etc. Editor fields - thanks for that tip!
As for grabbing a list of fields from a list of objects: Alternatively, you can do the whole shebang in a one-liner:
properties.list.get( 0, properties.list.length()).map( x => x.get("_field_name_" ) )
Caveat: Prevailing wisdom seems to be that – in the browser – a simple for loop is more performant than .map. Not sure if that’s the case on Bubble’s server. (It’d be worth testing, I suppose!)
Not wanting to go all nerdy on JS, but I’ve seen some tests that browsers optimized for .map some time ago. Now inside Bubble’s node environment… who knows.
Perhaps I should open a new post here but, since this is relevant to the discussion above, I have a question about objects as they come over to the server-side plugin environment from a Bubble app:
I’ve been building a plugin that has a field of type “any thing” and a field that is a LIST of type “any thing”.
One would think that, if the single item field is a specific User and then the LIST field is a list of Users, that:
The object properties.single_item should be findable in the “gotten” list of properties.list_item. But this seems not to be true. Even though the structure of the object properties.single_item looks the same as the structure of the individual array elements of properties.list_item.get(0, properties.list_item.length()), using various array functions to see if properties.single_item appears in the array seem to always return false.
Let’s say that you know the Bubble object represented by single_item is the third item in list_item. However, the following returns false:
However, if you map list_item to the unique IDs of the items it contains (property “_id”), and retrieve the unique ID of single_item (properties.single_item.get("_id"), that list of UIDs will include single_item’s UID.
So I guess my question is: Is this the only way to do it? I’d love to be able to compare items “object-wise”. Am I missing something? (Or is this perhaps a bug in the server-side action API?)
In this context, does “App Type” mean “type of thing” - i.e. the data type within the app? The nomenclature is a bit confusing to me, as “App Type” implies “type of app”.
Yes - it’s confusing, not sure what it is trying to say.
But it means ‘Type of thing’… You can then add a Search field and restrict it to that Type, and you can add a ’ Fields of…’ field that basically runs listProperties() on the Type of Thing and presents as a user dropdown. See below:
It works but it’s a bit clunky, especially for users. But the main issue is that it makes going deeper into the data-structure and reaching linked Things almost impossible. In Chart Tools I (clunkily) allow users to go one layer deep if they need to reach linked objects, but going further than that is not practical.
It would be great to be able to manage this the way that native Bubble plugins do. For instance the native Bubble Chart element allows users to pick a ‘Type of Data’ (App Type), then run a Search, and then pick out the required fields using the familiar dynamic-style interface. This last part is not open to Plugin developers.
Example of what I mean below where I have pointed the Label expression to the Type field, which is part of the Type object, which is linked from the Activity object… I could go as deep into my database as I want here:
Hi @neerja, please any update on this. That is ability for plugin’s to access Current thing’s … .
I really need this for some plugins I want to release.
Thanks
I love the map use above, but you can use this code to iterate over a list and get back a list of objects just in case you need to pull up other named field value
//This code get the list as an object which you can then iterate over
let objToFetch = properties.variable_list.get( 0, properties.variable_list.length());
//Use this code if you need to examine the object length console.log('objToFetch',objToFetch.length);
//Get and add variables to plugin
objToFetch.forEach(e => {
let n = e.get(properties.variable_names);
let v = e.get(properties.variable_values);
//use this code to examine the results console.log('Variable Added','Vartiable Name:',n,'Variable Value:',v);
});