I’ve spent the past few days trying to work out some IF/THEN logic for a side project. The problem is that this is something I could have worked out in a matter of a few minutes with actual code. I’m running into several limitations with the current IF/THEN logic we currently have in Glide.
First of all there inconsistencies between what’s possible with an IF/THEN column, and what’s possible with If/Then logic in visibility conditions or actions.
- Most importantly, an IF/THEN column only allows for ELSE logic if a condition is not true. There is no way to check if multiple conditions are true with and’s/or’s before moving on to the next ELSE condition.
- Visibility conditions allow for AND/OR logic, but not a combination of both, so you are stuck with either everything true or only one of the conditions needing to be true. Sometimes you need condition A AND B to be true OR condition C AND D, but that’s not possible at the moment. It’s either all conditions or only one.
- Custom actions allow a little more flexibility for all AND or OR logic combined with ELSE logic, but there is no way to combine AND’s and OR’s in the same condition check, so you have to build out several ELSE conditions so it can fall into the correct slot to fire off the correct actions. Sometimes you are building the same set of actions because you want A AND B to fire an action ELSE you want C AND D to fire the same action. Right now you have to duplicate the set of actions.
That’s three different methods of dealing with IF/THEN AND/OR logic and it’s not consistent between any of them. Custom actions handles it the best out of all three, still could be expanded to allow for combined AND/OR logic in the same condition check.
I have a situation where I was adding actions that did absolutely nothing (set column action that doesn’t set any columns) depending on a variety of different AND/OR conditions, but the number of ELSE conditions in the custom action was getting out of control and hard to follow. One small change would throw the entire thing out of whack, and if I need to add another condition, I had to try to mentally run scenarios through my head just to visualize where in the ELSE structure I needed to add the condition and would it cause other conditions to never fire. So instead I started to put some of the logic into an IF/THEN column, in the data, so I could end up with a single value to check in my custom action to determine if it should do anything or not. Problem is, the IF/THEN column follows a completely different procedure and has no AND/OR logic, so I’ve been trying to twist my mind around to make the right scenario fall through to the right conditions, based on several criteria, to return a TRUE/FALSE value that I can use in the custom action. Every time I get close, I find another loophole scenario that doesn’t set the correct value. I could probably break out the IF/THEN column into several IF/THEN columns, then combine those results into a final IF/THEN column, but that adds another level of complexity and confusion.
If would be so much easier if we could use logic similar to what any programming language uses:
IF a=b AND/OR c=d
ELSEIF a=c AND/OR b=d
To me, the oversimplification of IF/THEN handling and the inconsistencies of how it’s handled in different areas of Glide has caused some trouble. Instead of checking if a set of multiple conditions are true, sometimes we have to reverse that thought and check through a variety of false conditions and let the default ELSE be true. Most times it’s reasonably doable, but not intuitive to most people. Other times, we have to put IF/THEN columns on top of IF/THEN columns just to check if multiple conditions are true. Any time conditional logic become multifaceted with multiple possible conditions to check, then it gets really ugly and almost impossible to look back later and understand what and why you set it up that way. I think expanding on the IF/THEN logic to follow what a programmer would normally expect would actually make it easier for non-coders to understand.
I’ll try to expand with a bit of an example using my calculator app.
My number pad is an inline list of tiles. They all call the same custom action. What I’m trying to do is prevent users from typing a decimal more than once. Also, I’m trying to prevent them from typing a negative sign more than once…unless they have already inserted number after the negative sign, then the the negative will switch rolls and actually run the calculation, move the result to the left side and await input on the right side of the math operation. In addition to the negative sign serving two roles, I have to check if the user typed any numbers in, are they using any of the scientific calculations, did they type a negative or decimal already, etc, etc. There is a lot of things to check, but I also start to run into problems with the conditions messing up some of the other buttons that may or may not be allowed to be pressed. It’s a complicated structure that I’ve spend a few days on to clean up and make simple, but I keep finding loopholes. If I fix one thing, I break another. The IF/Then structure in code would be super simple but I just can’t find an elegant way to approach it without making a complete mess.