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…
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”.
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.)
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?)
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…
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.' );
(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,