How to Coda with True() and False()
Some tips & tricks while dealing with logical operators
When you start learning how to Coda you rapidly come across statements as ‘outputs true or false’. Honestly speaking, in the beginning I had no clue what that meant. I was simply happy when a filter or an If statement worked and did not care so much about true or false…
In this blog I share some learnings I picked up along the way, as well some tips and tricks to make good use of True() and False(). Once you see how True & False play a role as conditions, it becomes easier to Coda correctly.
When is an outcome true and when false? We start with simple examples and integrate bit by bit the outcome in a filter.
You can ask for example if the date in column ‘Name’ is smaller or equal to the date of Today.
The above formula with ‘contains’ can be written shorter via thisRow.Name <= thisRow.Noeland this is because here we compare numbers since dates are formatted numbers and numbers love logical operators type ≤ or ≥ or = .
Why we use Contains
Before we continue, a few words on the usage of Contains(). I consider it best practice in many cases to use this function instead of the logical operator “ = “ , see below.
Using Contains() can be read and interpret as ‘is equal to’. Certainly people with an IT background instead use “ = “ or when they want to exclude something it goes like below with !=”.
This goes all well and fine when you want to reference one column in your filter as in the above. It becomes complicated when you want to:
- Reference values living in multiple columns.
- Reference virtual values, the outcome of a function.
To keep my functions readable I decided to use Contains(). It permits to easily adapt the content of what should be contained or excluded using Contains().Not() as alternative for “! =”
An other advantage of the function Contains() is that it can contain multiple (lists of) items. Is the value equal to 1 OR 2 OR 3 and so on than there is a match, it is true. See also this contribution
In short, when we discuss the true or false output of a Filter function, we try to apply Contains() instead of “=” and Contains().Not() instead of “!=”
We see that we can use False or True to have check boxes (un)checked, though practical, there is more to it. We wrote a formula that had two options. The date of today is equal to the date in the column Name or not thus True or False. We then used the comparison in a filter and in this case we only have one outcome.
We can also write a function that gives us the dates after today, like below. In this scenario we have two rows that fit the filter criteria and thus in the column where we have the filter function active, we have two outcomes per cell.
We created via the filter a list of dates fitting the criteria ‘dates after today’. Since the display column is on the column ‘Name’, it returned the dates. In case these dates represents the birthdays and we put the names of the people as display column, we get the following.
The filter outputs the values only if there is a match, only if ‘true’, nothing related to false and that important to notice. A checkbox logic shows true & false outcomes, a filter only the true results.
True is the game maker in a filter and false the game breaker.
The filter
We start with the poetic description of the filter function:
FILTERA formula returning a boolean value (true or false). Use "currentValue" to reference the current item in the list. When filtering a table, "currentValue" will refer to a row.
Without any formal IT back ground this type of proza is close to incomprehensible. But as you noticed before this is understandable when you see that via a filter you compare and once the comparison ‘fits’ or ‘matches’ (outputs true) you can or ask for more information or you can calculate. If there is no match the result is a blank.
True or False outcomes are only possible if you compare comparable items. You cannot ask if the name Louise is equal to 6, but you can ask if the length of the name Louise is equal to 6 and you can use this outcome in your formula like below. We took the sum of the length of all the people with a birthday after today. It is kind of meaningless outcome that only shows that once you have a proper functioning formula (meaning it checks for ‘truth’), you can ask for about anything.
The virtual true
In my previous article I described a way to check for virtual values, thus values that are not present in a table as such. These values are only living in the calculation.
Left you see the base table and the formula to > tocheck and the result it outputs: true or false. We compare values living in the same row.
The table right looks the same, but is quite different. Left we compare row per row inside one table and we notice per row the outcome. Right we compare the list of values living in the column ‘to’ with the values per row in the column ‘to check’. We compare 8, 15, 25, 50 first with 4, next we compare 8, 15, 25, 50 with 8 and so on. Every time we see only outcomes that relate positively to this list of values. Thus only for outcomes that are true we get a result. Number 64 does not return true, it is a false and thus there is nothing to show. The filter function shows a blank []
FormulaMap with True & False
It is interesting to see how the above logic plays out when we apply the function FormulaMap() . See below for the Coda proza:
The application of this function outputs a serie of true & false because each item in the list is evaluated and the evaluation is shown. When there is a match (or fit) it is true, if not we see false:
The filter showed result only when ‘true’, the FormulaMap() is indifferent to true or false as condition. It simply evaluates every item in the list and if the logical operator in our example outputs a true for an item it is shown and if it outputs a false as well. The FormulaMap does not reduce the outcome by only accepting ‘true’, it evaluates every item after item and tells if it fits the criteria or not.
Both Filter() and FormulaMap() have their place and practical application in the Coda Formula Language.
The main lesson here is that within a Filter True is the condition, while for FormulaMap it is a possible outcome. In a situation you only want to evaluate a sub section of the list, you first Filter (true as condition) and second you FormulaMap.
Before we finish one more thing.
The Checkbox True & False
The most obvious true and false values come to us via check boxes. And as many of you, I assumed for a long time we only had these two options: True (checked) or False (Unchecked). But it seems we actually have three:
The Blank one is as empty as the UnChecked one, but is nonetheless different and I leave it up to Paul to explain why:
P.S. Why != true and not = false? Because the checkbox can have the third state: blank. It can get blank if one presses delete or backspace on a cell — it’s gonna look a bit more translucent than an unchecked checkbox. Blank checkbox will not properly test for = false but will properly test for != true. Just a precaution.
And how this can be problematic you find here and here. Time after time users run into trouble because they deleted the checked value instead of altering the state by clicking on it.
The offered solution by checking on True or Not True via !=True() offers a way out. Likewise you can Filter() or FormulaMap() and require that the currentvalue is true as a condition to proceed with for example count or sum or something else.
This blank version only appears when a user erases (via delete or back space) the check.
Conclusion
I hope you enjoyed this article. If you have questions feel free to reach out. Though this article is for free, my work (including advice) won’t be, but there is always room for a chat to see what can be done. Besides you find my (for free) contributions to the Coda Community and on Twitter
My name is Christiaan Huizer and I am the owner of Huizer Automation. A company specialized in serving SME in harvesting data and keeping it aligned. I am a Coda Consultant & Expert and rely mainly on Coda, Mailjet, Zapier & Paperform to get the job done.
