Hello Bubble forum!
I need help with creating an action. I have created an action and returned data to the console but how would I be able to assign the result to a data field.
The console return works but I am having a hard time understanding the small documentation for creating actions on implementing bubble features into the javascript.
Thank you in advance!
Having actions return data is not available yet, but weâre working on it.
Thanks for the reply! Iâll wait for that feature to come out, in the meantime I found a work around.
What was your work around @codurly. I am in a similar situation where I need to return data from an action.
Sure, I used Javascript to Bubble plugin which published the value onto an invisible element.
No pressure but is there a rough eta? I have about 6 plugins that would need this to really make worth finishing thats all. Cheers
We canât commit on a timeline, but hoping to do this before the Fall.
Hi @emmanuel
any update on returning Things/values from the action to use them in the next step in the workflow (result of stepâŚ). That could be quite helpful.
Weâre currently working on this, hopefully this will be live in a month or 2.
Hi Emmanuel,
This is really crucial for us in several things we are developing. Are you far away with this feature? Need testers?
Thanks in advance!
Weâre not too far from beta testing for the ability to write server side code (which is what you need here). Hopefully one to two weeks.
Great, cant wait. Do you follow any conventions for the code?
I assume node.js with constraints/simplified or do you rely on any specific abstractions of the server-side code, lodash etc.
Please sign us up for testing if possible, should I drop you an e-mail?
Yes please email support. Note that this is for beta testing, it wonât be production ready then
Thats fine. Willdo.
Looking for this to (for plugin actions to return values to be used in workflows). Seems such a glaring obvious need thatâs been dragging on for a long time.
Server-side actions do this. Thereâs not a TON of discussion on this yet, but there are certain folks messing about with this, and you will find a few discussions over in the plugin builders forum.
(A good way to get started thinking about the server-side actions is to play with the âserver scriptâ action in @mishavâs toolbox â it lets you run JS on the server without having to build up your own plugin. So understanding it and messing about with it is a good first step.)
BTW: If youâre hoping that client-side actions will someday be able to return values inside of a workflow, I suspect you might be waiting a very long time. My guess is that client-side actions can really only interact with the DOM. They are âdo itâ type actions. The workflow does not and cannot really know that they have succeeded, failed, completed, etc.
Iâve not looked at EVERY SINGLE DINGLE one of Bubbleâs own client-side actions, but Iâm pretty sure that none of them return values. So, this isnât an oversight or an omission. Itâs just that we never before had access to the OTHER type of actions before â server-side actions. These are the things that CAN return values to the workflow.
You can check this out for yourself. Take a look at all of the actions in the Element Actions category. These are pretty clearly actions of the âclient sideâ type. And none of them (at least that I can see) return values to the workflow.
So itâs not like thereâs some secret stash of plugin functions that you as a plugin dev are being kept from. Itâs just that client-side actions are just that â client-side actions. And one thing client-side actions are unable to do is return values to the workflow.
We can now build the other type of actions, however.
I donât think that anybody has yet published a plugin that includes server-side actions except @mishav (his âserver scriptâ action in Toolbox) and yours truly⌠and my plug-in is just a very minimal one that I only published to help demonstrate a very vexing issue with server-side actions at the moment (they run very very slowly at the moment â we are told this is being worked on and I will not further theorize about why this issue exists).
Anyway, if you want to see a real-live (but useless! 
) minimal server-side action plug-in you can find mine here https://bubble.io/plugin/return-5-1549738344279x692874662753861600).
And, like I say, the forum youâre looking for is plugin builders, not this one.
Iâve been really fascinated with what @keith has been exploring.
Iâm trying to understand the capabilities we hope to gain with server side workflows but itâs a bit over my head as a non coder. So, Iâm wondering if sharing a use case can help me get oriented. Again, forgive my ignorance.
A limitation that we came up against with Bubble is that we wanted to pull in API inventory data from several sources and display them in a single repeating group. Since bubble only allows us to assign one data type per repeating group this meant that we saw three viable options:
Get the data as soon as the page is loaded and store it temporarily but directly on the repeating group or in a custom state. Great for having up to date data but might ping the api too frequently and cause us to hit api usage limits.
Save the results to a âthingâ that is the same type as the api request. Works well for one source but not good for combining multiple sources since the data cannot be combined with other api data types. Plus there are a lot of other issues with the state of that data, I believe Keith refers to this as the âapi ghettoâ and has written a lot about the limitations/drawbacks.
Pull in the api data from each source and run it through a workflow on a list action to convert it to a unified data âthingâ which gives us more flexibility to combine, sort, filter, etc. However, doing this is very slow as it is has to run operations on each thing it pulls in and create a new database item for them.
So, at one time we were initiating the api requests for data from various sources and combining them into one data type through hosted code over at Blockspring and then calling it back into bubble. This seemed much faster than option #3.
So, hereâs the question.
Would server side workflows that can now be run with node dependencies enable us to run code that combines each of the api sources directly from within Bubble without the need for a third party such as Blockspring?
Thanks @keith for the client-server-side workflow clarification. I always assumed the workflows were client side, triggering API calls to the back-end as needed. Now it seems there is a mix - mostly server side triggering client side actions. I suppose this also clarifies why the âdelayâ action only works on display related actions, since the server side is not affected. I guess it would be nice to flag a workflow as âclient onlyâ and allow the return values at that point, and a better ability to directly affect DOM elements in this as well.
Personally I think this was a bad choice. Workflows should focus client side to better support SPA (single page applications). The company I work for uses many Google suite products and the ability to create a SPA using Googleâs web APIs (etc) might mean the ability to publish HTML+CSS+JS only apps. Calling to the server side should have been done by allowing workflows to design a server-side API that is optional. I guess the business model was the deciding factor.
Hey @dserber⌠Yes, the situation you describe is exactly what I call the âAPI ghettoâ issue. As for the question:
Itâs potentially possible, to a certain extent. It depends on what exactly one wanted to do.
The node âhttp.requestâ module is available in server side actions â so theoretically you can do your own API Connector type calls (GET, POST, etc.) from directly within a server-side action. And you could asynchronously makes those calls, await the responses and then massage/combine the data into a consistent format.
Further, that format could POSSIBLY? be compatible with a ârealâ custom data type that you have defined in your app.
At present (and maybe not ever, Iâm not sure) you cannot return a custom data type itself. You have access to the primitive data types like so (and those can be single values or lists):
Now INSIDE of a server-side action, there is no capability to modify Things in the database nor to create new ones. That is still the exclusive province of the Create and Make Changes actions.
So I think one still has the problem of having these lists of data objects and needing to iterate over them in a Bubble workflow (like a recursive workflow or schedule API workflow on a list) in order to create ârealâ database Things out of them.
So, in a way, I think what we see here is the origins of the âAPI ghettoâ problem. You can build your own âAPI Connectorâ type of things with a server-side action, but you still have the same problem as in Bubbleâs API Connector, which is that you cannot:
Anyway, I canât figure out even a tricky hacky way around this. (Note that I have not played with using http.request module in my own server-side action efforts. Mostly because it seems to me that I will hit this problem and it just wonât solve the API ghetto issue.)
What Iâve been doing in server-side actions is making interesting new modules that are primarily around filling gaps in certain list type operations (e.g., a Bubble version of getIndex() â tell me what position object x is in a list of objects), utility functions for creating certain types of primitive lists, some actions that are akin to logical operators, date/time manipulation things, etc.
The idea is that each of these is a pretty lightweight bit of code and you could conceivable chain the together in a workflow to do things that are very hard to do right now.
(The issue one runs into with that is that at present SSAs are very very slow to return â this may be a âbugâ in terms of Bubble scheduling these actions or maybe its just that SSAs eat up a lot of what minimal CPU capacity we have. Bubbleâs @marca is working on this. It remains to be seen what kind of performance we can expect from SSAs once Bubble does optimize or fix any actual issues that SSAs currently have.
The thing one hopes is that SSAs can be used at least a little like we use on-page JavaScript or external microservices⌠This is often done to quickly loop through lightweight recursive tasks that take 10x - 1000x longer in things like âschedule API Workflow on a List.â
But my fear is that we may not be able to achieve any performance advantage in this way. There would still be cool things that SSAs could enable if SSAs that operated on a single object were suitably fast, but one of the thing that excites me about SSAs is the potential for filling in some of the holes that would make Bubble more of a true array-oriented language.
We shall seeâŚ)
