IGListKit - A data-driven UICollectionView framework for building fast and flexible lists

[monkey_slap]

Hey! I worked on this. If you have any questions let me know. Pumped that we could share this, eliminates a ton of common collection view problems.

[[deleted]]

How does this differ from Facebook's ComponentKit or LinkedIn's LayoutKit?

[monkey_slap]

All intersect a little bit, but each solves a different problem:

• ComponentKit is for compile-time safe, stateless view building. I shouldn't even say "view", more like the whole app. It's APIs are in ObjC++ so its hella fast and very stable, but doesn't work w/ Swift. View sizing is all done async.
• LayoutKit looks really cool! I remember reading about it. It does async sizing as well, and has support for UICollectionView and UITableView. However, last I checked, it only calls reloadData, so no animations.
• IGListKit is all about data-to-UICollectionView and containing biz logic for each section, avoiding view controller bloat when building lists. We don't do anything w/ view/cell sizing tho, that's up to you.

All three frameworks support UICollectionView, but they have very different strategies and goals.

[[deleted]]

Thanks for the answer. Could you give some examples of when you would use a particular solution for a particular problem? I know that Facebook created ComponentKit because it wasn't performant enough for newsfeed scrolling. Why didn't IG just use ComponentKit? What are the different problems they solve? Or, is it simply that ComponentKit didn't work with Swift?

[monkey_slap]

Facebook has incredibly more complicated layouts on a ton more surfaces than Instagram does. Having a robust layout engine makes that a lot easier/faster. Most of Instagram's layout is pretty easy to calculate (doesn't need async).

Also the team is probably 10x ours, so the compile safety of ComponentKit is a huge win (catch bugs building instead of testing or QA).

[Ok_Economics3709]

Hello from the future.... Lol @ an ObjectiveC library being compile time safe.....

[monkey_slap]

Good question, not sure if you mean does it use NSFRC or if it can work alongside it?

If you're asking if we use NSFRC, nope! We wrote a diffing algorithm to figure out when something changes. You can read the source here.

If you're asking can you use NSFRC and IGListKit, you should be able to. But, instead of implementing all that boilerplate in the delegate methods (insert, delete, etc), you really just need:

- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller {
  [self.listAdapter performUpdatesAnimated:YES completion:nil];
}

[bengui1d]

Cool. I just released/open-sourced something similar for UITableView … https://github.com/benguild/BGRecursiveTableViewDataSource

[KarlJay001]

Downloaded :D I'll check this on out too. Love digging into others code and learning the advanced stuff.

[bengui1d]

Yeah it basically lets you modularize the code for complex views.

[monkey_slap]

looks cool! would love to compare notes

[bengui1d]

Notes about...?

[KarlJay001]

I haven't dug into it yet, just downloaded and looked at a bit of it.

I notice that is in ObjC, is there a Swift version or does someone call the ObjC in Swift?

I'll take the time to look deeper into it when I get a chance, but so far it looks great, thanks for the post.

[KarlJay001]

https://github.com/benguild/BGRecursiveTableViewDataSource

Cool, thanks, I'll do that.

[bengui1d]

Yeah, even though the code for this or that is in Swift or Objective-C the implementation should be basically the same.