TUTORIAL - How to achieve 'Loop Until' action safely in Weweb, 'no-code'

[AgentD]

INTRODUCTION
Hi community, my name is Doye but everyone calls me D. I am a Flutter developer and a big no-code enthusiast too. I adpoted Weweb as my web platform of choice 2 months ago and it has been amazing . I often like to contribute to the no-code communities I belong to (and I am looking forward to the marketplace). But today I wanted to share a decent no-code solution to a question I have seen come up quite a lot in the community forum

THE PROBLEM - How do I perform a repeated action until something happens, aka, the While Do workflow
This is often needed when you need to poll an endpoint for example and you wanna keep doing that till you get a response. There is no direct way to do it in Weweb, but when I needed to do it, I found a way to get it done safely without triggering infinite recursion.

A THE PARAMETERS -

1. Create a global workflow call it “loop until” (or anything you want), give it two parameters – max_loop a type number and delay a type number too.

Max loop will be used by you to set an upper limit for your loop function (you know like a max retry), this is because you don’t want your action going on forever if there’s a bug for instance).

delay is the gap in miliseconds you wanna have between the loops. This is important because you don’t wanna flood the server you’re polling.

B. THE HELPER FUNCTION
Next you get a function that generates a random array any length that you tell it to (don’t worry, just ask the AI to generate it for you).

C. THE WORKFLOW ITSELF
The workflow is simple. On execution you open a for loop (or iterator as we call it here)

1. The array the for loop will iterate over is a random array of length = the max number of loops you set (that array you would generate from your helper function remember?)

2. Now the loop is open, the first action in that loop is whatever the logic you wanna repeat.

3. Next put a true/false split to evaluate your stop condition (the thing that you will get to make you stop polling e.g. a 200 response status)

4. After the true/false block, you put a delay timer whose value = the delay parameter you picked when calling the function.

5. Now for what is in the false arm of the true/false you can leave it blank and do nothing

6. For what is in the true arm. This is what you execute when your stop condition is met and you wanna exit the loop. For this, just put a custom javascript code there and in the code write break; That’s all, nothing else, just break.

That’s it. This workflow helps me process an item that I needed to poll every 3 seconds for 3 minutes no problems.

Note that the break will actually force an error which will kill the action. (So if you need to do anything before exiting the loop onSuccess, uno, maybe send a success message or something, make sure you put it BEFORE the break)

Workflow images below

complete workflow structure

I’m happy to answer any questions you may have. This way you can long poll on weweb safely with minimal risk of flooding your server or infinite loop.

PS: because it is running as an async execution the loop WILL CONTINUE without blocking other actions even if you leave the page where you called it. So you can use it for ‘Chron-like’ tasks (PS, you should do chrons in backend).

[AgentD]

Workflow images below

Random Array generator in use

[AgentD]

‘break’, breaking the loop.

[dorilama]

There is no need for random values inthe array, in this case it doesn’t matter what values are in the array, only the lenght. You just need something like this: Array.from({length:10})
Have you actually tested this tutorial? Using the break statements on its own is not correct and will throw an error. The loop wil break because of the error, but anything after that will not execute, and the “on error” part of the workflow will trigger.
There is a basic example by Aurelie about how to implement this kind of loop here

[Broberto]

Yeah also using this for " ‘Chron-like’ tasks" is just a straight way to tech debt. I appreciate the effort tho.

[AgentD]

Hi @dorilama

First, yes actually it’s the length you need. But as the plan is to use the Weweb native iterator with as little code as possible. Just makes it easier for anyone to understand.

Second, the ‘error’ is precisely the plan, you use the side effect to bring the entire action to an end and force an exit (if you plan to do anything at the end of the loop before the exit just put the action you wanna do before the break, very simple)

If you try Aurelie’s method (which I did try at first), it did NOT work consistently. Some tasks didn’t finish (you can try it yourself and compare both methods). I implemented a simple counter from 1 to 100 (Aurelie method for whatever reason didn’t always get to 100 in 20 trial runs). The workflow I put above got to 100 all 20 times. Even after I navigate away from the page and do other things.

And yes of course I’ve tested this tutorial. It works flawless tbh. Feel free to try it yourself. Perhaps you could have a better way with as little code.

[AgentD]

@Broberto lol . Thanks for re-emphasizing this point.

One should do ‘Chron’ tasks on the backend ideally (which is why I put that caveat there). But that being said, there are super unique instances where you make wanna run a small check in the background while on the front end (especially if it’s not doing anything serious).

In programming tbh, there are almost no Absolutes. Any programmer will tell you that. It always depends on the use case.

Finally, given the inability to support SSE no-code right now in Weweb, and websockets aren’t that easy for no-coders either.

I do believe this method will help a lot of builders achieve their polling functionality in a safe manner that won’t damage things.

[dorilama]

Got it. I missed the part where you specified the error strategy and the caveats