@mallika I took me a while to discover that when needing just 1 section (but not all the other sections) from a community template … since there is no way to Shift / ctrl + click and then delete, the most efficient way to delete multiple sections is to add the unwanted sections to a folder and then delete the folder containing all the unwanted sections
Oh, and this fact too:
When you reference the master table in the formula, it always works on a full set, whether or not a filter is applied.
When you pull the same data from a view, it will only use the filtered subset.
Sorting setting doesn’t matter in either case, you need to explicitly
.Sort() in your formulas:
And this is sometimes very useful also in terms of efficiency, so relying on [Views] (if possible) it helps to improve the overall “speed”.
IDK, I prefer to rely on master tables only — more predictable that way. I like to explicitly write in my formulas what exactly I need from the full data set and how.
One exception is that if it’s a formula that is only used once and nearby the view in vicinity — e.g. a header saying Hello
User(), today you have
[Your tasks view].Count() tasks. I.e., when it’s apparent that this formula describes the view beneath it.
UPD: When I meant “rely on master tables only”, I meant in the context of working with the full data set directly and not segmented via lookups. If e.g. I have a table of users and a table of tasks, I’ll first pull in each users’ tasks into a lookup column of a Users table, then refer by
@Some user.Tasks. I won’t write it like
Tasks.Filter(User = @Some user) in that case. TL;DR: If I can connect the data, I’ll do that first.
@Paul_Danyliuk, I had the same feeling: somehow it’s like not really be sure of the underlying data.
I discovered it really helps a lot (i.e. better UI performances) when many rows - and many columns - are involved.
Often it’s just a matter of proper View naming.
Think about the overall historical
Exchange Rates (master table) and
Current Rates (the View with current valid ones) anytime you need to have exchange computations.
Looking up a single field with few rows dramatically increase computation times.
Anyway: didn’t want to drag the attention away from this post
@Federico_Stefanato Never tested it actually, but I think that if we were after micro-optimizations, we wouldn’t be using Coda but write it in C++/Java/etc
I mean, with tools like Coda, I believe good data design and sensible conventions are more important than performance.
But yeah, there are always exceptions, that’s why I always say use your best judgement.
However, in your case I’d say you could approach this differently and have both better design and performance. I’d keep the historical
Exchange Rates table, but instead of the view I’d make a
Currencies master table that looks up the most recent exchange rate for each currency into a lookup column. Then reference the
Currencies table when I need to get the most recent rate — e.g. with a direct row lookup like
I’d love to keep this discussion open
I’ll write you in private (in order not to deviate this post)
@Paul_Danyliuk - this is fixed now. now you would see all allowable columns in the dropdown. - the fix would be deployed in a day or two. Thanks for reporting the issue.
Oh, and also this:
Have used Coda for ~9 months before I accidentally discovered this.
I knew that one already from excel
After two years, THIS:
This will probably sound silly, but I just realized that when I add a column to a View, it gets added to the base table. I thought views become their own table that can extend the base table. I mainly didn’t notice this because I tend to not modify a view’s table structure, only visuals.
I often add columns for buttons only to the View, thinking that it is stored off separately in the View only.
Do you think this was always the behavior, or do you think after the
WithName introduction the behavior might have changed (or around then)? Remember, it used to be that you could only add the
RunActions at the beginning of your formula, you couldn’t include it inside of your loop iirc
If you could only put
RunActions at the beginning of your formula then it would always be the same behavior.
I have a feeling it’s a recent change introduced with this patch:
because this one hints at how Coda changes the behavior of actions to be non-blocking in certain scenarios.
Or it could be a change introduced along
WithName(), although I don’t remember any regressions in this regard at the moment.
Fact: I don’t remember having any problems with omitting RunActions() in a FormulaMap before. I only noticed it now. I was doing quite a lot of client work and I used to omit RunActions() quite often. So I assume that if this behavior existed before February, I would have caught it already. I had a pause in consulting since February, and I only caught it now. I also caught a few bugs around using CurrentValue and WithName in FormulaMap/RunActions.
That’s why I’m concerned in the first place. What if this is a recent change indeed and many of my old clients’ docs are now broken?
Other than this, there’s evidence of RunActions() forcing sequential behavior back in 2019:
There’s no evidence that lack of RunActions() used to run non-sequentially though.
Never heard of this; I never doubted that I could use RunActions anywhere, it never gave me any errors. FWIW I joined Coda in Mar 2019; maybe it was different before that.
Interesting fact: a button would always implicitly wrap your whole action in RunActions() even if it’s just one action that you’re running. You can inspect that by “merge()-ing” the button and seeing its pending evaluation formula.
Escape Characters in Strings
@ references to other rows, especially useful in filters like
thisRow = @otherRow. This is a pattern I use in every doc I build now, but for the longest time I never knew about it (and I likely never would have discovered it)
- That publishing a doc in Edit mode is vastly different from sharing a doc in Edit mode. I think this would have been clearer if it were to be called “Product mode” or “User mode” to make it clear that the user could push buttons but not edit text (I know it’s in the tooltip, but my familiarity with the word “Edit” made me think that there was nothing new to learn)
Set as Display Column, I initially didn’t know that this also changed the value that the column resolves to. So changing the display column on my early docs would cause bugsthis seems to have been fixed. Now you cannot implicitly coerce a row to its display value. Nice!
Great stuff @Connor_McCormick
@mallika seems difficult to be discovered lately - we are missing you my dear.
I had a problem as described towards the bottom of this post: How to automate adding multiple rows from one table to a new table with a button? - #7 by Carl_Haugen
I tried to cross doc a table and it drove me nuts that my filter function for an automation button did not work as I expected. I cross doced a tasks table, and the tasks table had a lookup to a project table.
When adding a filter function for the “project” column I got the message that the referenced data could not be found, but I mistook that for being a limitation in the cross doc table instead of that the actual data could not be found. The reason for this was that I saw the data in the table just fine. Except for it being marked (with dotted lines perhaps)?
I think it would be a good idea to add a slight better error handling or inform the users better in this case. Perhaps you could add something like “(references in cross doc’ed tables need to also be cross doc’ed)” to the error message of "Data referenced could not be found). Or adding a red dotted line or something to the column data and a popup on mouseover of “data can not be used in functions unless referenced tables is synced” or similar. Perhaps you could add a “do’s and don’ts” to the “Cross Doc” page that always pops up when adding a cross doc.
How easy it is to convert numbers from hexadecimal numeral system to the decimal one using
… of course I first chose to use a helper table to do my conversion before looking more closely at ToNumber() …
i STILL find reverse lookups non-intuative and must refer back to earlier documents to see how its done.