rowEdit cancel not working as expected with row validation

[ddaribo]

Description

When the rowEdit event is canceled, the row's new data is cleared, however the cells' edit values remain. This is not related to the validation feature and is visible in the "Event cancelation" demo in the docs:

In a grid validation scenario, it is expected that canceling the rowEdit event prevents the user from adding/editing an invalid row.
However, due to the above behavior, the grid accepts an invalid row.

To an extent related to #12127.

• igniteui-angular version: latest (& any)
• browser: any

Steps to reproduce

1. Open this sample
2. Observe that the ProductName and CategoryName fields are required
3. Click the "Add" button on the action strip to add a new row
4. Type something only in the ProductName field
5. Click Done in attempt to finalize the row edit while the CategoryName field is left empty
6. You will see the error message and the ProductName cell's value reset. (At this point, if you double click on ProductName you will see its edit value remains as before clicking Done)
7. Fill a value in CategoryName
8. Click Done

Result

The row is added, however, with an invalid state, event though the rowEdit event is canceled with the intention not to add/edit an invalid row:

public rowEdit(args: IGridEditEventArgs) {
    if (!args.valid) {
      args.cancel = true;
    }
  }

Expected result

Reset the cell edit values to the cells' previous values when row editing is canceled?
Properly recalculate the row's validity state.

Attachments

[github-actions]

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

[mmart1n]

Also, when the cell editing is canceled via Escape, the cell.editValue is not reverted to the cell.value.

[mddragnev]

@ddaribo It was discussed that even normal (without validation) rowEdit cancelation should not clear any values you entered during cell updating because it is not like canceling the rowEdit with escape or cancel button. So in the mentioned PR I changed that and made it consistent between row adding and row editing. Therefore with this change the issue should be fixed.
Also, I have fixed the additional issue that @mmart1n mentioned above.