-
Notifications
You must be signed in to change notification settings - Fork 2.5k
columnDef.cellClass() executes on an old version of the row model #2377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This should work - the afterCellEdit also calls notifyDataChange, which in turn triggers the cellClass update. Two thoughts:
|
I dug into this a little more, and set a few break points. cellClass gets called before afterCellEdit, but not after. I tried calling notifyDataChange(grid, ALL), with no improvement. (grid refresh was logged to the console). I still need to try the latest changes. Thanks for the quick response! |
I am experiencing a similar problem, whereby updating grid.options.data and then calling notifyDataChange(uiGridConstants.dataChange.ALL) didn't change the underlying row.entity in calls to cellClass despite in the same function cellClass I can definitely see grid.options.data updated already |
The grid doesn't ever take a copy of the entity, it just has a pointer to it, so in theory this shouldn't happen. I've seen issues like this before and they turned out to be where some data was provided to the grid, and the grid rendered it into rows. The data was then subsequently changed (new objects in the array), but the grid associated with the pre-existing rows because the $$hashKey was the same. So now we have a grid with some rows that have one version of the entities, and some data that has a different version of the entities. Is there a way we can check whether this situation applies here? Ideally the grid would notice this had happened and change it's pointer to the entity, perhaps this is an extension we need in the data watcher? |
In our case the problem was a result of implementing rowIdentity or getRowIdentity (the docs didn't describe much why the 2, but it looks like one calls in the other). Although we return a unique id for each row the grid didn't refresh until we removed one of them (I can't remember which one was the real culprit I think it was rowIdentity) I didn't dig any deeper into it. |
Sounds like you have a workaround so I'm moving this to the 3.1 release. It's possible (though it shouldn't be) that the grid has orphaned rows where the entity no longer exists in your data set, perhaps because the grid BELIEVES the entity still exists based on how your row identities are defined. If I can reproduce I will try to fix it. |
In gridApi.edit.on.afterCellEdit(), I update a row property used by columnDef.cellClass(). This is used for visually displaying validation. When cellClass() executes, it is operating on an old version of the row object. $scope.apply() does not seem to execute columnDef.cellClass() again. It would be wonderful if there was a way to trigger columnDef.cellClass() for a cell, row, or the entire grid.
Reproduction Steps: Edit a cell, click away, the cell class is not applied because the row object has not been updated when columnDef.cellClass() runs.
The text was updated successfully, but these errors were encountered: