Forum Documentation Showcase Pricing Learn more

triggerEvent: Why does it have a callback?


I don’t understand why it is that triggerEvent has a callback. Per the documentation for instance:

triggerEvent: function(name: String, callback: function(err))

I understand that there’s a function there (but why?) but I don’t understand why its argument is err (presumably an error object?)…

Like, I can do:

instance.triggerEvent(‘date_hovered’, function(){console.log('why? ')})

But what is one supposed to do with this? When would triggerEvent ever have an error come back to it? I’m confused on this. There must be something useful here, but it’s opaque to me…


Can’t events trigger workflows? It seems entirely possible that a workflow could generate an error, in which case specific error-handling logic might be warranted.


Sure, but it’s hard to construct an error oneself to check this out. This is one of those cases where an example would be helpful. Also, it’s not clear to me that a plugin should care if user does something stupid outside of the plugin, right?


I agree. An example would certainly be helpful. (I haven’t checked to see if the error object is documented.)

However, it seems an error wouldn’t necessarily be user fault, given the vast array of actions that could comprise a workflow.

Also (and I realize it’s just an example), I was curious about the choice to “trigger an event” as opposed to “publish a state” on hover.


Good question! I’m just playing around. Triggering an event on hover is a bad idea (it turns out) and triggers too many events. So not advised.

(This isn’t a problem if your element is just one thing, but the thing I’m building right now is… well, let’s just say it’s full of hoverstates…)


Still don’t get why this is an error handler fn though…


Ok… so… does anyone use this feature? Does anyone actually build plugs in Bubble that DO anything?

Wondering about triggerEvent’s callback and what the f it’s intended for.

Seems like it might be useful, but I’ve not been able to discern its applications…


Ok, so I intentionally generated an error by triggering an event within my plugin and then implementing an event handler (workflow) which attempts to send a confirmation email without the user being logged in. The error object returned is:

    "statusCode": 400,
    "reason": "NEED_TO_BE_LOGGED_IN",
    "message": "You have to be logged in to modify your account.",
    "args": {
        "bubble_code": "1552278138567x623546740597951700"
    "stack": "[stack trace omitted for brevity]"

So it appears to be as I surmised - i.e. basically, the plugin equivalent of what’s accessible from the “An element has an error running a workflow” and “An unhandled error occurs” workflows. Actually, there’s only a code and message available in the workflows, but it’s the exact same error message. (I confirmed this by displaying the workflow error message in a popup.)

In short, it enables plugins to handle errors if need be. It can probably be ignored in some cases, or simply printed to the console to help with troubleshooting. I guess the best way to handle it depends on the nature of the plugin.


Nice work, @shot! Thx!

(Interesting that there is this error callback, but no generic callback facility, don’t you think? Like, how rad would it be to trigger an event and then get a value back from a user-created workflow? Like, you know, a real callback.)


Though I have to say: I’m still at a loss to see why the plugin should care that this happened. What’s the plugin going to do about it? Nothing. The plugin cannot know WHY this happened and has no ability to fix it. What did the plugin HAVE to do with it? Nothing. This feature seems like a pointless stub.