How Scalable & Efficient are "Do When" workflows?

I’m trying to find a consistent alternative to the “when page is loaded” workflow, considering my app is an SPA that uses URL Parameters to show and hide content.

That means that every single time you do nearly anything, I’m using a “go to page” workflow, and thus am triggering bubbles native checker of “hey the page just reloaded, let’s go through every single page loaded workflow just to check whether we need to perform an action right now.”

even reusables that aren’t visible will still trigger their when page is loaded workflows within the debugger.

so yeah, would “do when” be a good alternative? The logic would pretty much always be active.

I’ve tried using Gauravs If-Then plugin, but when you keep the logic on 24/7 it starts to drain too many resources!

Add condition when page is loaded and this reuseable element is visible

On the “do when condition is true” workflow, you can do “when URL parameter is equal to…” or “when reusable element is visihle”. As far as I know, this uses event listeners on the page. Although you wouldnt want to use way too many of these, in general theres nothing to worry about when using these in terms of performance.

However, i feel like if youre having to ask this question then you might want to take a look at reworking the page architecture.

1 Like

There is absolutely nothing wrong with that if the conditions are set properly and things are not triggering when they are not supposed to. Bubble is incredible performant when it comes to evaluating conditions and skipping over workflows that evaluate to NO…so unless your issue is based on the fact that when you are debugging and using the step by step in the debugger and this causes an annoyance for you (does for me) to see all those get skipped over, than, there is nothing wrong with using them if done properly with conditions.

It is an alternative, but remember the difference between the two…the when page is loaded is not for a completely loaded page, it would grammatically have been better to be labeled as when page is loading since it is actually something that gets triggered when the page first starts to load, and not when the page is loaded, as in past tense a completed action. Alternatively, the do when condition is such that it will trigger when the page is started to load, as well as when the page is completed loaded, and comes with the handy selection of do always or only once.

No need for a plugin to structure conditionals as that is all they are, they are if then statements

2 Likes

when it comes to a SPA though, I feel like the best solution is for bubble to not even have to evaluate those workflows. people expect instant feedback when doing basic stuff inside of an app.

I obviously can’t get rid of all page-load workflows, but I am trying to minimize the work load if possible. I’ll experiment with “do when”

That is what Bubble has done when it evaluates a conditional…if the first portion of the conditional is not met, it doesn’t even bother to evaluate the remaining portions of the conditional, nor does it attempt to run through any of the actions (if the conditional is on the trigger).

If you are experiencing issues with your triggers and the speed at which they are evaluated or that they are running when they should not, you should take a closer look at how the conditionals are structured.

I personally have never experienced an issue with performance related to on page load triggers for an SPA

1 Like