After nearly a year, I am still looking for ways to effectively structure the functionality of an app. Bubble seems to abound in possibilities but none seem to be ideal.
I have read and reread sections of the manual and reference describing workflows, but I’m not sure I fully understand how workflows work.
However, based on my understanding, Here’s something I think would be immensely useful:
Part 1: In Custom Workflows, support parameters just as can be done for API Workflows.
A simple use case is when a Custom Workflow is written to make updates to a thing. It is written as a Custom Workflow so it can be used throughout the app to ensure that updates of the thing are done in a consistent manner. (Most important among reasons for standardizing updates is to ensure referential integrity.)
Because there may be many fields to be updated, a potential source of error could be eliminated or reduced if all fields needed for the update are defined as parameters for the Custom Workflow.
Part 2: Custom Workflows can return values that are usable by the triggering workflow.
A use case is when the primary action of a Custom Workflow is to create a thing. The created thing can be returned and used by the triggering workflow.
Currently, the only way I see this being possible is by way of custom states in the reusable element containing the workflow. It would be much clearer how to program the use of a reusable element Custom Workflow if its input parameters and return values were defined in its interface.
Background Understanding
Although I have read and reread docs regarding workflows, It’s entirely possible that I’ve missed something important about how they currently work. The above suggestion is based on the following understanding of key workflow types. If I am wrong in what I describe below, please correct me.
A “primary workflow”, i.e. one that is defined on an element and triggered by an event associated with the element, doesn’t appear to be something that can be triggered programmatically. It is only triggered if the defined event happens. Therefore, its functionality is not reusable and must be replicated other places it is needed.
An API workflow supports parameters passed into it. However, there is apparently no way of returning values to a workflow that called it. Apparently, the API workflow runs asynchronously and the calling workflow cannot wait for its completion.
A custom workflow on a page is only available to other workflows on the page. It does not encapsulate any data, i.e. custom states. It can freely work with custom states on the page or in any element on the page. It is not available to any other page.
A Custom Workflow in a reusable element is available to any workflow on a page that includes an instance of the reusable element. It has access to all the custom states within the reusable element. (I don’t know if it has access to other custom states on the page that incorporates it.)