One of my favorite things about Coda is the power in the Coda formula language. Wielded correctly, column formulas in Coda can do everything from finding needles in haystacks of data, to building a custom doc-based app to manage your team’s workflows. But one error in a formula run across a large table can have serious implications for your overall doc performance.
As our favorite web-slinger’s uncle once said: “With great power comes great responsibility.” Which is why we made it our responsibility to help reduce such errors.
Now, when writing column formulas, we’ll provide more specific warnings for some of the most common errors—like comparing arrays to scalar values—and even offer to auto fix some common errors right in the formula builder. If you see something underlined in yellow, now it’s a good idea to click that item to see what Coda recommends before you commit and try to run that formula.
For now, our detection will center around mis-matched data types, and we hope to further expand our ability to provide guidance for more types of formulas directly in the formula builder down the road.
In the mean time, please don’t forget the following resources that are available to help you build the formulas of your dreams:
coda.io/formulas has all of your on-demand formula documentation
coda.io/webinars has the schedule of our upcoming Formula Fitness webinars; and
Of course, our support team is standing by to assist when we can!
This is great at the micro level - is there a way to have it work at the macro? To have it give you a list of all costly formulas in a doc? That would be great for rehab’ing a doc.
Perhaps this could be combined with the Debug Calculations tool to find the formulas needing this treatment?
I see a lot of improvements, the editor is also helping with using currentvalue.some_field vs thisrow.some_field.
But I also see that this function:
is not working anymore. That might be intended, but since lookups are case sensitive and user input can be very random. I have to make an extra uppercase (or lowercase) column to do these kind of lookups - that is a lot of extra overhead for something that used to work without an extra column.
Now, if some of these functions could have an extra parameter to specify case-sensitive (or not case sensitive) lookups, coda would be another bit better than it already is.
The same would be very useful for filter() and some other functions.
Of course, until a couple of days ago, we already had that with the formula that I show in the screenprint above. Is it really intentional that this is not working now?
I still run into the issue where I reference Name (which is shown as CurrentValue.Name) instead of CurrentValue.Name which is apparently a different value.
Can you try this with Filter() instead of LookUp()?
LookUp() is a formula that uses Filter() behind the scenes, so I’m curious if this is working for the filter version and if we missed this part or if it’s affecting both.
EDIT:
Actually, I was wrong about the above statement. The engineers just let me know that there was a change made to the LookUp() formula. Now it will require that the second parameter is a column. You might need to move that part of the formula to it’s own column and then reference the column. That, or you can try using Filter() there instead.
OK - I will try that.
It would be nice if the engineers communicate about far reaching changes before they implement them - I had quite a few things fall apart.
!
