I’m having issues with this myself today it seems… you’re not alone
Thanks, could this be after a Bubble upgrade?
I am wrong. I got mine to work. Both client-side and server-side able to return objects
Are you testing your plug-in or did you install your test plug-in? There’s a difference between the two if you installed your test plug-in, are you sure you’re running the latest version?
Good morning, thanks for your reply.
No I have not installed it. I have not done any release, just using the test application
Might be worth switching out the return value for just the object stringified so that you’ve got eyes on exactly what’s being pushed back.
This does look really strange though…
I’m keen to get to the bottom of it has we heavily rely on this.
Also would be worth deleting the api call and setting it up again.
Oh I think I see it now… you’re not giving a return value key name. Try:
return {“api_data”: result}
This is it exactly!!! @jasantana see the post above!!
You’re right!!! God I knew I was missing something but not that obvious!!
Thank you very much
Yes, thanks. Saw it now. How could I miss that?!?!?!
Coming soon!
Hey Jared, so looking forward to this one. I’m currently stuck on exactly this problem (returning object from plugin on client side)
welcome to my ramblings. thanks for reminding me about this one @flesik
Now, this example and video is only related to returning simple data however if you apply the concepts from the other examples for returning objects you can use it in the exact same manner
^^^returning simple data from an action, and triggering a workflow to handle the returned data
Hey Jared, thanks for the video.
I was able to return simple type like string easily.
My issue is returning “app type” via state.
I tried so many variations and result is always null.
Examples that I tried to return:
instance.publishState('data',{"type": "test"});
instance.publishState('data',{"_p_type": "test"});
instance.publishState('data',[{"type": "test"}]);
instance.publishState('data',[{"_p_type": "test"}]);
None of them works. Can you pls help with the syntax, how the “app type” should be returned into state?
One more question. I was renaming fields and my suspicion is that internally the field name may have different name compared to UI (I experienced this on the backend flows). When the parameter is “app type” as an input. Is there a way on front end to show, which fields are expected/available to be provided on the return value of “app type”?
Thanks for your help.
If your app type is a database custom type then you need to pass the UID field into the state value (e.g. publishState(‘data’,‘102340403X320030303’)
Hey @jared.gibb, I love that you do videos like this, but I don’t understand why/what you are doing here?
That element plugin you created HAS its own actions that you can define interfaces for in the Actions section of the element plugin (and then trigger them with code that you write in the Code Actions section).
I don’t get why you’re creating an element plugin and then making it communicate (via the window) with an Action plugin? (It’s neat that one can do that, but for actions that are associated with an element plugin, you don’t need to do this.)
@keith totally valid point. Interestingly enough though, you can use this method to communicate with other plugins/actions. I don’t have a good use case for you on that either but it is nevertheless possible.
I can’t even remember why I ever learned how to do this to be quite honest. It’s so convoluted. But something that can be done regardless. ![]()
Yeah, I’m having a hard time thinking of practical applications of exposing plugin_a’s instance object to some other plugin_b. (Although doing so allows plugin_b access to a’s instance.triggerEvent() and instance.publishState() functions.)
It’d be a funky interface, but one could expose one plugin_a’s main properties object (the properties that is sent to initialize) on the window and then some other plugin of the same type could be made to inherit plugin_a’s settings (or some subset of settings). I had actually thought of doing this with (for example) Calendar Grid Pro, where the main interface has dozens of properties and it might be useful to just let the user plop another one on the page and, rather than making them copy/paste plugin_a or fill out dozens of fields, they could just fill in a text field that’s plugin_a’s HTML ID to say “this one looks just like that one”.
Hi, I am trying to return an array of object from server side action but it’s returning empty array. If I fill up the array manually it works fine as you showed in the video but when I am filling up that array after reading data from bubbles database and doing some operations on those datatable it doesn’t work. Also if I console.log() it in the client side action It’s working fine. Don’t know what I’m doing wrong, any help is appreciated.
Here is my code: JSFiddle - Code Playground
Return data model:
Output data setting:
Output empty array in server side action:

I managed to return the object from the server side action. But is there any way I can treat it as my custom type in the following steps of my workflow?

At the moment that’s the only thing that shows when I try to create a list of things from the previous step.
However, when I set the previous step return type to my actual data type, it shows as expected “allowing me to directly add it to my database”


