Tutorial: Iterator tables (CurrentValue workaround)

After answering the CurrentValue issue questions so. many. times, I finally recorded the tutorial on a Coda data processing pattern I use as a workaround for this very problem. It involves creating single-row helper tables that store outer CurrentValue values into cells, so that they’re accessible in nested Filters and FormulaMap loops. I call this pattern Iterator tables, and beside being a workaround for CurrentValue, these are very powerful for doing more complicated calculations

The video is ~40 minutes long. The first ~8 minutes explain the pattern using a simple example. The rest of the video discusses a much more advanced use. Also I noticed only now that my webcam window overlaps pieces of formulas :sweat_smile: sorry for that, see the sample doc below.

TL;DR:

  • Create a single-row table with a button that first thing stores CurrentValue in each FormulaMap into a separate column. Then reference that column when you want to retrieve that value.

Pros:

  • Elegantly works around the CurrentValue context issues. The table is like a collection of variables.
  • Avoids doc bloat because of buttons in each row — shrinks the doc tremendously if your table has lots of rows.
  • You can build very complicated calculation logic there.
  • You can break that logic down into steps, and examine for issues more easily, step by step.

Cons:

  • Takes some effort to setup (but you know whom to hit up if you need some paid assistance :wink: )
  • Most likely, you won’t be able to set up automation to run this for you. In one of my setups automations were failing with unspecified Coda error.
  • Iterating over large datasets will generate hundreds or thousands of Coda “ops” (tiny edit operations), which are then sent very slowly (like, 4 per second) to Coda servers and synced to other collaborators. You’ll have to wait for the doc to save all changes before you can close the tab. You’ll know when it’s not finished yet — trying to close or reload the tab will show you a warning.
  • Frugal free plan users: it adds 1 table and 1 row to your object and row count :scream:

Also, the sample doc:

Once again I remind you that I’m going to run a blog codatricks.com — please subscribe for tricks like this. I’m ashamed to say it’s been a year and I still haven’t started publishing anything there, and I’m putting everything out in this Community instead. For me, writing articles is much harder than just spinning unrehearsed single take videos like this one. But I’ll get there.

16 Likes

Thank you! I’m going to have to check this out and will let you know if I have any questions. Sorry for the late reply it’s been a little hectic but I am back now working and improving on my doc.

Hey, @Paul_Danyliuk.

Thank you very much for this tutorial.
I have this doc that all my work depend on that was running really slow.
It had a table with more de 2000 rows and seven buttons.
After removing all buttons from this table, my Doc went from 129MB to 68MB in uncompressed size
Your post should be in coda.io help pages. :grinning:

My question is how do you think Coda will tackle performance and scalability, as Shishir say in his road map, when it has these very limiting issues?

1 Like

I think in the best way possible :slight_smile:

3 Likes

@Breno_Nunes We are intimately aware of the problem here and are actively working on some dramatic improvements. Performance issues can be a bit more complicated to address, so please stay tuned!

1 Like

@Paul_Danyliuk , wanted to hop on to say thank you. I’ve repeatedly struggled with needing to use AddRow with nested FormulaMaps and this iterator table concept is just the ticket.

1 Like