Hey @tylerboodman - some general notes about element plugins (and I know you’re not referring to @vnihoul77’s plugin , but):
This feature is not available to plugin developers in either the element or client-side action plugin API’s. So there are no third-party plugins that can do this.
What they do instead (for element plugins) is publish the value(s) that result from some element action to an exposed state. Because this is all they can do. (I have made repeating entreaties to Bubble to enable such functionality in the client-side actions API [and, by implication, the element actions API as well], but this is something that’s not available yet. Though it might be something we see added early next year, if this can be trusted.)
Right, in many instances (which are hard to fully document because it really seems to “depend on a lot of reasons”), the exposed state may not be available yet to certain downstream in-the-same-workflow actions by the time Bubble decides to trigger them.
What a well-built plugin will do is trigger an event after the exposed state values are published to that the Bubble programmer can key off of that event and continue with actions that need access to the published values. (You may want to check if the plugin you are using offers such an event - sometimes these are present but not documented in any meaningful way.)
But of course this is neither documented nor required, but it’s a best practice that more experienced Bubble plugin devs are familiar with. If our element plug has an action Blah, we would publish the results of Blah to the element’s “Blah Results” output (exposed state) and then trigger an event like Blah Complete. In Bubble element API code:
instance.publishState('blah_results', results)
instance.triggerEvent('blah_complete')
And you would use that triggered Event (which appears in the editor under Workflow triggers as “Blah Complete”) to continue doing something after But not all plugins are designed this way.
If such an event isn’t available, you can (particularly if you’re only using the action in question once), create a workflow that triggers on the “when some condition is true” type workflow trigger on when “such and such plugin’s exposed state” is not empty. This will go true when that output goes from its initial state (which is typically empty) to being populated.
If you’re using such an action (which has no triggered event) multiple times, this becomes a bit more problematic, but you can watch for changes to the exposed state in various ways (one great way to do that is with the Floppy Expression Watcher element).
In recent times, a bit of not-entirely-untrue (but also not-entirely-true) Bubble folk wisdom has sprung up that if you encapsulate some workflow actions that act synchronously with respect to one another in a Custom Event, and then follow that with another Custom Event that also contains actions that are synchronous with respect to each other, that the whole chain will then be synchronous.
But, this is not true in all cases, as I observe in this video and subsequent discussions. Until we have a proper way of returning values from a plugin action to the workflow (meaning that not only can we return values to the workflow from plugins, but that the presence of a value in “Result of step x” is actually respected), there won’t be an elegant, universal solution to the issues you’re facing.
Note that server-side actions do return values to the workflow and using such “Results of step” do in fact enforce synchronous operation of downstream actions that depend of those values, but that’s the only context in which we have access to that feature. (And, obviously, server-side actions are not appropriate for most in-page type things we might do with plugins.)
!
Detect VPN and PROXY use
