I’d often like to use a pattern like: FOR EACH [item], IF [condition] THEN [action], where no action is taken if the condition isn’t true. The hidden formula _NOOP can accomplish this, but this document is too important to risk using hidden formulas.
I found this thread from 2021 that indicates SwitchIf() can be used for this purpose because the default value is optional. That seems to be true, but as soon as the SwitchIf() that occasionally defaults to ‘no action’ is placed within a FormulaMap, it doesn’t work- the first time the condition isn’t true, the formula exits with an ‘Invalid Action’ error. Example here.
I’ve been handling this with a clunky approximation of _NOOP; whenever I want no action to be taken I have the formula delete rows from a dummy table that exists only for this purpose. It works, but it seems like there must be a better way.
Your observation is in line with my experience, even in the SwitchIf() we need the _Noop() in this scenario when the evaluation returns false. Leaving the fall back option empty or putting "" or List("") does not work either.
May you feel uncertain, you can create a value in the fall back option you filter on as condition for a delete action.
_Noop() is okay and won’t break — it is heavily used internally. Tell you this, your whole button becomes a single _Noop() formula when it is disabled okay not really anymore previously it was a pendingevaluation object as well, now it’s a sentinel value.
Wondering if anything changed recently because contrary to what Christiaan said, "" used to work fine in place of _Noop(), i.e. you could totally If(expr, Action(...), "")
P.S. Just checked, yeah, no problem whatsoever here
Reason #1 is that they could be looking for a less technical or generally more elegant way to set up a noop action — an average person wouldn’t know what noop means, and even not every developer would. I suspect that the support for "", which was added sometime in 2022, could actually be that elegant solution that they were seeking.
And reason #2 is… I dare you to find a single video from Coda themselves where they are teaching how to set up buttons with complex actions. Because all I’ve seen so far were Maria’s videos where to make multiple actions, she’d advise to make a button that clicks other buttons. And to make those buttons conditional, Coda would advise to just use the “disable if” formula. That’s why I made a special focus on these in my video about buttons. I suspect that Coda prefers to treat that flexible custom actions feature as something too pro, and since there is already a workaround for pros with the _noop(), they wouldn’t prioritize making it more accessible to beginners just yet.
Huh, yeah, seems like when a button produces a list of actions but there are blank items (i.e. "") that’s where it would fail now. I think it’s introduced recently, like a few months ago, because I’ve seen a similar behavior change with some other code that I had to go and fix, I don’t remember now exactly what that was. In a nutshell, Coda got stricter with what it expects as a result of a button action formula: it has to strictly be a single action or a list of actions (or a one big blank) but not a list of lists anymore, and not a list with blanks in there (`_Noop() is not a blank, it’s still an action, which simply does nothing)
Well, since in your formula you’re building a list of actions, you can just filter out the blanks — this works:
thisTable.FormulaMap(
If(
CurrentValue.Value = "Cat",
Results.AddRow(Results.Result, "You added a Cat."),
""
)
).Filter(CurrentValue.IsNotBlank()) // <- this will clean up the blanks
@Yannik I’m not a codan and cannot really answer that. From what I’ve heard, all the analytics and customer discovery that Coda conducts show that even stuff like this is above the average of what average users are doing with Coda. So we might be a minority at the moment. Things will probably change as the adoption grows and more power users get onto it.
previously it was a pendingevaluation object as well, now it’s a sentinel value.
