Conditions
Last updated
Last updated
Conditions, or conditional , let you set up mechanisms that check whether a specific question returns a yes or a no answer and then take an action, stop an action or make a change in your app in response.
Conditions rely heavily on the use of expressions. We recommend that you get to know how dynamic expressions work.
Article: Dynamic expressions Reference: Data sources Reference: Operators and comparisons
For example, if a user fills out a form but leaves a required field empty, a condition could be used to check whether the field is empty and, if so, prevent the form from being submitted until the missing information is provided.
This is used in several different scenarios:
Element conditions lets you change the styling of an element based on the value returned by an expression. For example, you can make a button by asking the question "is the user logged out".
Only when-conditions are placed on or that have already been triggered, to stop them from running if the condition does not return a yes. Only when-conditions are both a useful part of Bubble's workflow logic and an important part of your app's security.
For example, you can stop a from running if an input field's value is empty.
Do when-conditions are workflows that trigger automatically if an expression returns a yes value. For example you could run a specific value whenever the question "is the current user logged in" returns a yes answer. They can be set up to run once, or every time the value changes.
Backend triggers are also workflows that triggers based on an expression, but they run in the backend and server-side meaning that they run independently of any page.
They can be used to trigger changes in the database.
Article: Backend triggers
Element conditions are used to change the properties of an element when an expression returns a yes. Element conditions consist of two steps:
The expression that defines when the properties in point 2 apply
The properties that should be modified when the expression in point 1 returns a yes
In the example above, we make a button unclickable if the user is logged out. The styling is dynamic and instant, meaning that whenever data in the conditional expression changes, the styling of the element is immediately applied.
You can place multiple conditions on the same element, and more than one can be active at once (for example, one condition could make the button unclickable and another could change its color). If there are conflicting style options, the condition at the bottom will override those at the top since conditions are read top-down (as such, the bottom condition is applied last).
When editing an element's condition, you can click ON/OFF to preview what the element will look like with its properties changed. This has no effect on the element in Run-mode.
As an element can have more than one condition, several conditions can be evaluated to yes on the same element. You will often have to debug an element's behavior when it involves conditions to understand its behavior, we recommend using the Debugger to inspect an element and figure out which condition is evaluated to true and how it impacts the element's appearance.
Only when conditions are applied to workflows and actions to ensure they only execute when certain conditions are met. For example, if you have a button that triggers a workflow you can instruct Bubble to check every time the button is clicked whether to proceed running the workflow.
If a condition is applied to a workflow, it will prevent all actions within that workflow from being executed. It's also possible to apply a condition to an individual action, which will only prevent that specific action from running.
You can also use conditions to alternate between different workflows depending on specific conditions. For example, you could have one workflow that completes a database operation like only when when current user is logged in and another workflow that shows an error message only when the current user is logged out.
The same can be achieved by placing conditions on individual actions. If you have workflows with multiple action steps, we recommend keeping the two alternatives in separate workflows as it makes it easier to manage.
To learn more about how expressions are evaluated, we recommend reading the section How expressions are processed in our article about dynamic expressions.
Article: Dynamic expressions Article section: How expressions are processed
An expression is processed until it reaches a definitive yes or no answer. This means that if an earlier part of the expression provides the necessary response, Bubble will not evaluate the remaining parts. This is to optimize for efficiency, as it reduces the amount of work needed.
You can further optimize your app by giving careful thought as to how your expressions are built. Knowing that Bubble evaluates from left to right and only processes what it needs to, we can make the app as efficient as possible by placing the fastest part of the expression in the beginning.
It's difficult to set a hard rule for what makes an expression slow down, but we can give some general guidelines:
Expressions that evaluate something based on information already on the page are generally the fastest. For example:
Current user is logged in
Element is visible/invisible
Element's value is X
Database operations such as Do a search for need to be sent to the server, processed and sent back to the device, meaning it can slow the expression down. The more complex the search, the slower.
Operations that are processed on the device are generally very fast, but can become slow if they are doing complex processing. For example, if you have two repeating groups holding hundreds or thousands of things and you use the intersect operator on it (repeatinggroup1's list of things intersect with repeatinggroup2's list of things) you can end up with a process that takes some time to finish.
In this example we are checking two things to verify if the task should proceed. The first is information that Bubble already has and can quickly check client-side. The second is a search that has to be performed on the server – it will take longer. By placing it last we can avoid having to check the last step if the user is logged out.
By determining which components of an expression are likely to take up the most time, you can strategically arrange them such that the quicker parts are positioned at the beginning. By doing so, Bubble has a higher chance of finding the required answer in a shorter amount of time.
Conditional expressions are an important part of your app's security, but it's important to understand how some conditions provide proper security while others only provide obfuscation.
The phrase "Obfuscation is not security," is common when discussing security, and this holds true for Bubble as well. While obfuscation may increase the difficulty for an attacker to exploit vulnerabilities, it cannot provide sufficient security to be deemed truly secure.
That's not to say that you should avoid obfuscation. It's always a good thing to make it more challenging for attackers to exploit vulnerabilities and it can also be an important part of the user experience. The important thing is to be aware of what can be considered and what can't.
Using conditions to hide/show element, make them unclickable/uneditable and/or changing their styling is a common way of providing and communicating security.
While this makes good sense from a UX perspective, it's important to note that it should not be considered secure. Since the elements on your page are part of the downloaded application code, a technical user could be able to find ways to change the styling, such as showing an element that is supposed to be hidden.
As such, this should be considered obfuscation.
Placing conditions on your workflows and/or actions are a more secure way of stopping unathorized use and are, along with Privacy Rules, a central part of your security.
Still, there are some guidelines you should follow to increase security:
Conditions that can be checked are more secure than conditions that rely on something on the .
A typical example involving the server is to check something in the database, such as Current User's Admin = yes. Since Bubble can check this without relying on anything on the client's device, it can be considered secure
An example of the opposite is to check something on the page, such as "Element X is visible" or similar things. This would rely on information on the user's device, and is easier to circumvent
If you have multiple courses of action depending on a condition, it's easier to stay on top of your security if you place them in separate workflows, rather than in one workflow with conditions placed on each action. This minimizes the number of conditions you have to update if something changes.
Always remember to test your app as different users to verify that conditions are working properly.
