Fixed a diffing key issue inside DiffableTableCellViewModelProxy.
Changed from static to instance because it was giving all off screen models the same diffing key.
There is a scenario where some models that are off screen, are about to come on screen, and when they all share a diffing key they get mixed up and the StagedChangeset ends up with some unnecessary information.
This was ok on Xcode 12, the DifferenceKit reload, which does a performBatchUpdate, sets the new table data, and modifies the rows, handled the extra info.
On upgrading to Xcode 13 the extra information in the StagedChangeset caused the performBatchUpdates to associate some cells with the wrong model.
In PlanGrid, on Xcode 13, the wrong cells associated with wrong models could cause a crash. On Xcode 12, the crash part did not happen, but you could see an incorrect animation when new cells were presented on screen. Sometimes, one or more of the new cells would appear to come from somewhere else in the table, even though it was a unique new cell that did not share a reuse identifier with anything else in the table. This was because the extra information in the change set placed the new cell in a wrong position due to it having a common diffing key, then moving it to the right spot.
Fixed a diffing key issue inside DiffableTableCellViewModelProxy.
Changed from static to instance because it was giving all off screen models the same diffing key. There is a scenario where some models that are off screen, are about to come on screen, and when they all share a diffing key they get mixed up and the StagedChangeset ends up with some unnecessary information. This was ok on Xcode 12, the DifferenceKit reload, which does a performBatchUpdate, sets the new table data, and modifies the rows, handled the extra info. On upgrading to Xcode 13 the extra information in the StagedChangeset caused the performBatchUpdates to associate some cells with the wrong model.
In PlanGrid, on Xcode 13, the wrong cells associated with wrong models could cause a crash. On Xcode 12, the crash part did not happen, but you could see an incorrect animation when new cells were presented on screen. Sometimes, one or more of the new cells would appear to come from somewhere else in the table, even though it was a unique new cell that did not share a reuse identifier with anything else in the table. This was because the extra information in the change set placed the new cell in a wrong position due to it having a common diffing key, then moving it to the right spot.