I am pretty sure that in the past a common mistake I would make is treating a list that has only one item as if it was a single value.
Then I would have to place a .First() into my formula to handle that case.
But recently I have noticed that Coda is converting List-Of-One values into a normal single value without the need for the .First() function.
I am convinced its a good thing - but I wasn’t aware it was a thing.
So, does anyone know if this is a new thing?
And, are there any situations where this automatic reduction from a list to a single value might cause problems?
For example, if i have a pack that expects a LIST as a parameter (treated as an ARRAY within the pack) but the user supplies a LIST that has only one item, does the pack now get a single value which does not match the data-type of the parameter?
Or is this auto-conversion only done under certain circumstances where its known to be safe?
Above my pay grade, but I am uneasy about this. I tend to assume every line of code in a pack could fail, but my assumption about lists are that they are typed and therefore couldn’t assume a different type based on a condition of one item in the list.
Seems like a recipe for issues that would be difficult to debug.
Interesting. I am just now seeing a lot of changes recently in Coda where it’s showing me a list type where I was expecting to see just a value. So I just started using .first() when I expect my table to only have one item in it. I figure better safe than sorry.
What if some user finds my table that’s in a hidden page and decides to add another row to it?
Using first() (for this purpose) is not best practice. And just like in any other data environment, you have to setup your pages in such a way users can only add data to tables where they are supposed to do so.
You can hide the plus button, you can set lookups to not allow for ad hoc adding of new rows, you can use page locking to lock tables for anyone but authorized users, etc.
Yes, it is a bit of work, but it can be done without to much effort. In the beginning it requires a lot of testing to learn how to set it up properly, but I use it for our team and these are not (all) computer minded people.
Don’t use hidden pages to protect your tables, use hidden tables only to create a clean UI/page menu. Hidden pages are not meant for (data) security.
So I just started using .first() when I expect my table to only have one item in it. I figure better safe than sorry.
If you use first() for this, you will be sorry at some point.
Would you elaborate more on your statement that at some point I’d be sorry for adding .first() to the formulas?
I agree, hiding pages is insufficient and it is definitely not the only thing I have put in place. The issue is, the client has a doc maker account and nothing can be done to prevent them from using that account, unlocking the doc and figuring out how to add something to the table that I intend to only have one record. Therefore, as one extra layer of precaution I went ahead and added .first() to make sure that if someone did screw with that table, that it should never throw an error when it changes the intended comparison of 1 item = 1 item to 1 list of items = 1 item.
I figure it’s better to assume someone can screw something up if there is any way possible for them to do so and to make sure that whatever I build will have the greatest chance of continuing to work if they do.
There are many reasons to not rely on first() if you want to retrieve a specific record, the most obvious is that you will never be sure which row (record) will be the first one sometime in the future. Imagine someone adds a couple of rows, accidentally (or not accidentally) deletes your row and then adds a row identical to your row to make good: your row won’t be the first row anymore. If your table gets a filter, you might not even realize the row you are looking at isn’t the first row anymore.
There are workarounds to prevent some of this, like filtering the table based on who is looking at table, but these type of workarounds are vulnerable too, in particular if other people have the same rights as you.
Not any safe, but working just as well: if you only need one row, you can also work with named canvas formulas holding the defaults. This is not the same as table values, but for many defaults this works fine.
But really, get yourself a team license and use page locking in such a way that only you can unlock pages. You can have a pages with tables where nobody but yourself can edit important tables. Obviously you have to make sure that ALL pages are locked to some extent (at the least prohibit canvas editing) and don’t give your users canvas columns: otherwise they can add a view to your default table, undo filters and mess up your data.
I feel pretty confident that there will be better ways to secure data in the future, but I am not sure how soon that future will be upon us. So for now, you have to make do with what we have today.
In my case, all my columns in the table are formulas pulling in the current user() and then setting a bunch of things to reference for that user. I had them in canvas fields, but I was having some odd things going on with formulas not calculating properly on the canvas the same as they calculated in the rows. Coda Support was baffled by what was happening as well. Filters were failing because the formulas refused to calculate for every user. Yet putting those same formulas into columns on a table the table row/column value would equate to empty rather than throwing an error in some cases.
Neither Coda nor I had seen these errors that just started showing up within the last couple of weeks.
For my case, yes, they could add another row, but it should be the same as the current row unless they really dig in and start messing things up. So using .first() will always prevent an error in this case.
I do have doc locking turned on and all the other things mentioned. It’s just that when your client owns the doc and is the doc maker and the only one with control of turning on editing of the doc, you just have to trust that they won’t unlock things and start messing around. If they only use editor level user accounts to access the doc, they shouldn’t be able to mess it up.
It sounds like Coda might be planning some better doc security/locking features in the future. I will be excited to see what they come up with.