This must be a common use case, I am wondering what are best practices:
Use case sequence:
user needs to enter a value into an input
to find the value, user clicks an icon that opens a popup window
a reusable element in the popup window helps user select value
the selected value gets put into the input
I think of this as a “function” that gets called when the user clicks the icon, and the function returns the value for the input.
In Bubble, I can open the popup when the user clicks the icon; but the only way I figured out to get the resulting value into the input field was a complicated sequence of setting a flag that the “value is ready” and a workflow that runs when it sees that condition is true.
That seems pretty indirect, is there a better way?
No unfortunately. It’d be great if workflows returned values esp for reusables so that we’re not popping stuff in and out of custom states all of the time. Being able to get a return value from a custom workflow as well so in actions we can say “Result of Step …” as you can when writing to the DB. Also being able to store “custom states” (variables) specific to workflows. As a coder myself, these things would just put the icing on the Bubble cake But they’re all work-around-able so all good I suppose.
It’s been almost 4 years since this post. Is there still no such thing as reusable functions in Bubble?
Using custom states is not robust due to lack of dependency. Using API workflows is also not foolproof as it runs in the background and you don’t know for sure when it completes.
Right now, I have the same steps in multiple workflows. And if I need to change the step, I need to change in many places.
We’ll need to use custom states to store those return values.
Is this 100% reliable in terms of dependency? i.e when the custom event exits, the custom states will definitely be populated? I didn’t have a good experience with depending on custom states.
That’s true. I was responding only to the need to consolidate common code. I use Custom Events for that very purpose quite often.
In my experience, it’s best to think of Bubble as responding to events instead of “returning values”. Bubble basically has its own “reactive” front-end framework baked into the platform. “Returning values” is a more traditional / procedural concept and doesn’t translate well.
Instead, think of things happening in the UI in response to an event - be it user-triggered or system-triggered - such as a data source or a custom state changing.
I’ve never had an issue. When the value of a custom state changes, then any expression, condition, or element referencing it should automatically be re-evaluated / updated as well. That’s how it’s always worked for me.
But they’re all work-around-able so all good I suppose.