Update specific column of specific row (+ general API usage discussion)

Developers Central
1

Working with the coda-js wrapper for the API.

I want to update a specific cell, and I know the docId, tableId, rowId, and columnId in question. The examples I’ve found seem to require getting the whole row’s cells, and then writing them back again via the API with any changes included. Is this necessary, or can I just specify a new value for a single cell? Something like:

coda.updateRow( docId, tableId, rowId, {columnId: value} );

Edit: Had a different error that was causing the above not to work. In fact, it it precisely the correct way to do it :slight_smile: Will leave here in case helpful for others.

Further edit: if you prefer, you can also go do an array of objects like this:

coda.updateRow( docId, tableId, rowId, [
      {column: 'id or name', value: 'value'},
      {column: 'another id', value: 'another value'}
]);
2

Hey @Nick_HE can you share how you’re using the coda-js wrapper? I’m trying to learn ways to extend Coda. Thanks

3

I mostly use the API to either:

  • Format data from Coda in a pretty (or very specific) way, for printing to PDF
  • Use Coda as an admin interface, and then provide access to a slice of Coda data to someone that I don’t want to invite into the whole doc (e.g. Coda doc for booking staff; staff can see just their own info via API)

In terms of my stack:

  • I’m running coda-js in Firebase Cloud Functions (if you’re not familiar - cloud functions are a trendy way to handle server-side code; instead of a full backend app running on a machine somewhere, you just have individual functions that are encapsulated as their own little micro-apps. Lots of modern hosts let you do this, and Google’s Firebase is one of them)
  • Usually I’ll make a little Vue.js app as the front-end, that interacts with the cloud functions
  • If it’s something very simple, I’ll skip the front-end app entirely and serve some basic HTML directly from the cloud function

Caveats:

  • While you can kiiiiinda use Coda as the backend database for a site/app, it’s really not built for that!
  • It’s not super fast (e.g. a round-trip from my Vue app asking Firebase cloud functions to pull 4 rows from Coda in one request is clocking around 5 seconds)
  • There is a significant delay (15-20sec) between when data is updated in the Coda doc, and when it’s updated in the API’s view of things. So if you update a cell in your doc, and then get it via the API 10 seconds later, it will still show the old value.

Let me know if you have any questions. What kind of stuff are you looking to do?

4 Likes
4

@Nick_HE Thanks for sharing how you are using the API.

I’m building out a CRM in Coda. I built a simple GMail add-on that grabs all the recipients (to, cc and bcc) in the email they’re looking at. When they choose a particular recipient I go to Coda to get the information we currently have. If I don’t find them the user gets a card where they can specify they type of relationship they want to capture for this person. On save I insert the row into the base table in Coda via the API. It’s been my experience that this insert can take up to a minute , or longer, to show up again in the add-on which can be fairly frustrating for the user and, it appears there’s no real way around this, at least the way I’m doing it.

I cache the Coda response so I can check the mutation status for the row that was inserted or updated so at least I can give the user an indication about what’s going on.

I was looking to see if there was a different Coda doc structure that would be quicker to update (I currently have one doc) but inserts and changes generally show up in Coda within 10 seconds (typically much less) so I’m not sure if the effort will be worth it.

I’m still on a learning curve with how best to utilize Coda’s strengths and having someone else validate my experiences is valuable so thanks for that.

5

@Robin_Thompson that sounds like a great use case! It lets you custom-build the gmail bits without having to implement an entire CRM front-end. All the fancy stuff like slicing and dicing customer database, automations like followup reminders etc, can all be handled in Coda.

I’ve taken the same approach as you have with respect to client-side caching I think, updating client-side state as if the row had been added in Coda. In theory it’s kind of dangerous. I used to use Meteor.js, which has some really snazzy automatic “optimistic UI” (i.e. as soon as you take an action, it shows the result of success, even before it hits the server). Made interfaces feel really snappy, and then the UI could just change back into an “oh actually, failure!” state if the backend request ended up failing. In this case you have to wait quite a long time before certain failure states manifest themselves (1 min!) which is where I see the danger coming in. That said, I think (I hope?) the vast majority of the failure states would be flagged by Coda’s response to your write. But the way I read the docs, they don’t totally guarantee that a write that gets accepted into the queue will always makes its way to the table.

Have you run into any other challenges beyond the time lag?

One slightly annoying thing is I’ve been hard-coding columnIDs (didn’t want the brittleness of relying on column names, as I often tweak them for the Coda users’ benefit), but at least that’s a set-it-up-once kind of thing.

And I’ve heard there is (was?) a doc size limit after which API access stops being a thing, but have never hit it.