Closed rnystrom closed 7 years ago
I think we need a system in place to pluck objects with duped diffIdentifier
s. There should be asserting when this happens locally.
Recovering from this state is a little trickier because we want to dedupe our objects quickly before entering the diff (I think?). We only have to do this to the toObjects
before diffing. Something like:
NSMutableSet *identifiers = [NSMutableSet new];
NSMutableArray *deduped = [NSMutableArray new];
for (id<IGListDiffable> obj in toObjects) {
if (![identifiers containsObject:[obj diffIdentifier]]) {
[deduped addObject: obj];
[identifiers addObject:[obj diffIdentifier]];
}
}
// then diff w/ array deduped
This adds another O(n)
step before diffing, but should be pretty cheap.
But isn't diffIdentifier
required to be unique across objects?
Seems like this scenario has invalid pre-conditions...
@jessesquires theoretically yes, but the implementation doesn't enforce it. I think it probably should.
Note though that I think the diffing algorithm should still support duped identifiers.
This is a really weird case that I haven't spent a ton of time thinking about a fix. Without trying to explain too much, let me just paste a failing unit test added to the e2e tests.
This throws within
-[UICollectionView performBatchUpdates:completion:]
:This makes sense because the update that is applied looks like:
Deleting sections 1 and 2 are correct. So are the inserts to 1, 2, 3, and 5. However a duplicate entry for object with key
@4
is inserted. The infra has another insert at section 6, but skips section 4.