Purpose

I would like to add support for UITableView within IGListKit. Ever since @rynstrom started formulating what would become IGListKit I thought it would be great if it worked with UITableView, but I didn't have the time to do that. Additionally, Instagram doesn't have many table views left so the impact would have been small. However, I still believe that there is meaningful value in supporting UITableView, and for Instagram it would be great to convert the remaining UITableViews over to this more sane framework.

This issue is to track the following:

• desired additions
• analysis of required changes to IGListKit

As this will likely be 100% source breaking changes, I'm guessing this will be included in at earliest the 4.0.0 release.

Expected Changes

Below are my (likely) naive expectation of changes that will happen:

IGListAdapter

• collectionView, collectionViewDelegate, and updater will no longer be direct properties on the object

IGListAdapter is relatively weakly coupled to UICollectionView. There are a number of collection view specific data source, delegate, and layout methods but none of them are critical to the adapter itself. I believe all of those could move out to an owned object that is specific to collection view without breaking the adapter.

IGListUpdatingDelegate

This protocol is also not 100% dependent on collection view but rather what a collection view can do for adding, deleting, and moving parts. Thankfully all of that is possible in UITableView also. Except for the completion block that is available with -[UICollectionView performBatchUpdates:completion:], but I feel confident that it will be possible to add that exact method via an extension to UITableView and effectively change this protocol into one that depends only on an object that implements some other specific protocol.

Add IGListUpdatePerformable Protocol

I'm good at naming. I based this on the Swift API Design Guideline

Protocols that describe a capability should be named using the suffixes able,ible, or ing

This protocol will be used by IGListUpdatingDelegate to encapsulate an object's ability to handle adds, deletes, moves, and reloads that IGListKit support. By abstracting this out it should be possible to allow objects that aren't even UIView subclasses be managed by IGListKit.

Add IGListEncapsulating Protocol

Names. This protocol would be for objects that actually own the object that is being managed by IGListKit and should implement any specific data source and delegate methods that should be intercepted/implemented. This object type would be what is owned by IGListAdapter and could become the actual collectionContext that is provided to IGListSectionController instances. That last part may get a bit weird, but maybe.

The overall goal is to make IGListAdapter independent of UICollectionView and provide some method for it to handle any kind of list-ing thing. The largest downside is that at some point a consumer is going to have to do type specific casts to go from a protocol to a specific list-ing type. Thus if there are implementations for UICollectionView and UITableView then at some point there will be a need to know which type is being used and then cast to that type. I don't know exactly where that is yet, but I'm sure it will shake out on its own and there will be great feedback.

Break UICollectionView Dependency in IGListSectionController

This one is potentially going to be difficult. The section controller needs the collection context and then has various delegate and data source objects that are specific to collection view functionality. The two that are most apparent are IGListSupplementaryViewSource and IGListDisplayDelegate. Both of these maybe could be easily converted but I'm not sure yet.