When I have single button with more than one triggers and I want to move to next trigger, I have to get out from the current and open the next, when you have a list of triggers, lets say,10 triggers, it is very hard to remember if I entered the last one or not, if there where buttons of Next and Previous inside the trigger, life would be much simpler.
Moving to next trigger meaning building it in the editor? Or moving to next trigger by clicking the button multiple times?
Moving to next trigger within the current one doesn’t exists yet in Tulip, I suggested to add this ability
Hey @Amit -
Totally understand your pain here. It strikes me that the root cause here is not the ability to swap between two triggers, but the need for 2 triggers in the first place. If everything is happening on the same triggering action why do we need 5-10 sub groups of actions to achieve your goal. There is some work just starting right now to make trigger building far easier, more scalable, and more powerful to address this root cause. I am hopeful that work will enable all of your logic in most cases to live in a single trigger.
Hope this context helps-
When you need to check more complex logic with and & or statements that checks several inputs from different input texts, you need to split the logic into several “functions”, so, understanding the logic later will be like any other developing language, easier by any person who will have to investigate the code for any reason.
In those cases and many more you must split those triggers into several and the movement between them is horrible.
I hope that the work on triggers that you are talking about will make life simpler.
Hey @Amit -
This us usually what drives me to segment my logic too, so each trigger acts as a function that is standalone.
This work is intended to resolve that need too, the plan is to make triggers something that can be saved for an entire instance and reused throughout your apps. In this way you could build a complex logic flow to calculate a key metric, and then reuse it across multiple apps. This complex calculation function would be represented as a single action when it is used in each app.
The closest parallel right now in the product is something like connector functions. A trigger could be established on a global level and shared in many different apps.
I don’t know if you are familiar with SAP programming but what you described similar to function groups that contains a list of function module, each one stand alone, gets inputs - do logic - set outputs and can be used anywhere, you can even say that your new way of thinking similar to old dll files and the list of example can go on and on.
I liked this way of thinking but the question is, will those variables configured inside this “function” will be local and not recognized (as they should be) in the calling app ?
Hey @Amit -
Yeah, this is a common approach across a number of tools. Right now the focus on the engineering side has been the backend work needed to be able to support this sort of functionality, so I can’t share too many details to stuff like variable scope, because those decisions are still in flux…having said that, I totally agree that those variables should be local to the logic block unless they are acting as an input or output.
This is the approach we take with props in custom widgets, and one that has proven to be incredibly powerful. I am actively advocating for product decisions that limit the number of variables needed in an app.