I believe recursive custom events were banned by bubble. But you can try 2 (or even 3) identical custom events calling one another as a workaround.
If you’re okay with something more inelegant, you can create the thing N times if there’s a small upper bound (say 30) - just put a condition on each action. I’ve done it for 10 items. Not pretty, but gets the job done quickly and I move on to something else.
In Design, create custom state “count” as a number with default value of 0.
In the regular frontend Workflow, create custom event “Main Loop” with the “Only when” condition set to “index’s count <= input’s N”. The 1st action should be to set the custom state of index’s count to index’s count + 1. The 2nd should be your action to add new record to database.
Then create another custom event “Retrigger Main Loop”. The only action should be to “trigger a custom event” which would be “Main Loop”. Go back to “Main Loop” and at the end, add the action to trigger custom event “Retrigger Main Loop”.
Also go to Settings, API and look under the heading “Infinite Recursion Protection” and update the Maximum Workflow depth to the number of loops to 100.
This is the setup I have with 1 difference. It works, but I think I tried to do this again without the difference and I got the loop error, unless I didn’t do something right. Let me know if it works, otherwise dm me and I can tell you what the difference is.
For my use case I am building a music app that loops through a list of text of 64-2560 max items with a bpm (scheduled) delay. This happens on demand every time button “Play” is clicked, in which corresponding background colors of a whole midi keyboard of buttons and 64 bar buttons are being changed, with each list item further split to retrieve/route individual notes into custom events to play audio samples.
That would equate to 64 workflows potentially looped and updated with the next 64 batch of items for a total of 40 times, per user. The other way of doing this would be through backend API workflow as just 1 big loop (do while index <= 2560 and play = true). In both cases, actions will contain “Only when” clauses, no database involved.
I was going to compare the two but haven’t gotten that far yet. What would you think is the better route with less timing delays? Thanks for chiming in.
Can you explain more? Because this could be the only reason to process it client side only. For example, you are getting data from API and want to process something about this API data but will never do CRUD operation to DB… However, this use browser ressource that could freeze user browser…
I don’t think I’m using API, just thought that’s how it’s named; I’m only referencing buttons, workflows, and custom states from client side. A save function would be the only time I save the list of text to the database.
In the “Main Loop” I would have 64 actions to “Trigger Play Index 1” “Trigger Play Index 2” etc., each using the index’s bar (incrementing custom state) to reference which workflow should execute - ex. (only when) index’s bar is 1, (only when) index’s bar is 2 etc. Actions of those would include changing button colors and triggering an event to extract, split, and route the list item notes to their corresponding audio samples to play.
Since Bubble doesn’t have something like “retriggerable delay” that I used in Unreal Engine (for dynamic bpm … play bar of notes, pause .1sec, play next bar, pause .1sec etc.), I can’t just insert that action in between each “Play Index” (and not have to use an only when clause). Instead, I have to run 64 queries/actions just for the correct “Play Index” to trigger FOR JUST BAR 1 … THEN “Schedule Retrigger Main Loop” to repeat 64 queries FOR JUST Bar 2 … 64 times, up to 40 times (total measures of a song). I saw a plugin that has a delay feature that I may use, but still not sure whether to go client or server side.
Here’s an old example of bars, colors, and sound playing:
