[Remove IGListCollectionView] Should IGListAdapter really depend on IGListCollectionView?

[ocrickard]

There are legitimate reasons to use a different UICollectionView, and virtually every large codebase that looks at incremental conversion will have to use IGListAdapter with an existing subclass of UICollectionView. I get the need to use this for people new to the framework, but we need a way to configure IGListKit to work with existing collection views. Would we reconsider the dependency?

[jessesquires]

This has come up before: #240.

I'm open to removing IGLK_SUBCLASSING_RESTRICTED. Would that be sufficient?

[jessesquires]

Actually, one other thought / data point here.

If users wanted to use IGListKit together with something like JSQMessages, this currently would not be possible since JSQ has it's own UICollectionView subclass. (Although, this will be removed from JSQ in the next major release.)

[ocrickard]

Yep, I saw that, but I'm not proposing allowing subclassing. I don't see why this can't be used with an arbitrary UICollectionView subclass, and I don't want to make subclassing the defined class in the framework the only way to use a custom collection view. There are numerous valid uses of subclasses.

Is there a good reason to keep the collection view in the interface of IGListAdapter? If people want to use IGListCollectionView, great.

[jessesquires]

@ocrickard 👍

Primary reason for the class is just to attempt to prevent access to UICollectionView APIs that are "invalid" under IGListKit.

The only real negative to removing this is that users will be able to misuse the framework more easily. But, that can be (partially) remedied with docs.

[rnystrom]

Talked w/ @ocrickard a bit about this today. I'm warming up to the idea.

I really don't want to lose the compiler safety of not calling update methods, but at the same time the pain is real for some folks. Hell even facebookarchive/AsyncDisplayKit#2848 had to hack around it.

I've also been brainstorming adding UITableView support down the road, so this would be a good first step.

And I agree if we're going to do this let's just drop IGListCollectionView altogether and use UICollectionView

[jessesquires]

One more thing, if you want to use UICollectionViewController (which is common), then IGListCollectionView prevents that. (unless you do that ASDK hack, which is gross)

[rnystrom]

@jessesquires oh nice, that's a great point!

[jessesquires]

@rnystrom - what's the decision here?

kill IGListCollectionView ?

[jessesquires]

Or -- we could keep IGListCollectionView and recommend it's use.

However, other APIs could change to UICollectionView.

This would also make it easier to make this change in IG

[rnystrom]

I think we should kill it. There are legit reasons to subclass UICollectionView (e.g. AsyncDisplayKit, iOS compatibility hacks, API extensions) and we're restricting others. The only downside is losing the compiler errors on mutating the collection view directly. Really wish there would be a way to enforce that w/out huge hacks...

[jessesquires]

imma do dis

[jessesquires]

landing internally now 🛬

[jessesquires]

Taking another stab at this today.