Variables (custom state) in API workflows

This is somewhat related to me last idea post Get Thing function in that it relates to API workflows and that it would cut down on unnecessary lookups.

It would be great if there would be variables in API workflows (custom states) not associated with visual components. I find myself have to do this a lot:

Do First Thing ONLY WHEN lookup some data to do a comparison on
Do Second Thing ONLY WHEN lookup some data to do a comparison on
Do Third Thing ONLY WHEN lookup some data to do a comparison on

in all three cases I am doing the exact same lookup and comparison. It would be so much easier on my if I could do it once while setting a custom state value and then use that custom state value repeatedly. It seems to me it would also be better for performance (1 lookup vs. 3).

Marc

7 Likes

'+1 to this. It would help make API workflows much more efficient.

2 Likes

+1

It seems that API workflows are unnecessarily crippled by not having local variables, aka custom states. For any sufficiently sophisticated logic, it is critical to have the ability to store intermediate results, hence local variables.

3 Likes

+1

This would be awesome!

The recently released server scripts go part way there, you can run javascript (Node) to have expressions evaluated, and the result is available for the following steps on the same workflow.

To make this easier than creating a plugin every time, the Toolbox plugin has a “Server script” action, where you can define the script, the data, and the return type.

More information at:

2 Likes

@mishav how would I create a variable that is set with the value from a “do a search for” ?

For example:
var folderID = Search for MailFolders:first item’s ID
var nextLink = Search for MailFolders:first item’s nextLink

I want to be able to perform the searches once and then set them in variables so that I could use them in “only when” fields on the subsequent steps in the workflow.

For example:
Step 1’s Only when = folderID is not emtpy AND nextLink is not empty
Step 2’s Only when = folderID is not emtpy AND nextLink is empty

Is this possible with the server script?

@Kfawcett yes, here’s an example, although there’d be a lot of ways of doing this …

Its setup on a page workflow for ease of testing, it does work on API workflow as well.

editor: toolbox-example | Bubble Editor
run it : https://toolbox-example.bubbleapps.io/version-test/serverscript?debug_mode=true

Button “text variables” …

Properties of some of the steps ...

image

image

image

2 Likes

@mishav,

Thanks for sharing this.

I only tried the Get Webpage and Generate List of Numbers. Surprised at how long they took. Many seconds just to generate and display either one.

Is the long wait time unrelated to the speed of the script or Bubble’s handling of it?

Once again, I am frustrated by some of Bubble’s barriers to encapsulation and reusability.

My app has relatively complex logic for calculating a future date based on several factors. Since there is no clear support for the equivalent of functions in Bubble, I am forced to replicate the series of actions in at least a dozen workflows. It’s a tedious and error-prone way to do what would be quick and reliable with functions.

Hi, @laurence. While I’ve not tried it with a complex calculation, I’m wondering if a Custom Event might be useful in that situation. Perhaps you’ve already explored it, but could a single workflow reference states that represent each of the “several factors” you mention? Of course, that assumes all the workflows are on the same page. Just a thought.

1 Like

Custom Event’s in reusable elements should be able to do the job.

Unfortunately, Bubble isn’t built so that custom events behave like functions, or even like callable procedures for that matter. (Sorry, but I have to fall back on some terminology from ancient languages like Pascal.)

One specific problem with custom events is that they don’t support a defined interface. In other words, it’s not possible to define a list of parameters that can/must be passed to the event. Neither is it possible to define a result value returned from the event as is the way of functions.

API Workflows implement parameters fairly well:

image

The big problem with API workflows is that they run on the server with no return signal to the client (the calling workflow). And API workflows, as discussed above, don’t even support local variables (custom states), so their calculating ability is severely limited.

Perhaps after I finish launching my app and have more time, I’ll document the ways Bubble comes up short on reusability. (Somehow I figured the fundamental nature of object-oriented programming would be reflected in Bubble. I guess we’ll have to wait for Bubble++. :slight_smile: )

1 Like

+1 on this

1 Like

Is it possible now?

Stars aligned and I am stuck on this in the same day as mghatiya, 2 years after anyone touched this topic :smiley:

+1

Haha good to know. I managed it via a workaround by creating a new table to store these variables.

When in the workflow I create a new row so that I can store the variables and access them. At the end of the workflow I delete the newly created row.

Working so far. Hope it keeps working.

I decided to go with server scripts, which are a part of javascript plugin called Toolbox. That way you don’t have to write the value to the database, and you can refer to the value as result of step X. But it is still a very clunky workaround for something what feels like it should have been in vanilla Bubble ages ago.

That’s true. It needs to be native feature.

Btw, I stopped using Toolbox plugin to do javascript stuff of storing variables etc. There was one issue that I got stuck on for months which involved saving cookie, reading variables etc. The variables were not setting reliably, causing my db operations to be unreliable, and it would fail often. No support from the plugin author and Bubble support simply said that we can’t promise db operations’ integrity if there is a plugin dependency involved.

But it is good if it is working for you.

can’t understand neither why it has not been implemented ages ago. It’s not like we can use parenthesis…

2 Likes

Now we can :slight_smile:

How can we do this now? That’s great!