Simple "else" Statements in Bubble

Sometimes in Bubble, we want to do one thing or the other. In some cases, it’s not possible to check for both cases in a single workflow, because the condition can change after an action…

For Example
-Imagine we have custom state that holds a list of images.
-When we click on an image, we want to add it if it’s not already in the custom state, and remove it if it is.

This cannot be achieved in a single workflow, because bubble doesn’t have an “else” system, only an “if”.

The workflow would run like this:
-Action 1 (For adding images)

  1. Check if custom state doesn’t contain the image
  2. If it doesn’t, add the image

-Action 2 (For removing images)

  1. Check if custom state contains the image
  2. If it does, remove the image

Both checks will be true, because the image won’t be in the custom state at first, so it will be added, which results in the second action to also be true, which will remove it again…

There’s 3 ways to solve this:
-Using an “else” statement
-Two different “on-click” workflows that checks a different condition
-Evaluating the condition before any other action is taken and saving it as a static true or false (yes/no) value.

Since building 2 workflows for a simple action adds up over-time and since we can’t use “else” in Bubble (yet), we use the third option.

The Third Option
It’s very simple really! All we do is create a custom event that evaluates the condition and returns yes or no. We then use the value of the custom event to determine which actions to take, because the value won’t change.


1) So we tried this first, and realized it wouldn’t work:

2) We then tried separating it into 2 different workflows, which works, but isn’t ideal in the long run:

3) But we then realized the best solution is a custom event:
-Give the custom event a new parameter with data type yes/no.
-Also give it a return value of yes/no

-The return value is going to be the evaluated “condition” parameter that you are sending the custom event:

-Now just use the custom event!

Hope this helps!

4 Likes

That’s neat. Why is it that #2 is not ideal in the long run?

I’ve been using this method since they launched properties for custom events and they work well so far.

I treat custom events like functions in code. Using the “schedule a custom event” action lets me run WFs synchronously too.

3 Likes

Mostly because it takes up a lot of space in the workflow tab. Other than that, it’s still a valid option

Nice one @thekeybeats2.

You can also solve this issue by using a custom event with 2 input parameters:

But with custom states with a lot of data, your method will be more performance and memory friendly. :grinning:

Okay. I see this as a novel approach that also requires two triggers in the workflow tab, so takes up equal amount of space, but definitely an interesting application of custom triggers and return data. Only drawback compared to #2 is that it requires 4 actions instead of 2, and if you copy and paste with workflows the elements the custom trigger will not be copied.

@thekeybeats2 combined your approach with how I used to structure a custom event when an else is needed (see my previous reply). I use the condition as an input parameter for the custom event where the image is also addded to the custom state.

That’s a great approach as well! Unfortunately though, the custom event would only be limited to adding/removing images from that specific custom state.

Since I have a bunch of other similar workflows that all do different things, it’s essential that I use the custom event only for returning a static yes/no.

Definitely will use your example for other use-cases though :smiley:

2 Likes

Yeah, if you are only using it once, it takes up an equal amount of space, but for me specifically, I have like 20 other workflows per page that follow a similar structure. I can just reuse that one custom event for each of them, leading to 19 less workflow blocks. Pretty neat!

And yeah, 4 actions compared to 2 is big, but it’s a hit I’m willing to take. I’m hoping it doesn’t slow my app down too much :sweat_smile:

True that. But I just use a custom event (as described before) every time an else is needed. You never know when a thing needs to be added to that custom state through another event (click, when condition etc.), a good way to centralize/reuse logic.

2 Likes

That is cool. I bet you could probably put that into a reusable header and make use of it anywhere you need a yes/no value returned.

I always used 2 different workflow, but this seems like a pretty neat solution!

Thanks!

1 Like

Yeah, thats a great way to use it too, more efficient.

1 Like

@thekeybeats2 Thanks for sharing your approach.

In such scenarios, I use “Make changes to Thing” action as a proxy to evaluate the condition and then checking whether the result is empty or not in subsequent steps

Here is my approach:

a. In Step 1, add “Make changes to Thing” action

  • Under “Thing to Change”, you can add Current User or any other record.
  • Note: No need to modify any field here. The sole purpose of this is to serve as a step that evaluates the condition.

b. In subsequent steps, I use “Result of Step 1 is empty or not” as proxy to original conditional.

  • Result of Step 1 is not empty - means the original condition we evaluated is true
  • Result of Step 1 is empty - means, it is false

An added benefit of using this proxy approach is that the “Result of Step X” [Thing] also becomes accessible in subsequent workflows when the original condition evaluates to true.

1 Like

I actually never knew this. I mean, I do this with “Make changes to” but didn’t realize you could keep it completely empty and it would still work like this.

Anyway using parameters and multiple return data conditions is a pretty nice way of dealing with if/else and also has the added functionality of being able to run stuff in order.

For example I have one yes/no return that always returns yes that indicates that the custom event is finished running. Then I have another return that is text based that indicates the type of custom event. That way I can repurpose the same custom event in multiple locations in the same workflow with different effects.

1 Like

Have you checked how much WU this costs if any? I find this to be an odd workaround.

This does cost WUs and should be replaced by another method, likely, the best method is the one outlined by the OP as it is pretty nifty and only costs WUs when the yes/no is evaluated if the yes/no evaluation incorporates data in the DB.

The use of make changes to thing to find out if it exists or not incurs the WU cost of 0.6 for make changes to thing even though it doesn’t actually change any data.

3 Likes

Yeah true. 'Make changes to a Thing" does consume WUs when the condition evaluates to “true”.

@ihsanzainal84 here is the screenshot of WU consumption.
image

1 Like

The only thing that sucks about custom events is that you can’t ignore privacy rules with them.