New Table Change Cell Event issue

App Building
1

I am testing out the utility of the Change Cell in the hopes of creating a background save capability for the table. I have spotted a couple of issues.

  1. The event fires whenever you blur a cell that entered edit state - even if nothing was changed.
  2. There is no reference to item or currentSourceRow so I have to use a kludgy workaround: {{self.changesetObject[self.selectedRow.bug_id].title}}
2

Thank you for the feedback! These are both great points.

  1. This is a bug! I've filed this internally and we'll get it fixed in the next week or two.

  2. The way I've successfully set up background-save is to always flush the entire changeset when "Change Cell" is called, but I acknowledge that has other issues with concurrent saves. The lack of extra scope in the Event Handler is an intended short-term limitation as we decide what scope would be most valuable to include. We were hesitant to include currentRow and item because we weren't sure if / how they should include the changed value. I'd love to get your thoughts on what I'm currently thinking for extra scope:

currentSourceRow: Record<string, unknown>
// new property
event: { 
  newValue: unknown,
  oldValue: unknown,
  dataIndex: number,
  rowKey?: unknown 
}

We could bring the event variable to "Cell click" as well.

3

I was thinking the same thing but hadn't tried it yet, good to know I was on the right track. I was wondering how the save dialog would handle it.

Ok, I really like passing an event property, with every property available, to the event handler! I'd love event context available to all event handlers. That solves your conundrum I believe. I would still give access to the standard context however (for consistency) and have it show the pre-change values, just make clear in the docs. Would the context pass to the triggered query?

4

I almost have the background table saves working right, but it appears that the disable spinner option is not yet ported?

Btw, here is my code:

if (tblBugsNew.changesetArray.length > 0 ) { // only run if there actually is a change
  await qryBugsBulkUpdateNew_Background.trigger() // Update database
  await qryBugs_FilteredOnServer.trigger() // requery
  await tblBugsNew.clearChangeset() // Run last or else the old value may pop back in briefly.
}

That runs on the Change Cell event.

Would be really nice if I could just merge the changesetArray into data and not need to requery that database!

I realize that this may cause the local and server data to be out of sync, but in some situations that is manageable in other ways.

5

Glad you're a fan of event! I'm hopeful we can bring it to many more event types to provide more details about the event. The event context won't be automatically provided to the query (yet, at least). We're actively thinking about how to make those workflows easier, however.

On merging changesetArray into data you're right -- it would be easier in some cases. I'm not sure it's a good pattern to encourage, though. If we make the loading state for Table better (by not rendering a click-blocking overlay over the entire component) would that be sufficient?

6

Agreed! It should not be the common pattern, but it has a few good use cases I have encountered.

The visual and usabilty performance of the table is absolutely a factor, but also the table source may be a massive query (I have a few of those) and I just don't want to hit it any more than needed. I may want to reload the table occasionally when multi-user consistency is not important.

I have used some backhand ways of doing it, but that gets pretty spaghetti-ish.

7

fair enough -- i'll bring up adding a commitChangeset API with the team!

1 Like
8

@Alexi is rowKey in the proposed event the columnId for the changed cell ? If so, it may be read from the selectedCell already or is it the primary key (if set) ? Side-note: any plan to support multi-columns primary key ?

I am also building a simple background-save logic using a temp state variable as source of the table. That allows me to use setIn to set arbitrary values to any column on Change Cell event, with a "background-save query (actually bulk insert to BigQuery) that runs every 1min or so to insert new changes (full rows).

To @bradlymathews's point, what I lack too is finding out the index on the changed cell, i always return 0 and item is not exposed (interestingly, it is exposed on Change Cell of individual columns). The selectedCell.dataIndex is the closest thing to it, but it means table must have cell selection on. I then need to read changesetObject just to figure out the new value to set in the temp state. As soon as temp state changes, table refreshes and I see the updated value in the table (which I can edit further if this was a default value).

Most would be unnecessary boilerplate if we had the event properties as you suggested. Any chance this or a similar approach may be in for the end of May release ?

9

Hi @yiga2


It looks like the rowKey would correspond to the primary key. I don't believe we had plans for multi-column primary keys, but I went ahead and submitted a feature request. It'll get triaged internally & I'll post back here if it's something we're able to ship

This event project isn't something that we've been able to ship yet, but we're working on table apis over the next several months. Definitely keep an eye out on our changelog for updates, and I'll post here if we're able to ship the `commitChangeset` API specifically.