Coda API: `visibleOnly` param should be factored out into its prescription for rows and columns individually

Context:

The Coda API enables specifying a visibleOnly param when retrieving a Table’s rows, which is documented as: “If true, returns only visible rows and columns for the table.” (see Coda API (v1) Reference Documentation).

Problem:

The problem comes with this specific use case of attempting to retrieve the rows of a given table in their natural order, including the fields for any hidden (non-visible) columns. Although this seems like it should be possible (and the documentation does not mention any reason it shouldn’t be), it is not possible, as in order to retrieve the rows in their natural order, the visibleOnly param must be set to true:

This ordering is only meaningfully defined for rows that are visible (unfiltered). Because of this, using this sort order will imply visibleOnly=true, that is, to only return visible rows. If you pass sortBy=natural and visibleOnly=false explicitly, this will result in a Bad Request error as this condition cannot be satisfied.

The restriction that only the visible rows may be returned makes sense, but the restriction on the visible columns does not. This artificially restricts the functionality of this endpoint, and there is no real way to emulate this functionality as a consumer of the API. The root cause of this is that the visibleOnly param serves two uses in this context. The solution would be to factor them out into visibleRowsOnly and visibleColumnsOnly params.

1 Like

Hi Louca! Though confusing, I think the intention here for this use case is to pass sortBy=natural but omit visibleOnly entirely. The warning you’re seeing is for the case where a user explicitly passes visibleOnly=false, this request is rejected because that option is incompatible with natural ordering and we’d rather error to let the user know about the issue rather than to ignore one or the other parameter silently. Can you try omitting visibleOnly entirely and seeing if you get back the right set of columns?

I agree it’s confusing to have an omitted parameter be a distinct state that’s different than true or false. Maybe it would be less confusing if visibleOnly had a third option which was something like infer or default, and that that was the behavior if the parameter was omitted.

1 Like

Hmm that explains things a bit more. I’ll give that a try and see if it works.

And yep definitely agree that the three-state boolean param is a bit confusing :slight_smile:

1 Like