I am a long-time but infrequent Bubbler. I am resurfacing a problem that may be among the most serious problems I encountered four years ago after building a lot of reusable workflows in a reusable element.
In many cases the workflow calculates or formats a number of values that are stored in custom states and available to the workflow that triggered it. Unfortunately, the results are unreliable at best because the reusable workflow is still working (in parallel) while the triggering workflow runs its next action which needs the result of the reusable workflow.
Step 2 sets a custom state in the reusable element to a number of minutes.
Step 3 triggers a workflow that converts minutes into text representing the minutes as hours and minutes (hh:mm).
Step 4 copies the resulting text from the reusable element’s custom state into the local custom state (wPlanDurationText)
Results are unreliable, which I think means their always wrong.
What seems to solve the problem in this workflow is adding a pause between triggering the reusable workflow and then using its result.
Ugly, potentially wasteful of time and potentially unreliable.
I set the pause for 100ms. Is that always enough? Would 10ms be long enough? Always? If I have ten such workflows, am I not adding a full second to the UX?
Other than the Bubble builders providing the ability to create true functions in Bubble, what is the right solution here? What can be done that is not wasteful because of excessive time spent in pauses and what can be done to ensure that enough time is in the pause to guarantee correct results?
@w.fly, I was about to reply when your post was withdrawn.
As I understand “Only when” conditions on action steps, they will only prevent the step from executing, not pause the workflow until the condition is met. The workflow will go on its merry way and simply not execute the step that depended on the reusable workflow.
Yeah… honestly all of it is quite confusing still… and I’ve been at this for years, like yourself. I spend a large portion of my time working on little details like these on my apps. I usually end up having to do it a different way that may be more inefficient just so I don’t pull my hair out lol…
@laurence when you set the value of the state in your dynamic data you should see ‘as a result of’ options to set the value of the state of your reusable element.
You can access the states of a RE from anywhere you have it, so you don’t also need to set a ‘local’ state that matches the RE state.
Currently you are seeing it be ‘unreliable’ because of race conditions.
PS. if you are already setting the custom state of the RE then your step 4 is redundant
My solution for these race condition issues on RE’s is a very tiny internal plugin called ‘Relay’ which sits on the main page with a yes/no condition expression inside that links to a state on the RE called something like “changes_made” or “continue_running”. When that condition is met then an event triggers from the Relay element and a workflow kicks-off on the main page. It’s essentially a fudged callback.
So you would update the state to “yes” inside the RE when you know the work is done → That will set off the workflow back on your main page → as part of that workflow you will reset the RE state back to “no”
@equibodyapp in this context I don’t understand what “dynamic data” refers to.
And you’re right that step 4 would be redundant if I didn’t want to save the RE’s state value for other uses than just in this workflow. Any place the value is used outside this “local” workflow should not need to know about the RE. It’s classic thinking from the days of structured programming. (kind of like classic functions that aren’t supported by Bubble.)
@exception-rambler It seems that this requires the local workflow to be divided: one up to the point of triggering the reusable workflow, and a separate one for handling the result of the reusable workflow. Seems like it would work, but would be a bit of a kludge that gets in the way of workflow readability.
Another thought. Please check me if I’m off track.
If a plugin can essentially implement a callback, what’s stopping the Bubble makers from doing the same in a way that allows a workflow to remain intact?
I’m not sure.
But probably because it falls in the big chasm between powerful game-changing, user acquiring feature, and painful, groan worthy, user churning bug. The people that spot it are usually also the people able to work around it.
In Bubble’s defence, the world of sync, async, requests, promises and callbacks in traditional development is a minefield and functions end up disjointed.
There’s several places where it would be great to be able to do ‘return’ values: from client-side plugin actions, from Backend API workflows called via Bubble (as opposed to API connector) and reusable element workflows too.
Thanks to all of you for your insights in this thread,
but . . .
YIKES!
I’ve been using Bubble for nearly 4 1/2 years and wasted literally weeks of my life because Bubble never explained workflow order of execution. Apparently it wasn’t until May '21 that something was done by Bubble to explain how it works.
In the nine months since this was published, why wasn’t it repeatedly shouted from the rooftops, in the forum and in the Bubble dev UI so that everyone would have access to this information? I only stumbled on it today because I was digging deeper into what is missing in my understanding of workflows that has caused me so much lost time and deep frustration for more than four years.
No doubt Bubble is doing much better at transparency since the early days, but there is still a lot wrong with their documentation and communication about foundational behaviors.
I spend a large portion of my time working on little details like these on my apps. I usually end up having to do it a different way that may be more inefficient just so I don’t pull my hair out lol…
