Modularity
When building functionality that is used in multiple places throughout the application, you should build in small chunks (modules) that can be replicated or used in other parts of the app. AirDev recommends splitting app logic and UI into modular pieces when Bubble complexity reaches a point where it causes confusion.
An example:
You have a complex sign-up flow where users' personal information has to pass through multiple steps of verification. Users must be able to access this sign-up flow from multiple pages of the app, and from different types of buttons for desktop and mobile users.
In order to set up this example, we can build this functionality in a Reusable Element (like Bubble's signup/login reusable) with a Custom Workflow for signing up users.
Before reading through this information, make sure you're familiar with how to use Reusable Elements, API Workflows, Custom Workflows and Plugins. This page covers when/why to use them.
The easiest ways to introduce modularity to your workflows (WFs)are through custom workflows and API workflows. Situations in which you might want to use one of these include:
There are >10 steps in a WF (too long for readability/ease of development)
Parts of a WF are reused in different places throughout a page
A WF in a reusable element needs to be triggered from outside the reusable element
An entire WF is copied and reused elsewhere (sometimes with minor changes to conditions)
A workflow is slow and sometimes times out (takes >30 seconds and throws an error), causing poor UX
API workflows offer the benefit of being accessible from anywhere in the application, or even from outside of the application via API, and they don't have the same timeout limits as normal workflows. Note, however, that if your application hits capacity, API workflows will be slowed down.
Some times to use API workflows:
Action doesn’t need to be completed immediately (e.g. exporting data where the export file is uploaded to the Bubble DB or sent to a user’s email)
User WFs keep timing out on the page (take >30 seconds) or users have very poor internet
WF is used in multiple pages, and the custom workflow isn’t in a reusable element that is present on each of those pages
WFs are triggered from outside the application
If a workflow is timing out, try to speed it up before creating an API workflow. Only move it if you are unable to prevent timeouts from happening.
Custom workflows can be faster than API workflows for the types of actions that a user would expect a near-immediate response from, or actions that a user must wait for before continuing (e.g. signing up for an app). Here are some situations where it is better to use a custom WF:
Actions make changes to elements on the page (showing/hiding elements, displaying data in groups, element-type plugins)
Alternative strategy: Use an API WF and set a listener to detect when the API WF is done (usually through checking for when changes are made to some object in the DB)
This is not ideal, but it is an ok way to get around the 30 second WF timeout
The WF is only used on one page, and none of the above API WF reasons are true
If the WF is in a reusable element and needs to be triggered from outside the reusable element
Sometimes, the trade-offs between a custom WF and API WF aren't clear until you actually attempt the implementation. In that case, you can try one of the two and see if it performs well enough in terms of execution speed and reliability.
Departing from workflows, reusable elements are useful when you want to make your app's visual design more modular. Here are some situations to use them in:
Your app needs to do the same thing (or nearly the same thing) on more than one page
Your page is a Single Page Application and a group has complex, but isolated functionality
Faster editor loading b.c. of less elements
Cleaner WF view
The group will likely be reused in other applications or on other pages, and it has some complex functionality
E.g. chat, comments, to-do list, menu, instagram-style display, or search filters
Users who know how to use the API Connector or who have some Javascript experience should consider creating plugins. This is more useful for creating modularity across applications rather than within the same application - you (or other users) can reuse the same functionality in multiple apps, and update it once in order to update it for everyone.
Situations where it is a good idea to build a plugin include:
A page uses a lot of custom code through the Run javascript action or you need to create an element with code
You create an API through the API Connector and you think other people would find it useful, or you want to use the same API in another Bubble app
App Templates are a more unique and labor-intensive way of working modularly, and are more relevant to Bubble developers who will build many apps. This is what our AirDev Canvas template is meant to do - it makes it so that builders can more quickly make fully-featured applications, without having to waste time on setup that you will do with every app you create.
AirDev Canvas allows you to build apps more quickly in a way that creates a visually consistent user experience across mobile and desktop. You can add modules that we have designed and build functionality on top of them, making it a breeze to create pages that look and work great.
