As Coda users want more and more complicated calculations in Coda, a pressing need for some temporary key-value storage arises. In conventional programming we use variables for that, e.g.
var result = /** some complicated filter **/
if (result.size > 0) {
result.doSomething()
}
to avoid calculating the result twice.
In Coda the closest analogies are:
-
in column formulas — you can extract pieces of calculations and store them as separate columns whose value you can then reuse.
In simple cases that’s okay, but with things like working around the
CurrentValue
context problems, the only working solutions become unapologetically complicated.Simple or not, such extra columns that exist solely for the purpose of breaking down a calculation into steps still take up extra doc space.
-
in actions — you can store intermediate values in dedicated cells, like I show in the Iterator tables approach.
This works, but it also generates a ton of unnecessary edit operations that still get sent to the Coda servers and all the collaborators. Coda simply doesn’t know that I’m using the cell as a temporary storage — it thinks I want to edit its value for 1000 times per minute for real. Because why else would any sane person call
ModifyRows()
on it?
I see two solutions to this.
-
Add variable support in formulas.
This is ideal but tricky. The problem is formula syntax. In action formulas we could write something like:
Tasks.FormulaMap(RunActions( SetVariable("Current task", CurrentValue), Projects.Filter( CurrentValue.Tasks.Contains(GetVariable("Current task")) )... ))
i.e. we can code multiple steps in an action formula. But we cannot do that in column or canvas formulas — those can only contain one function that takes inputs (which could also be functions) and produces an output, so no way to call things like
SetVariable()
within such formula.Knowing the limitations of Coda, I’m not ready to advise any solution on this front. Maybe the rest of the community can chime in.
-
Make it possible to designate specific columns as in-memory, i.e. not stored to the doc.
Coda already does this with volatile formulas — i.e. those that directly or indirectly rely on
User()
,Now()
, orToday()
. These are only calculated in-memory, in a user’s browser. I suggest to extend the same capability to any arbitrary columns that I mark as volatile.It will not be a complete solution, but it could be a non-breaking, relatively easy to add capability that would solve some of the problems listed above. At the very least, it will not bloat the doc size nor spam Coda servers with so many meaningless edit operations for values that are only needed temporarily.