Xano Pack | Coda with no row limits

Showcase Tips and Hacks
21

Hey @Bill_French, to be honest, I’m a complete novice when it comes to Airtable.

But I’ve read your post and your solution is spot on. I recently worked on a smaller-scale, but similar solution in Coda. We had a table with thousands of rows that had a relation to another table with 5-12 rows linked to each of the rows in the primary table.

As the primary table grew, we had a growing concern with the related table exceeding a reasonable row count. To remedy, we had an automation “cache” the related table options into the primary table, then when the user expanded the primary table row with a button, we quickly reinserted that cached content into the related table so that the related subtable still worked in the expanded layout.

The related table had only a few columns, so I cached the row as a makeshift CSV, but flip man I should have thought of a JSON object. Named properties would have made the code a lot more readable.

This community is great - you can work in Coda every day and still find new ways of doing things here. Thanks for the post :slight_smile:

2 Likes
22

Because this is a big issue for many enterprise Airtable accounts. If there were a Xano “fix”, they’d all love to know about it.

2 Likes
23

hi @Jono_Bouwmeester and @Scott_Collier-Weir,

I’ve taken this for a test drive and have a few questions from least important to most important:

  1. Why do columns called image_list and users in Xano come across as called Image List and Users in the sync tables? I noticed this (very annoying) behaviour in Coda’s own Cross-doc pack so I wonder whether this is (a poor) design choice in packs as a whole ?

  2. Possible bug: A lot of my tables have a files column where my users can insert multiple files. I set up an a image list column on the Xano side (I need to pay to get the file column type, and I won’t pay until I know this is a workable solution). On the Coda side, it comes across as a Image Link column that’s empty. Worse, edits to this seemingly empty column actually wiped out the images I had stored on the Xano side.

  3. Unlike, say, Cross-doc sync tables. it seems that your pack is unable to detect relations. For instance: I have a clients and bills tables in Xano, with the bills table having a client column. When I sync both tables into a doc using your pack, the client column comes across as just the numeric client_id. Now I appreciate that’s how it’s actually stored under the hood, but I was sort of hoping that you’d be able to replicate what the Cross-doc pack can do in recognizing the link and setting the user column to be a lookup into the cients table.
    I never made packs (or written a single line of JS in my life - python all the way !), but a quick look at their docs, suggests this has to do with the defining the Identity of a table ? I am guessing you are unable to set this for dynamically generated table schemas ?

  4. Most importantly: How would a typical Coda CRUD workflow be replicated using this Pack? A most typical Coda setup for me is:

  • The top of a page is a a bunch of personal control for filtering

  • below is the a view of the expenses master table, filtered for based on the user’s “permissions” plus the additional filters they add from the top level controls → I am guessing the combined filters need to be “translated” into Xano’s filter string and fed as FILTER option to the sync table setting:
    image

  • Ok, a bit of a pain but should be doable with some patient CFL Jujitsu.

  • Then what ? Do I need to make the user hit a button to trigger a RefreshTable() every time they change the filter?

  • What happens when they need to insert or delete a row into the filetered view they see? does every call to your pack’s AddRow and DeleteRows() function need to be followed by a RefreshTable() call on all the potentially affected sync tables?

→ This seems like it will be a bit of UI bottleneck, as we’d be giving up the ‘reactive’ part of using native Coda tables. But maybe I’m too greedy, as it also sounds no different that the sub-par experience we are currently getting with Coda’s own Cross-doc pack, even with the much touted “two-way sync”.

  1. [edit, I discovered this issued after I posted] Fatal bug found: When a single column in a Xano sync table row is edited, the pack sends the entire row back to Xano, not just the modified columns, this effectively overrides any changes to the other columns of that row, that may have taken place in the meanwhile by other users in other docs, or in Xano itself.

I don’t want to sound like I’m hating on your work here and I can definitely see you’ve put a tremendous amount of effort into this. I am just trying to clearly define the limitations before I invest more of my time into this.

I am curious to know whether you genuinely see Coda as a viable front-end builder. Once we’ve gone through the pain of migrating data to a BaaS such as Xano, maybe the wise thing would be to go all the way and also migrate away from Coda to a dedicated no/low-code front-end builder? I use Coda first and foremost as an internal tool builder and I love it. But I sadly find myself seriously considering this migration, as I am tired of hitting the “Coda performance wall” and ever waiting for better permissions and granular sharing.

2 Likes
24

Hey @Nad :slight_smile: Sorry about the delay in replying to your questions - wanted to make sure I was thorough in my response. Replying to your questions with the same numbering you’ve used:

  1. In packs, you define columns as a JavaScript object, with column names as property names of that object. Much like SQL and XANO column names, you can’t have spaces in property names; but it’s expected to have spaces in column names in Coda. So Coda converts CamelCase or snake_case property names into Title case column names. I do agree it’s a little annoying in this particular pack’s case, but there’s nothing we can do about it unfortunately.

  2. The XANO API returns images as a URL and packs supports images as a reference (ie, Image URL column) or as an attachment (ie Image column). So it’s totally possible for us to change how images work in the sync table. That’ll mean multiple images will pull in correctly. I actually intended image columns to not be editable row properties. You’ve clearly picked up a bug there, sorry! I’ll push an update in the next day or two.

Why I thought it best to not allow image edits… When row edits sync in packs, the whole row is sent for updates (not just the particular cell you’ve edited) so I was worried that sending images through for every update would make that quite slow. You’d be sending the same images back to XANO every time even if you didn’t change them. Are image edits something you expect to need? I could look into seeing if there’s a decent solution.

  1. Let me look into that. I can’t find any documentation in the packs SDK, but let me shoot the team a message.

  2. We originally did try to pretty up the filtering UI but every iteration meant limiting functionality. My thinking was the likely target market for the pack would probably prefer power over ease of use. Definitely something I was hoping we could confirm with user feedback!

> Then what ? Do I need to make the user hit a button to trigger a RefreshTable() every time they change the filter?

That’d work. Just make sure you switch off the “Keep unsynced rows” option under Table Options.

> What happens when they need to insert or delete a row into the filetered view they see? does every call to your pack’s AddRow and DeleteRows() function need to be followed by a RefreshTable() call on all the potentially affected sync tables?

That’s correct - pack action formulas (IE the actions you’d run with a button press) don’t automatically cause sync tables to resync. To improve the UX here, I’d recomment you use RunActions() to automate a RefreshTable() after addition/deletion of rows.

  1. You’re right - if you’re expecting multiple people to concurrently edit rows across multiple docs or other systems, you could run into the issue of users overwriting other users’ updates. Coda sync tables don’t support “live updates” in that way. In practice, you’ll need to determine if this is something you can work around or if it voids the use case.

> I don’t want to sound like I’m hating on your work here and I can definitely see you’ve put a tremendous amount of effort into this. I am just trying to clearly define the limitations before I invest more of my time into this.

It’s all good, I’m not feeling hated on at all. You’ve given really helpful feedback.

> I am curious to know whether you genuinely see Coda as a viable front-end builder. Once we’ve gone through the pain of migrating data to a BaaS such as Xano, maybe the wise thing would be to go all the way and also migrate away from Coda to a dedicated no/low-code front-end builder? I use Coda first and foremost as an internal tool builder and I love it. But I sadly find myself seriously considering this migration, as I am tired of hitting the “Coda performance wall” and ever waiting for better permissions and granular sharing.

Yeah I really do. I come from web development background, and have like decades of experience building SQL databases, and nowadays Coda’s somehow become my primary driver for almost everything. I do definitely have to implement some tricky workarounds from time to time, but it’s almost never impossible to get the job done. If you’d like some input on your specific project, you’re welcome to reach out. I very much enjoy pushing the boundaries a bit :slight_smile:

1 Like
25

I’ve been working with Scott’s team to implement the Xano pack on two different projects, and so far it has been fantastic. As much as we love Coda, it does feel like we hit that doc size limit a little too quickly.

I have a Xano-related question that I’m posting here in case anyone else is interested in the functionality:

Would it be possible to use this pack to pull in Xano “test” data? (as opposed to “live” data?)

The pack has the optional Filter that uses Xano search functionality, but would it be possible to incorporate the “X-Data-Source” header that we can use in Xano API calls to interact with live/test data as needed?

Hoping that we could set up ‘live’ and ‘test’ Coda docs for trying out new things in the ‘test’ doc before implementing them in the ‘live’ one.

Thanks!

1 Like