Make things modular
Make your application easier to build and maintain by reusing components where possible
Last updated
Make your application easier to build and maintain by reusing components where possible
Last updated
Whenever you have an action (or similar actions) that need to be run from multiple places on a single page or reusable, you should use custom workflows so that you only build the workflows once. It's easy enough to copy and paste workflows when you're initially developing, but maintenance gets out of control very quickly.
For example, on a search page, changing any of the search filters may need to automatically update the search results. Create a custom workflow that applies all of the relevant filters at once, and run this workflow any time a filter is updated.
Since custom workflows only support one data source, you can always use hidden variables to store additional information if needed.
If you need a workflow to be accessible from multiple places, and using an API workflow isn't an option, consider building the custom workflow within a reusable element and adding the reusable to any places you need. When an event happens in any of those places, you can use the "trigger a custom event from a reusable element" workflow to run it.
Backend (or API) workflows should be used for any intensive workflows that are triggered from multiple places within the app. They execute on the server rather than the client, so big workflows won't slow down the user's experience. There are two major considerations/limitations:
The workflow step after the "Schedule an API workflow" step won't wait to start until the API workflow itself has finished running. This means that your workflow should not rely on an operation within the API workflow because there's no guarantee it will be ready in time. Workflow steps within an API workflow, however, will execute step-by-step, as will custom workflows within the Backend workflows tab.
You shouldn't rely on API workflows for anything that needs to happen immediately for the user on the page because the user is able to interact with the page before the API workflow is finished. Take a messaging interface, for example. When a user sends a message, you should create the message on the page, so it's immediately visible. Then, you can use an API workflow do things like notifying the recipient.
API workflows are particularly great for handling operations on a list. Bubble's "make changes to a list of things" and "delete a list of things" actions can be unreliable at scale, so using the "schedule an API workflow on a list" is a good option instead.
Database triggers are a powerful but tricky tool that can help further cut down on redundant workflows. You define an event that detects when a certain change is made to the database, either through the app's interface or the Bubble database directly, which triggers any workflows you'd like.
There are two main use-cases for database triggers:
Keeping certain database fields in sync. For example, if you want to make sure that a User's "First Last" field is updated any time the User's "First" or "Last" fields are changed, you can set up a database trigger. That way, you don't need to remember to modify the "First Last" field in every workflow that updates the other fields.
Scheduling the same API workflow in one place rather than several. If you find yourself scheduling the same API workflow in many different places, consider using a database trigger instead. For example, if a certain workflow needs to run any time any field is updated, consider creating a new field called "Update?" and a database trigger that runs the workflow any time "Update?" is true. Then, just make sure to set "Update?" to true in any places you want the API workflow to run.
It's easy to unintentionally cause database triggers to fire, so use them with caution!
Reusable elements are pivotal for cutting down on redundant UI (and workflows, as described above). If you find yourself needing similar or exactly the same UI in multiple places, a reusable is the way to go. You may need to use conditional statements to show/hide elements or on workflows if the same reusable needs to be used differently in different places. For example, if an Admin and a Standard user both need access to the same popup on their respective dashboards, you may need to hide some of the popup's fields for the Standard user. Ultimately, it's a judgment call as to when there are enough similarities to warrant using a reusable.
