Hey everyone, a quick trick I just learned myself!
When you have multiple triggers tied to one action, they execute in order until one trigger has a transition fire.
There are times where you want to use multiple triggers, but only execute earlier triggers given certain criteria. A common example is field validation for buttons which process data being inputted. Before learning this trick, I would use a “Can proceed” variable to control my triggers when I use multiple such as this trigger in “Show 1”
Then, inside of “Show 2” and “Show 3”, I would use a conditional statement to determine if I still needed to run that trigger.
However, a much simpler solution when you need to “break” from a group of triggers is to simply route to the current step. This will prevent all following triggers from executing, and there will be no noticeable difference to the user.
This trigger will end the string of triggers after showing message 1. No variables or additional triggers to worry about!
It is very valuable to separate triggers. This is a neat little trick which can make them slimmer and easier to understand!
Nice solution, but this has the following disadvantage for my use cases:
If you have any step enter trigger you need to check the behavior of these carefully. So I often use the step enter trigger to clear all fields and reset important variables. Not so good
Exactly… that’s why I mostly use a boolean variable, that i set to true at the beginning and any trigger will flip it false, if something goes wrong.
This variable also is a condition for any trigger to execute…
I know that’s not as easy as reloading the step, but it is clear to understand and flexible (you could still select which triggers to fire or not etc…)
This has been a product gap for way too long. I use both of these strategies quite often and it confuses many less experienced Tulip developers who I am either working with or training.
@dan.pomeranz Personally, I sometimes simply test if a table record ID is blank or not (ID being the only mandatory column in a table) and use this to accomplish what your Can proceed variables does. It’s less explicit but it is enough and rather understandable in several cases.
@ChrisF Agreed! And same remark for On step exit triggers.
One thing that was not mentioned so far is the fact that this solution relies on the fact that Tulip will keep behaving the way it does (that is, transitioning from a step to itself will not execute subsequent triggers, then execute On step exit, then execute On step enter triggers).
I’m a bit worried that someday, this might not be the case anymore because one could argue you are not exiting and entering anything since you stay at the same step. So if your app relies on exit and enter trigger execution, a bug might appear. (It would be even worse if the transition would be considered to have no effect at all triggers after the transition would execute, but the chances of this happening seem quite low to me).
Regarding your last two paragraphs-- the Tulip team has been outstandingly committed to not making breaking changes like this. There have been small examples which Tulip has mitigated painfully, but this specific example would be a momentous change for most customers. You should not worry about that!
