Variables and Logic-How much is too many?

I need to send data through an api. There are 8 variables I need my app to consider before sending the data off. I think the decision needs to be made when button element is clicked.

For example-when group state is Y and Thing is X and Thing’s Thing is 0 then use “this” api form.

I know how to build it. My question is a) is there a cleaner way and or b) is asking the application to make 8 decisions going to slow down the app substantially if there isn’t a cleaner way to build the logic?

Hi @brian5,

It’s difficult to say when we don’t know exactly what the variables are. For simplicity’s sake, you can think of it in three layers here:

  • Conditions that don’t touch the database - LIGHT
  • Conditions that check something in the database (for example Current user’ boolean = yes) - MEDIUM
  • Conditions that calculate something in the database (for example ProductsInCart:sum) HEAVY

This is by no means a scientific way to measure it, but you get my point; the more you ask of the database, the slower the condition.

"Outsourcing" conditions
One solution that I like to use when a workflow depends on a lot of conditions, is to place the conditions elsewhere, so that you distribute the workload over time. For example, you can create a group and give it Type of content: yes/no. Then you place all the conditions needed for the workflow on that Group, and if they are all true, the Data Source for the Group is yes.

That way, Bubble still performs all the conditions, but since it happens before the user clicks the button, you avoid the slowdown. Same operation, better UX.


@petter thank you very much! You answered my question and confirmed my “work around” to limit the amount of conditions. I also love your explanation of light-medium-heavy that makes all the sense in the world!

Thank you!

1 Like

Great! Glad I could help!

Hey @petter,

Do you have a simple example/editor you can share that shows your implementation of “outsourcing” conditions?

I think it may brilliantly solve a problem I’ve been stuck on awhile: I’m swamped with conditions/logic and everything is messy. Like OP, my use case is a type of “branching logic”, think of a dynamic questionnaire: if user answered “yes” to question 1 and “no” to question 2, then hide/skip questions 3-6 and show /goto question 7, that sort of thing.

@meyerhd2, I can help if you’d like. @petter confirmed what I thought with reducing work load on the app, I was just hoping for an easier softer way haha!

Lets assume you have you have you 9 variables at a traffic light red-yellow-green-stop-go-slow-turn right-turn left-go straight.

Instead of having the application make all of those decisions at once you would do it states on the application

When intersection is < 500 feet of current user location show traffic light group

When light is red set state “action” to stop
when light is yellow set state “action” to slow
when light is green set state “action” to go

when traffic light group state action is not red show direction group
when traffic light group state action is red set user instructions state to stop

When direction is turn left set state to left
When direction is turn right set state to right
When direction is turn straight set state to right

First-this is a very simplified explanation, all of these are examples of out-sourcing the work-flow so as the user gets to a point where a button is pushed (for example) that specific button has one action with no logic behind it because the user has been navigated through a series or groups-pages-popups, etc…and presented with the afore mentioned button that has a specific action.

I was hoping that this was not the case, only because it was going to require me to contemplate everything up front through the users workflow, but at the end of the day if done correctly there will be very limited data calls.

My app will have several identical groups- each one will be displayed based on the state set by the users actions and the button in each group will only have one function “create new thing” “make changes to thing” etc…

Again- I was hoping for an easier solution that required less brainpower on my end haha.

If I didn’t answer your question or told you stuff you already know I am sorry about that. If it was helpful I am happy to help more if needed.

Good luck!

1 Like

Thanks for the elaboration @brian5. I think we’re on the same page regarding the overall functioning of the app: accounting for every user possibility (paths) and limiting data calls.

For running or controlling the sequence of workflows, I tried a couple things that got unwieldy like defining prerequisites for each action with data types (too much searching) or lengthy workflows that would “manually” go through every possible path for every action to determine the correct one.

It never occurred to me to use a boolean-type group(s) to filter/consolidate a series of conditionals, so I’m also wondering what that looks like in an actual app. I’m not clear on how to:

Then, I assume there is a single workflow Do When This Boolean Group is Yes?

I may be misunderstanding anything here, it was just one of those eureka moments that broke me out of my tunnel vision!

Hi @meyerhd2,

Then, I assume there is a single workflow Do When This Boolean Group is Yes?

Yes, this is correct, or alternatively place the YES condition on the workflow Only if if it’s not meant to trigger something.

This can also be used if you have very complex conditions, to avoid nightmare-long chains of and and or, you can create more than one group (or other elements) that holds different conditions, and require that all of them are set to yes before you trigger or proceed with the workflow.

Using outsourced conditions for error messages
A bonus tip: I often use this for error messages as well. Let’s say you have a user sign up on a form, and he’s forgotten to enter his date of birth. As the user clicks submit, you want to show an alert with an error message. If you have a lot of different error messages, this can result in a jungle of actions and conditions but if you use the same method as above, but instead of yes/no, you use text, and different conditions result in different texts, such as birthdate or last_name.

Input Birth date’s value is empty → Data source: birthdate
Input Last name’s value is empty → Data source: last_name

So whenever the content of that group is not empty, the submit button should not proceed, but instead show an alert. The content of that alert is based on the text (birthday/last_name).

Hope that made sense. Saved me a ton of conditions and workflows on complex forms.

1 Like

This is all very helpful, broke a big logic-structure log jam for me! And you already pointed out where my thinking was headed:

My app is 80% path navigation/logic and 20% content (the easy part). So I’m basically scrapping most of the app and starting over with this sort of structure…excitedly though, so thanks again for chiming in on the subject and elaborating further!

1 Like

No probs! Hope it turns out to be great!

This topic was automatically closed after 70 days. New replies are no longer allowed.