Rendering delay only when not debugging

[ken1]

When I click a button my app switches “view” by hiding one repeating group and showing another. The button click sets a state on the page which the two repeating groups respond to. This has been working great until today.

When I am in the debugger, but not actually debugging anything, the groups switch seamlessly as expected. There is no visual delay. I can see this in the console after clicking the button.

But when I turn off the debugger, the visual delay starts and I see this in the console.

So clearly something is working differently. I realize there is some sort of timing error (which is not my favorite!).

Does merely having debug_mode=true cause the app to behave differently?
Does anyone understand what the two timeout handlers are above the “No Data” entry? These are what is causing the delay. When I click on run.js:115, I see this code:

I don’t know how to interpret this. Any ideas what I can look for?

Thanks!

[ken1]

I figured it out! It was in fact a timing error. I did not need the console to understand this.

In the debugger, I stepped through one-by-one and noted the sequence that each step was executing.

Then I went back to the workflows and looked at the steps. My workflow (triggered from a reusable element) has two steps.

1. JS2Bubble function call to hide/show my elements on the main page.
2. A Custom Event where I reset all of my filter values.

As I stepped through, I noticed that resetting the filter values was executing first, then the javascript function was executing. This produced the correct result.

So, assuming that without the debugger active these were not executing in the same order, I needed to force the order. To do so, I utilized the Keeper element from Listopia.

Although this is not exactly what it was designed for, it worked perfectly and simply.

I put my custom event to reset filters first, and the last step in that event was a Keeper action that just set it’s “result” to empty. I gave it an “Action Name” so I could use that to trigger the next step.

Next, I created an event that triggers when a Keeper’s result is updated and the Action Name matches.

Finally, I placed my Run Javascript step in that event.

Now, everything runs as expected/desired without the debugger. So, using a Keeper in this way is one way to make sure steps execute in a required sequence.

@NoCodeDataArtisan

[ihsanzainal84]

Keeper and @NoCodeDataArtisan are dope and doper respectively, but if you need a WF to happen after a J2B event you can use “trigger an event” and then use the J2B Trigger event to run the actions.

[ken1]

Thanks for the comment. That does not work here because the Custom event for filters is in a reusable element. The J2B trigger event is on the main page. So I need to use a step to Run Javascript so I can trigger the J2B event from the reusable.

Even with the order of my steps as 1) Reset filters in custom event and 2) run javascript to trigger the rest of the steps, they do not run in that order probably because of the reusable.

So using the Keeper, I can make sure the filters are all reset before triggering the Run Javascript set (all from the reusable) and then the sequence works correctly.

[NoCodeDataArtisan]

Hey @ken1,

As you’re aware, the sequencing of actions can present challenges in certain use cases. To address this, we’ve introduced the Action Name feature in Listopia, ensuring that each action is completed before the subsequent one begins.

@ihsanzainal84

Keeper and @NoCodeDataArtisan are dope and doper respectively

Thank you mate

[ken1]

Yes. That’s what I was explaining. I used Keeper and the Action Names to control sequencing even though the workflow did not need Keepers. They were used only for the sequencing.