You know how we can get if/else statements on the server side (see below)?
Can we also get those on the front-end? For example, I’d like to display different alert types, depending on the response I get from a call to the server.
Might depend on your use case.
Flows have support for conditions, but you can also use ternary’s which are available in the formatter or manually type in dmx expressions:
exp ? if true : else
1 Like
Usually you use a conditional region that shows and hides content depending on the expression.
Furthermore you can use a class toggle dynamic attribute, to toggle a css class based on expression.
1 Like
Thanks, @mebeingken and @George! The information in the union of your messages is very helpful for this.
1 Like
Flows are the easiest way to acheive this.
It has a if/else condition step.
1 Like
Remember that flows have certain caveats. You can’t execute one of the same kind until the previous one has finished.
For the alerts/toasts flows are not the optimal solution as you could have a scenario where the user can spam an alert and you won’t get the next alert until you finish the previous flow.
But that would apply only to page/project level flows, right?
Not an inline flow.
If you are using the inline flow for the same component you will also have encounter this.
Imagine you have a two-state button that will trigger a toast with different messages depending on the state(i.e. subscribe/unsubscribe).
There could be scenarios where you click the button quickly and you won’t get a new toast(spam button, network issues, long running server function, etc). It would actually negate the option of stacking toasts.
I always use disable dynamic attribute on click of such buttons which invoke a SC or submit a form.
This works well.
So don’t think the issue of pending flows etc would present itself.
It has more to do with the flow running and the time needed to complete than with what event you are firing and the method used to fire it.
What I mean is inline, page or app if you are firing the same flow you need to wait for that flow to finish before being able to run that exact flow again.
I found this to be incompatible with toasts/alerts. As you will run the event, bit the user won’t get a toast notification of what he has done and if it ended well or there was an error.
I can understand the concern with page/app flows. But i’m sure this does not apply to inline flows. Will run some tests when I get a chance.
I don’t think this the case. Flows are actually JavaScript functions executed in a chain of promises, so you can have multiple executed at the same time. Being limited by just the JavaScript single thread execution as any other JavaScript function.
Maybe @patrick can confirm this.
Did you had a case @JonL that you were limited?
100% sure. You will get a nice console message saying the flow has not finished yet if you attempt to run it again. That is for page and app flows.
I am not certain for inline flows as I didn’t test those. I suspect they have the same problem as they are bound as attributes to the same html element but @sid has doubts.
It is true that a page flow component can not run while it is still busy with the previous call. This is because the component also will have the data the flow returns, when you run the flow before the previous flow was finished you will not know which data it will return, could be from the first or second call. Inline flows don’t do anything with the data and are allowed to run simultaneously.
2 Likes