I thought I am already quite a bit into it - but based on your table: 1st level 
i HAVE to ask…
why is AddOrModifyRows() crossed out?
respect
max
and…
if i always use
totext(_merge(…)) instead
does that count?
I’m a fan of the explicit If/AddRow/ModifyRows/Noop. I can’t find the exact post where I was arguing for it but here’s some of the mentions:
I like AddOrModifyRows, use it all the time.
Forced Circular Recalc is funny, I didn’t know that had a name, but I definitely have a doc where I had to use it.
What are Volatile Columns and $$ Syntax?
I am somewhere between 4 and 5.
Haven’t used Cross-Doc actions and Iterator Tables (what are those?) from level 4 yet.
But use everything from level 5 if by stamping you mean logging.
the $$[…] syntax is how grid-references to objects are stored internally within formulas and buttons. they allow us to hack into the formulas to change them. the same references are used in the api. thats how you can change the name of a column or a control, and all the formulas that refer to that object will automatically appear to have the new name.
deep voodoo… very dangerous
i am not sure what volatile columns are.
and there are times when AddOrModifyRows() is appropriate, but yes, we should mostly use either the AddRows() or the ModifyRows() and get our logic right.
but folks, this is beginning to feel like a nerdy pissing contest 
respect
max
another one i am not sure of
Forced Circular Recalc? - sounds painful
max
Somewhere while descending into darkness, the whole no-code idea evaporated…
Which, I suppose, is what makes Coda so powerful. You’ll reach the the end of your personal skills way, way before you reach the end of Coda’s abilities.
And yes, i have yet to get AddModifyRow() to work.
P
Lol, indeed. This is just a meme I made for the talk about Coda I did yesterday at a local meetup. Don’t take this too seriously, lol.
Here’s some references:
-
Iterator tables — tables that perform some repeated action over a dataset externally. Initially the reasons for them were different (absence of
WithNameand very costly Button columns), but they are still relevant with another reason: to keep business logic away from the data. E.g. I have a Patreon Admin doc where I add patrons and add doc templates, and I use an iterator table to generate rows for new Patron-Doc associations (instead of having a button on Patrons table to generate all templates for a patron, or having a button on Docs table to generate this template for all patrons.) -
Volatile columns — columns in your tables that are not saved to the doc and are not global but unique to each user looking at that table. This is an anti-pattern because it mixes presentational logic with data. But sometimes it’s a quick way to implement some interface without introducing extra tables (I’d say though that in 4/5 cases I had to eventually refactor those)
-
Forced circular recalc — just had to come up with a catchy name yesterday, lol. But the trick is to write formulas in such way that they trigger repeated recalculation until some stable condition is reached. This is achieved when formulas get recalculated in separate frames, i.e. the change to one formula will then trigger the recalculation of another, and vice versa, until the result of either is not changed anymore and the loop stops. Very fickle because these are very likely to break on any engineering changes to CFL (Coda Formula Language)
Indeed, but what oftentimes happens is that a client adopts Coda and is hooked on its no-code capabilities, but then eventually wants more functionality, which requires all those deeper dives 
Still I think the landscape improved significantly in the last few years. People make better docs now. They are more keen on getting some of those yes-code skills to make better docs than before.
By stamping I mean replacing formula columns with regular (editable) columns and writing in calculation results “manually”, i.e. with an action. This is more work and this is basically a departure from declarative to imperative programming approach (i.e. not “I want these to be looked up into here” but “Take these and put them into there”), but this gives us the control over what we want to recalculate instead of relying on Coda optimizations. This is a common technique to avoid massive recalculations on large tables, e.g. I do this in the Email matching tutorial here:
Depends greatly on how much I’ve had to drink and beverage type.
Forgive me Father, for I have sinned…
…and just used AddOrModifyRows() myself:
And this is one valid reason to use it: if regardless of whether the row exists or not I still want to modify it. See how the check is on three columns but there’s an extra Is list to merge column that gets set every time to a present value.
HAHA! Same It seems I am way up in the sky above the iceberg. 
The brilliant thing about coda is that you can still get a huge amount done there… And then one gradually moves down as needed.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.