igx-grid - beginAddRowByIndex - supply default values

[mikerentmeister]

Question

I am currently using the beginAddRowByIndex function with batchEdit, and want to be able to supply an object that contains default values for some of the columns. Looking through the grid base component, as well as the crud service, I didn't see any great way of doing it. Instead I tried listening to the rowEditEnter EventEmitter, and updated the e.rowData object to my liking. I then called e.owner.detectChanges(). This updated the new row to contain my default values, however, when the row was committed, it didn't contain my default values.

I tried the following three options in rowEditEnter, but none of them worked to persist the values to the row when the row was committed:

e.rowData.property1 = 'blah'; // This updated the new row to contain my default values, however, when the row was committed, it didn't contain 'blah' in the property1 column.
e.newValue = Object.assign({}, e.rowData, { property1: 'blah' }); // Didn't work at all
e.rowData= Object.assign({}, e.rowData, { property1: 'blah' }); // Didn't work at all

Is there a different way that I can provide these default values for the user, and have them persist (unless changed by the user) when the row is committed? In my opinion, devs should be able to modify rowData in both the rowEditEnter and cellEdit events, and have them persisted to the final transaction, but this isn't the case when using beginAddRowByIndex.

I also reviewed this support ticket from a while back, because I will need to set multiple column values when a column changes, but the provided solution doesn't work for rows that are added via beginAddRowByIndex. How can the solution in the support ticket be modified to work for new rows as well?

• igniteui-angular version: 13.0.1
• browser:

[mikerentmeister]

Since my grid was batchEdit mode, I was having a lot of issues with the answers on forums heretofore given. Through trial and error I was finally able to supply default values, and have them persist when the new row is committed, by doing the following:

public onRowEditEnter(e: IGridEditEventArgs): void {
  // check to see if we have already set the dataType default value
  if (e.isAddRow && !e.rowData.dataType) {
    e.rowData.dataType = PropertyDataType.Text;
    const transaction: any = {
      id: e.rowID,
      type: 'update',
      newValue: { dataType: PropertyDataType.Text }
    };
    e.owner.transactions.add(transaction, e.rowData);

    // these next two lines were required for some reason unknown to me. Didn't want to dig anymore
    e.owner.crudService.updateRowEditData(e.owner.crudService.row, e.rowData);
    e.owner.cdr.detectChanges();
  }
}

It's not the prettiest solution by any means. If anyone has a better solution, please let me know.

As for the requirement to set multiple column values when a column changes, I was able to achieve it using the following:

public onCellEditDone(e: IGridEditEventArgs): void {
  // Make the description match the entityId if the description is empty, or equals the old entityId
  if (e.column.field === 'entityId' && (e.oldValue === e.rowData.description || !e.rowData.description)) {
    const transaction: any = {
      id: e.rowID,
      type: 'update',
      newValue: { description: e.newValue } // Other properties can be added here as well
    };
    e.owner.transactions.add(transaction, e.rowData);

    // these next two lines were required for some reason unknown to me. Didn't want to dig anymore
    e.rowData.description = e.newValue;
    e.owner.crudService.updateRowEditData(e.owner.crudService.row, e.rowData);
    e.owner.cdr.detectChanges();
  }
}

[rkaraivanov]

@mikerentmeister I agree this is not as straightforward as it should be. Users of the grid should not dig into internal APIs to accomplish a what otherwise should be a simple scenario. I'm transforming this into a feature request and add it to our backlog.

[github-actions[bot]]

There has been no recent activity and this issue has been marked inactive.

[github-actions[bot]]

There has been no recent activity and this issue has been marked inactive.