Newbie Guide: Using States & WF Sequencing

[ihsanzainal84]

@boston85719

I personally think it is better to make use of a plugin, although my go to is no longer karma ware available, the developer did spin it off into a paid plugin of theirs, but there may be some free ones out there that do the same thing. This helps to reduce the need to run actions to load data, and eliminates the need for states to determine if the data is loaded or not as the plugin (if well built) will provide for those types of values already.

Most definitely. Since ListShifter is no longer karmaware, Floppy is the very first purchase I’ll make for each new app.

@boston85719

Could you provide some evidence provided by Bubble that confirms this? I understand that all actions are triggered just after the previous action is triggered, so action 2 is triggered after action 1 is triggered and doesn’t wait until action 1 is complete, and I’ve never heard that there is a difference between the type of actions (ie: client side versus server side). I see this when in step by step mode trying to investigate the setting of a state and it will not follow the order necessarily (may be the known limitation with step by step that causes this).

In the example it’s just part of a test. I only use pauses for visual elements. I don’t like it when my loading element flashes for like 300ms and purposefully add an additional pause to make it show for a second or a half.

@boston85719

Could you provide some evidence provided by Bubble that confirms this? I understand that all actions are triggered just after the previous action is triggered, so action 2 is triggered after action 1 is triggered and doesn’t wait until action 1 is complete, and I’ve never heard that there is a difference between the type of actions (ie: client side versus server side). I see this when in step by step mode trying to investigate the setting of a state and it will not follow the order necessarily (may be the known limitation with step by step that causes this).

There are a number of posts about sequencing, but I’ll quote @keith since his explanations are always in-depth. He goes into even more detail as the thread goes on:

Workflow sequence for client-side actions

In response to (1): The Element > Set State action is entirely synchronous, AFAICT. Which is to say, if you have multiple Set State actions in series, even if they don’t depend upon each other (via "Result of [some previous step]), they complete one-after-the-other. You can easily test this by making a workflow that does Set State for the results of a long-running search (stored somewhere as a list called “Results of long running search”), followed by Set State for some simple scalar value (e.g…

Here’s some general info from the manual:

General rules about how workflows run:

• Frontend workflow actions run in order but the next action does not wait on the previous action to be complete before triggering.

• Backend workflows are triggered as soon as the workflow is triggered, independently from steps. For example, a “Schedule API Workflow’” action will be triggered as soon as the workflow is triggered even if it is placed last in the workflow action sequence.

• Custom events run in sequence, not parallel. If Workflow 1 triggers a custom event that starts Workflow 2, Workflow 2 will complete before the remaining actions in Workflow 1 run.

• Searches aren’t always immediately updated with new data. So if you create a new item, and then try to retrieve it via search, it may or may not work; you should not rely on this.

  • Retrieving a thing from “result of step X” where step X is the “Create…” step should always be safe.

I have a small test page for state sequencing but it reflects how I set up complex workflows in my apps:
coffeehat-sandbox | Bubble Editor

Just to add as a reference to the types of client-side actions I refer to. From the manual:

Client-side processing
Many actions that you run in your app do not need to be sent to the server to be completed – indeed, many of them can’t be processed on the server since they refer to things happening locally on your user’s device.
For example, events, actions and conditions such as the ones listed below will in many cases be completed locally:

1. Navigating between pages by use of the Go to page action.
2. Displaying or hiding elements.
3. Changing the appearance or styling of elements (colors, fonts, etc.).
4. Validating user input in forms before submitting the data to the Bubble server.
5. Performing calculations or manipulating data locally.
6. Saving custom states with local content (such as user input)
7. Triggering animations or visual effects.
8. Running custom JavaScript code within the browser.
9. Do when condition is true where the condition does not happens server-side
10. Do every X seconds

@boston85719

You should explain this a bit more, or link out to the forum thread that was originally posted explaining this…it is important for others to understand the differences and what each would be used for.

Here’s the link to the thread for those looking:

Search: count is 0? Or Search:first item is empty?

So, since the change in pricing model, and the introduction of WUs, I’ve spent a LOT of time (probably way more than it’s worth) testing many, many things in Bubble to establish the most WU efficient ways of doing standard (and not so standard) things, especially in relation to loading related data (lists versus no list etc.) and bulk data processing. I’ve been tempted to publish my findings so far, for the benefit of others, but I’ve held back as I’m yet to be convinced that it’s actually a wo…

Thanks for the peer review!

I should remind everyone (not singling you out) that Bubble has its quirks. Like search :count vs search:first item is empty, the way search:filtered works, and how current date/time works in a workflow (it will use the current date/time that the event was triggered).