2

I have a Lightning Web Component that is feature-rich, so to say. 250 lines of HTML and 1350 lines of JS. Due to these sizes, I cannot list the complete source.

One of the things that it uses is this lightning-datatable:

<lightning-datatable
  key-field="Id"
  data={theSearchResults}
  columns={searchResultColumns}
  draft-values={draftValues}
  oncellchange={handleChangedQuantity}
  onrowaction={handleSearchResultRowAction}
  hide-checkbox-column="true"
  column-widths-mode="auto"
  min-column-width="10px"
  suppress-bottom-bar="true">
</lightning-datatable>

The definition of theSearchResults:

get theSearchResults() {
  console.log(JSON.stringify(this.searchResults, null, 4));
  return this.searchResults;
}

The cells in a number of columns in the datatable are editable. Whenever such a cell is changed, this function is called:

handleChangedQuantity(event) {
  // Store the entered data in the searchResults object.
  if (event && event.detail && event.detail.draftValues) {
    event.detail.draftValues.forEach(changeObject => {
      // Id looks like 'row-nnn'
      const index = changeObject.Id.slice(4);
      for (let key in changeObject) {
        if (key != 'Id') {
          this.searchResults[index][key] = changeObject[key];
          if (DEPOTS_IN_PROPER_ORDER.includes(key)) {
            this.searchResults[index][this.cssClassLabels[key]] = 'slds-is-edited';
          }
        }
      }
    });
  }
}

One of the effects is that the edited cells look different from the other cells.

The user can enter search criteria somewhere in the LWC and the datatable gets refreshed (call to Apex). Up until Summer'24 this has worked perfectly (for at least 4 years).

What we observe now: whenever a user has edited a cell (say on row 3), the LWC remembers this. Everywhere in the JS code, both searchResults and draftValues are reset, but to no avail: the LWC knows that the cell on row 3 has been edited, it knows its previous value and it will present it in all subsequent actions.

The console.log statement in theSearchResults shows us that the cells contain exactly the values that they should have, but the browser shows the values that have been used in previous edit actions.

The LWC also has a button that takes the values of the database (including changes) and processes them. Provided the user did not edit anything since the last search action, a console.log shows that searchResults is still the same as it was when last retrieved by theSearchResults. So, the browser really has a different idea about what it should present, compared to the actual data.

I have been banging my head against various walls for a day now and to me, it is starting to look like Summer'24 has introduced some kind of caching.

It is not a browser issue, I have tried it in Chrome, Firefox and Edge. Also: it only happens in Summer'24 sandboxes, in the Spring'24 production org - using the same browsers (versions) - this does not happen.

It's a long shot and I know my HTML and JS are not simple, but maybe someone has also seen this behavior?

Update: upon re-reading the documentation on lightning-datatable, it struck me that I don't need the draft-values tag. Omitting it, however, does not solve the issue.

2 Answers 2

1

draftValues isn't used directly, but instead a copy is made. Looking at the npm lightning-base-components, you'll find this code:

@api
get draftValues() {
    return getDirtyValues(this.state);
}

set draftValues(value) {
    const { state } = this;
    this._draftValues = value;
    setDirtyValues(state, value);

    if (this.isConnected && this.hasValidKeyField) {
        this.updateRowsAndCells();
    }

    updateActiveCellTabIndexAfterSync(state);
}

My educated guess is that, in the Summer '24 release, they added some logic that ignores null, leaving the previous dirty state intact.

Bug? Feature? Not sure. That said, I've always explicitly initialized to an empty array when using draftValues.

0

After a day and a half of googling and trial-and-error, I finally figured it out. In my opinion, we are in the vague bug/feature zone.

The draft-values tag, and its accompanying JS variable, is not well documented, on this site alone you will find other people having problems with it.

In my original code, I had included the tag as well as its accompanying JS variable, but it doesn't seem to be used anywhere. In fact, omitting them did not seem to matter at all. But it seems that Summer'24 has changed that.

Since my problem is related to draft values, viz. old draft values being presented where they shouldn't be, I tried this in my JS code:

this.draftValues = null;

But this did not solve anything: old draft values still show up in places where they shouldn't.

Another draft-values related post on this site suggested this:

this.draftValues = [];

And that solves the problem! This does not make sense to me. How can I still see old draft values if it was reset to null? It looks like that assignment is being ignored, while the assignment of [] is executed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .