Add to cell value - Overcomplicating it?

Hello Community! :wave:

I built something but I can’t make it match to the date range picker and I might be overcomplicating it. If you know a better way to do this, feel free to add you ideas in the comments :slight_smile: Also, if the Updates column could be in bullet list it would look wayy cleaner (if you know how to do that it’s a bonus).

*The goal of this is to save rows (this doc will get big)

Thank you :pray:

Short answer: yes.

Since I’m the one who hinted at the idea of using lists vs separate rows in another recent topic, I think I should chime in here too.

Here’s what I’m thinking. Using lists in cells are a viable design choice if:

  1. You don’t need to calculate much out of them. E.g., in my timer example, it’s just sum minus sum. When you find yourself using FormulaMaps over those a lot, this is a bad sign.
  2. You don’t need to edit the data there
  3. You already have table structure that you don’t want to refactor
  4. You absolutely must conserve row count (although it’s just postponing the moment when you’ve got to upgrade to the Pro tier — at which point you must think whether saving $10/mo is worth all that trouble)

Otherwise I’d say go with separate rows. Especially in your case when you want to separately calculate added in selected period, today etc.

Also, IMO, bad idea to store updates like that, in formatted fashion, and then parsing them to extract the date and the value separately. At least store those as two separate lists: of dates and of numbers, in two separate columns. You can always iterate and match with Nth()

1 Like

Thanks for your feedback @Paul_Danyliuk

So I did take the idea from your timer, thinking this could help the doc in it’s scaling since there would be less rows. In the example below, only 1 value is pulled, but ideally I would pull 8-10 value from each weekly update. Each update will create around 20 rows if not merged into a cell, but this number will go up significantly each week as we publish more ads (Values would be daily spend, clicks, etc).

Do you think it’s better to link back to a table with all the data separated or would it be a better idea to merge the updates by updating existing rows and filtering from there?

Again, thank you, you’re definitely the master here :mechanical_arm:

Is upgrading to Pro a problem to you, so that you need to ration the rows?

If not, then better go with the separate table, separate rows per update entry, and good old lookup.

@Paul_Danyliuk already a team user, just looking to scale the doc to the max. Thanks

Separate table with separate rows will scale better and perform better too (if my assumptions about how Coda works are correct)

1 Like

Often times a column that requires recalculating on nearly every action can be heavier on the doc than several smaller values only updated occasionally. The more you pack into one column formula, the more likely you are to run into it needed to recalculate more often.

This is always a gray area though and really just takes trial and error for a lot of it. There is no absolute answer at the moment, just options to try.

This is a great help article on how to optimize formulas and calculations:

1 Like