Custom events are really cool, but they lack the ability to return values (like a custom state on an element)
CONTEXT
I am manually authenticating API requests to an API workflow in the backend. What I would like to do is create a custom event called “Authenticate” which would return a “yes” or “no” value depending on if the API request meets the authentication requirements I have defined. Based on the result of the event, I want to either reject the workflow or to run the rest of the actions.
THE PROBLEM
there is no way to return values from custom events. Instead, you must do the following:
API workflow runs custom event (let’s called it custom_event_1)
Inside custom_event_1 you run the authentication process, then if everything works out you then run a new custom event (custom_event_2)
Inside custom_event_2 you run the actual actions you wanted to take in the original API workflow
A BETTER WAY (REDUCE REUSE RECYCLE)
A way better way of doing this executing actions depending on the returned values from the custom event. This would let users reuse their custom events (in my case, authentication process) for all of their front and backend workflows by leveraging parameters and return values.
Right now I can’t reuse this custom event, because I had to hard code custom_event_2 inside custom_event_1
I want to run the same authentication workflow for ALL my webhooks. Now, I need to create several custom events that all do the same thing …
How about use endpoints?
Then you bring return values back into play.
I do exactly that with a single endpoint that returns the User.
I do also agree that return values on custom events (esp. front end) and in several other parts of Bubble (f/e plug-in actions!) would be v useful though
It’s interesting, using endpoints, I’m sure that works for you but it just seems like a weird workaround that shouldn’t exist. Not to mention, super inefficient!
Bubble already treats workflows like “functions”, so I don’t see why functions shouldn’t be able to “return” something
Hello! Starting to shape out this project now - could you PM me a bit more about what problem(s) returning data on custom events would solve, your use case for this feature, and what workarounds you’ve tried (as well as why these workarounds might not work for you). Would love to incorporate this feature into the product development process. Thanks!
I am manually authenticating API requests to an API workflow in the backend. What I would like to do is create a custom event called “Authenticate” which would return a “yes” or “no” value depending on if the API request meets the authentication requirements I have defined. Based on the result of the event, I want to either reject the workflow or to run the rest of the actions.
THE PROBLEM
there is no way to return values from custom events. Instead, you must do the following:
API workflow runs custom event (let’s called it custom_event_1)
Inside custom_event_1 you run the authentication process, then if everything works out you then run a new custom event (custom_event_2)
Inside custom_event_2 you run the actual actions you wanted to take in the original API workflow
MORE ON THE PROBLEM:
I need to recreate the same custom event over and over again because I must hard code each subsequent event (event 2, event 3, event 4) at the end of custom event 1… I am either forced to use very complicated conditions if I want to reuse custom event 1. Not being able to reuse custom events (because of a lack of being able to “return” a result) leads to a bloated workflow tab, because I have several custom events that do 90% of the same thing
That is a really good, clear example Jonah. Thanks for providing that to them. I admit, I am struggling with my exact use case… but can confidently say +1 to your example lol.
My app does a huge amount of calculations. Almost every value is depending on the result of the calculation before. I was struggling quite a bit until I figured out a way to fire calculations after the one before is done.
Also: Sometimes I need the result from calculation 3 in calculation 8.
My current way is that I schedule each calculation with a 1 second delay attached with each’s result. So every next custom event has at least one more variable than the one before that it asks for.
This kind of way is not really satisfying and really complex due to the fact that custom events don’t return anything and therefore also not wait for the returned result.
Maybe this helps in enlighting why this is a feature we’d all welcome to see.
Exactly, sometimes we need to have things happen in order. Custom events (C.E) returning values would solve this issue, because you would be able to force workflows to wait for the C.E to return something before proceeding with a condition.
The biggest thing for me is being able to REUSE events. My editor is SO slow on big apps ( I have 16gb of RAM, use Firefox cause it’s better on RAM, I have a 6 core processor and an integrated GPU) and my PC is BRAND NEW. Less making things over and over again and I can finally develop at full speed again! (hopefully…)
i assume this is different than just making a recursive workflow using an Api so launch itself again when a condition is met, or run a different Api if another condition is met. that’s what i do.
but I’m sure I’m just not understanding what’s different about the problem you have. and im sure if this gets implemented ill be like ooooh yeah that’s better.
Returning values from custom events is completely different from scheduling an API workflow (or making an API call to yourself, as you say)
The differences are…
Custom events are run on the client-side
Custom events (and workflow actions) just run plain old JavaScript. Making an API call reduces performance (that adds up over time)
Custom events have access to groups, elements, url parameters and other “things” on the page (backend workflows do not)
Custom events shouldn’t clutter backend workflows with mundane tasks
Finally… I am requesting custom events to be treated as ASYNCHRONOUS operations, rather than RECURSIVE (like your API call example) operations. Anything Async is normally better than recursion because it reduces errors and avoids loops. It just does the thing you want it to and when it’s done it lets you know! That’s exactly what I’m looking for here.
And like I said, return statements allow reusability (ever heard of that thing called functions? Coders like to name functions I.e actions in bubble speak and have them return things). Parameters + return statement would turn custom events into functionally the same thing as functions!
