Hey @Bubble: You know what we be really useful? If triggered events could have an accompanying value.
The way the plugin APIs are right now is backward: The Bubble programmer user can send us (the plugin) a value (or values), but we cannot respond in kind. triggerEvent() could really use an argument (or array of arguments) . Like:
triggerEvent(‘event_name’, value, callback())
… instead of how it is now:
triggerEvent(“event_name”, callback())
I GET that the Bubble programmer user can, upon receiving an event, inspect the value of an exposed state. However, that state can easily be gone or changed by the time all of that happens.
Also, such a feature would enable iteration in the browser. Let us say that I build a date picker that exposes a list of dates. Now, the client user has selected dates and Bubble programmer user needs to iterate over them. Bubble user could send initiate an Action such that we (the plugin) can respond immediately with a barrage of events and accompanying values.
In this example, respond with triggerEventI(“doSomething", date1, some_callback(which_we_prolly_no_longe_need)) followed by triggers accompanied by date2…daten and thereby enable safe, client-side iteration.
We need this. (Well, those of us building bare-metal Bubble plugins DESIGNED FOR BUBBLE and not just adapting libraries or doing no-op functions.)
(If i’m being derpy and this is already available do let me know. But I’m pretty sure this is something the plugin API does not enable, ATM.)
Well, not exactly. I’m asking for the analog of a plug-in element action.
Plugin element Actions are triggers FROM a Bubble workflow, to a JavaScript function, which ALSO pass values from fields, right?
But the signaling we have from JavaScript back up to Bubble is a trigger, without accompanying value. These are called Events.
You have to declare Events in the plug-in editor, but you do not get to declare accompanying value(s). It would be useful to have that.
The Event value(s) should be typed (not arbitrary) as Bubble values must always be typed and are not polymorphic. They could (and should) be capable of being arrays (lists) but sending a list or lists would happen in a single Event.
My point about iteration is that you could then send Events with accompanying values one at a time to make up for the fact that Bubble doesn’t truly have array-oriented features like .map().
But the passed value would be available in the workflow triggered by the event, right? So instead of the Bubble app editor having to reference an exposed state, the value would just appear as “this workflow’s thing” or some such? Just trying to understand how you envision the app editor accessing the passed value.
EDIT: By “app editor”, I mean the person - not the UI.
So the iteration would be under the plugin developer’s explicit control, right? That makes sense to me.
Yes, but good luck with the iteration INSIDE Bubble. I’m working on fixing that with various plugin thingies. (And this idea is one of them.)
In general, I do not think that the Bubble programmer should ever have to think about loops or looping, but think instead in terms of maps (array oriented operations) and similar structures (which are implicitly iterative, of course, but can be thought of as a single action).
Gothca. Just wanted clarification that the “iterative” functionality wouldn’t be automatic, as I can imagine many scenarios where one might want to pass a list without taking action on each item.