Provide clients with (optional) diffing notifications — split up IGListAdapterUpdaterDelegate into finer-grained delegates?

[jessesquires]

Internally, we've come across a case where we need to know the results of the diffing. (Specifically, we need to know what was re-ordered in a list.)

We could using the diffing components separately to figure this out, but that doesn't make sense since ListAdapter will be "re-doing" this work.

We could add a nullable id<IGListDiffingNotificationDelegate> (or something similar) that clients could set in order to get (optional) updates on the diffing results (i.e., to receive the IGListIndexSetResult from IGListDiffing()).

We'd add the hook here to pass the result to the delegate/listener.

[jessesquires]

cc @rnystrom - thoughts?

[rnystrom]

Could we use the IGListAdapterUpdaterDelegate for this?

https://github.com/Instagram/IGListKit/blob/master/Source/IGListAdapterUpdaterDelegate.h#L31-L39

https://github.com/Instagram/IGListKit/blob/master/Source/IGListAdapterUpdater.h#L32

Maybe we split apart the delegate, or make it one-to-many by importing the announcer stuff.

[jessesquires]

Ahh 👍 Looks like IGListBatchUpdateData contains everything we would need.

However, I agree that IGListAdapterUpdaterDelegate is way too large.

I see 5 distinct groups of notifications that clients might want to listen for independently:

• batchUpdateDelegate
• insertUpdateDelegate
• deleteUpdateDelegate
• reloadUpdateDelegate
• crashDelegate

---

Note: we could still keep IGListAdapterUpdaterDelegate, which would inherit from all of these and just be an empty protocol (so it's just to composition of all of the above) for clients who want to listen to everything with less boilerplate.

[jessesquires]

Maybe we could combine insert / delete if 5 is too much

[rnystrom]

Ya, its a bit much. We could def split it out. Right now we use this for custom exception handling to find bad diffs. I was thinking too that a UICollectionViewLayout object could conform to the updates and do custom invalidation or something. Maybe we keep the granular updates as one delegate, a begin/end delegate, then a crash delegate?

[jessesquires]

cc @lichen19853