Dynamic Typing on Plugin Outputs (ala MishaV's JavaScript to Bubble element from Toolbox)

Hey, @mishav, where you at? Seems you’ve not been here in a bit. I’ve a question about Toolbox… It would seem that the JavaScript to Bubble element (from Toolbox) has a unique feature: Its “value” output (which I assume is just an exposed state) seems to have a dynamic type. (Its type is set in the interface and then the element/Bubble expects that type.)

How is this accomplished? (Or am I missing something obvious?) In the plugin editor, it seems that one has to declare the type of any exposed state. So, I don’t see how the “value” output can have a variable type.

It’s entirely possible I’ve missed seeing something…

This question isn’t just for @mishav, but for anyone who has insight into what I’m getting at…

Thanks,
K

Are you talking about using the app type? You can choose which type of data to return the value in, whether it be custom from your database or text, number, etc.

Ex - A field you have is app type called choose_type.
Then in your exposed state you make the type of data “as choose_type”.

1 Like

I’m going to say that you are 100% correct, @tim12333. That must be how that works. And I had a sense for that from working on server-side plugs… But I failed to realize this must be how JS to Bubble works.

(My own issue is that I’m building a plugin with multiple output modes – a date picker where the “value” output could conceivably be a single date, a single date range, or an array of dates… heck, it could output multiple [an array of] date ranges, but I think that might make Bubbler’s heads explode. These modes are dynamic, so they should not have to depend on user input… but seems there’s no way around that.)

Thanks for your answer and for the tip!

-K-

Sounds fairly complex. For that I’d probably use 4 exposed states -

  1. a single date
  2. a list of dates
  3. a single date range
  4. a list of date ranges

And just let the user choose what they need as well as use conditionals in case they’re not sure exactly what input they’re gonna get.

Good luck!

Yeah, that’s what it does now (and fires off an event noting that picking is complete, depending upon mode). Thanks so much for chiming in here, @tim12333!

Aside: I think I just realized why triggerEvent() has a callback. (The question is: can one await the response of that callback to check if the workflow failed or not. Or is success assumed until failure is confirmed? And, if so, isn’t that a bug?)

Not sure, I haven’t played around with the trigger event callback.

I would think the callback only happens once the workflow is finished - either successfully finished or finished early because an error came up.

Thanks again, @tim12333. I feel (but have not tested) that this must be the case. I did wonder why this callback did not have args (err,data), but then realized that a user must instantiate that action. This creates a documentation problem, but… what the hell… ignore the docs at your own peril…

EDIT: tl;dr callbacks in Bubble are weird-ish.

@sudsy… I see you typing here… what choo got?

I believe @tim12333 is correct on that.

As I understand it, the callback IS the response indicating success or failure of the WF. The callback’s err argument is simply null if no error occurred. The key thing to bear in mind is that this is all asynchronous.

So for instance, let’s assume an error occurs during the following triggered workflow…

instance.triggerEvent( 'my_event', function( err ) {
    if ( err ) {
	    console.log( err.message ); // Assume err.message = "Error occurred!"
    } else {
	    console.log( 'No error.' );
    }
});
console.log( 'Here is the next line.' );

…then what will get printed to the console is…

Here is the next line.
Error occurred!

Just thought it was worth pointing out.

1 Like

I’ll be checking this out in the AM.

(the only issue is that err should be UNDEFINED, not just null, if we are still awaiting the result, should it not?) Null is falsey, as is undefined. I’ve a feeling somebody at Bubble has thought of this, but FYI/YMMV…)

But it would seem that this is how one creates a hook inside of an element,

It’s really unfortunate there’s not more info-sharing in Bubble plugin-land as the docs are so lacking…