Conditions

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".

Placing conditional expressions on elements let you change their styling based on whether the expression returns a yes or no answer.

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.

In this example, the Create a new thing action will only run if the expression in the Only when field returns a yes. If not, Bubble will skip it and move on to the next action in the workflow (if any).

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.

The event in this workflow checks whether the current user is logged in. When they are, the workflow will run. Note that it is set to Run this just once, which means it will only run once per session (page load).

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

Element conditions are used to change the properties of an element when an expression returns a yes. Element conditions consist of two steps:

1. The expression that defines when the properties in point 2 apply

2. 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).

Previewing conditions

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.

Our Academy quick tip on how to preview conditions on an element

Run-mode debugging

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 (workflow conditions)

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.

In this example we have created a yes/no field called Admin on the user and we check that it's set to yes on the current user.

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.

Alternating workflows and actions

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.

Here we have two workflows with the same trigger (button clicked) but only one of them will ever run, depending on the admin status of the user.

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.

Creating efficient expressions

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.

Click the image to enlarge.

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.

Using conditions for security

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.

Obfuscation versus security

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.

Element conditions

Using conditions to hide/show element, make them unclickable/uneditable and/or changing their styling is a common way of providing and communicating security.

It's a good practice to implement styling conditions as a part of your UX, but it should not be considered a secure way to stop a workflow from running.

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.

Workflow conditions

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.