instagram/iglistkit

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

---

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

	Main Features
🙅	Never call performBatchUpdates(_:, completion:) or reloadData() again
🏠	Better architecture with reusable cells and components
🔠	Create collections with multiple data types
🔑	Decoupled diffing algorithm
✅	Fully unit tested
🔍	Customize your diffing behavior for your models
📱	Simply UICollectionView at its core
🚀	Extendable API
🐦	Written in Objective-C with full Swift interop support

IGListKit is built and maintained with ❤️ by Instagram engineering. We use the open source version main branch in the Instagram app.

Multilingual translation

Chinese README

Requirements

• Xcode 11.0+
• iOS 11.0+
• tvOS 11.0+
• macOS 10.13+ (diffing algorithm components only)
• Interoperability with Swift 3.0+

Installation

CocoaPods

The preferred installation method is with CocoaPods. Add the following to your Podfile:

pod 'IGListKit', '~> 4.0.0'

Carthage

For Carthage, add the following to your Cartfile:

github "Instagram/IGListKit" ~> 4.0.0

Swift Package Manager

For Swift Package Manager:

To integrate using Xcode:

File -> Swift Packages -> Add Package Dependency

Enter package URL: https://github.com/Instagram/IGListKit, and select the latest release.

For advanced usage, see our Installation Guide.

Getting Started

Try out IGListKit by opening any of the sample apps available in the Examples directory.

• Our Getting Started guide
• Ray Wenderlich's IGListKit Tutorial: Better UICollectionViews
• Our example projects
• Ryan Nystrom's talk at try! Swift NYC(Note: this talk was for an earlier version. Some APIs have changed.)
• Migrating an UITableView to IGListCollectionView, by Rodrigo Cavalcante
• Keeping data fresh in Buffer for iOS with AsyncDisplayKit, IGListKit & Pusher, Andy Yates, Buffer

Documentation

You can find the docs here. Documentation is generated with jazzy and hosted on GitHub-Pages.

To regenerate docs, run ./scripts/build_docs.sh from the root directory in the repo.

Vision

For the long-term goals and "vision" of IGListKit, please read our Vision doc.

Contributing

Please see the CONTRIBUTING file for how to help. At Instagram, we sync the open source version of IGListKit daily, so we're always testing the latest changes. But that requires all changes be thoroughly tested and follow our style guide.

We have a set of starter tasks that are great for beginners to jump in on and start contributing.

License

IGListKit is MIT-licensed.

The files in the /Examples/ directory are licensed under a separate license as specified in each file. Documentation is licensed CC-BY-4.0.

Legal

Copyright © Meta Platforms, Inc • Terms of Use • Privacy Policy

iglistkit's Issues

Disable Wiki

Similar to xcpretty/xcode-install#118, according to @jhersh, all internet tubes are clogged 👍

Optional protocol conformance

Issue

Where possible, protocols should allow for optional conformance to avoid having empty implementations.

This is seen in the example app as:

func listAdapter(_ listAdapter: IGListAdapter, willDisplay sectionController: IGListSectionController) {}
func listAdapter(_ listAdapter: IGListAdapter, willDisplay sectionController: IGListSectionController, cell: UICollectionViewCell, at index: Int) {}
func listAdapter(_ listAdapter: IGListAdapter, didEndDisplaying sectionController: IGListSectionController) {}
func listAdapter(_ listAdapter: IGListAdapter, didEndDisplaying sectionController: IGListSectionController, cell: UICollectionViewCell, at index: Int) {}

or

func didSelectItem(at index: Int) {}

Seems this is partially complicated by ObjC to Swift bridging that creates ambiguous method / argument namings.

New issue checklist

• I have reviewed the README and documentation
• I have searched existing issues and this is not a duplicate

General information

• Library version(s): 1.0.0
• iOS version(s):
• Devices/Simulators affected:
• Reproducible in the demo project? (Yes/No): Yes
• Related issues:

Add a CHANGELOG.md

Should add a CHANGELOG.md. Generally considered good practice.

Entry for 1.0 can just say "initial release". Then, for PRs, we can ask that contributors include an update to the changelog. 👍 (Then writing release notes is easy.)

---

Example:
https://github.com/Alamofire/Alamofire/blob/master/CHANGELOG.md

Provide IGListCollectionSectionController [inception]

Create a stock horizontal or vertical scrolling item controller. This is a pretty loaded RFC b/c the API would have to be really thought out. Some questions come to mind:

Subclassing?

Since the infra requires subclassing IGListItemController and conforming to IGListItemType, if we provide a new item controller for this it would have to follow the same pattern as the stacked or single item controller:

@interface IGListCollectionItemController : IGListItemController <IGListItemType>
@end

Question is: do we have clients subclass this object or do we stick SUBCLASSING_RESTRICTED on it and provide some hooks?

Another idea is that we don't conform to IGListItemType but add hooks to properly setup/configure/reload the embedded item controller.

UICollectionView config

• Should we have an enum for h/v scrolling?
• What layout object would we use?
  • Maybe we keep the stock version of this to using UICollectionViewFlowLayout

I'm sure there will be more questions that come up. Open to suggestions.

RFC: Support NSCollectionView

Suggestion from an attendee of iOSDevUK where we announced the project. Wanted to record it.

I've never done any macOS work before, so I'm not sure how difficult this would be. But I know that NSCollectionView was modernized recently to mimic UICollectionView.

Open for discussion.

Make diff code available as a separate component

It would be useful to have just the diff algorithm implementation and related protocol used in IGListKit available as a separate component to be used for other purposes (i.e. table views, existing apps that don't want to migrate to IGListKit but want the diffing).

Remove -didDeselectItemAtIndex: API

Unused internally, and I haven't seen a solid use-case for it yet. We've discussed moving all interaction APIs to an interactionDelegate (similar to displayDelegate) on IGListItemController to make the base class boilerplate even simpler.

Add a method on diff results that is "safe for batch updates"

New method should:

• Convert reloads+moves to insert+deletes
• Convert reloads to insert+deletes
  • This is proven to not be safe for performBatchUpdates:completion:

RFC: Stock cell with UITableViewCell styles

Building custom cells isn't a lot of work, but since we don't support UITableView I wonder if it's worth adding an IGListTableCell or something that supports all (most?) of the default cell styles.

UITableViewCell style docs

Sections with different flow layouts

I hope it is ok to ask this here. Otherwise, please feel free to delete this issue.

I'm playing with the examples and am wondering what's the best way to create a collection view with sections that scroll in different directions. So for example let's say there are two sections, the first has items that scroll horizontally, but it also scrolls vertically along with the second section.

So far I've been achieving this by putting a collection view in a table view cell.

Along these lines, let's say in addition to that, that we want the first 'horizontal' section to be fixed, meaning that it won't scroll along with the second section. Should we just use two different collection views for those sections in this case?

Add Changelog

Mostly for documentation purposes. See @jessesquires examples:

https://github.com/jessesquires/JSQMessagesViewController/releases/tag/7.3.0

Changes are also picked up on Cocoapods

https://cocoapods.org/pods/JSQMessagesViewController#changelog

Add Carthage support

Probably worth adding this (mentioned in #9). Shouldn't be too difficult and we can keep an eye on it via Travis.

Convert reloadIndexPath when inside batch updates to delete+insert

Calling reloadSections: and reloadIndexPaths: on a UICollectionView while executing the update block in -[UICollectionView performBatchUpdates:completion:] is proven to be dangerous. Instead, we should always delete+insert. We converted this for sections already, but its still around for index paths.

• Remove the reloadIndexPaths mutable container from IGListAdapterUpdater
• Add index paths to deleteIndexPaths and insertIndexPaths when batch updating in progress
• Remove reloadIndexPaths from IGListBatchUpdateData

Rename IGListItemController to IGListSectionController

I've already caused a little confusion on how the infra maps to UICollectionView, so let's do away with calling these "item controllers" and instead call them "section controllers" so that it is more inline w/ how it works.

IGListKitCrashes when used in an iMessages Extension

New issue checklist

• [ x] I have reviewed the README and documentation
• [x ] I have searched existing issues and this is not a duplicate

General information

• Library version(s):1.0.0
• XCode:8.0
• iOS version(s):10.0.x
• Devices/Simulators affected:iPhone 7Plus
• Reproducible in the demo project? (Yes/No):Yes

Running iMessage Apps which have IGListKit included via CocoaPods results in the app crashing on launch with the error like the following: dyld: Library not loaded: @rpath/IGListKit.framework/IGListKit
Referenced from: /Users/demo/Library/Developer/CoreSimulator/Devices/5C343568-A532-405F-8B65-52A049827328/data/Containers/Bundle/Application/AA18B7D3-48C4-4958-A14C-C056A309D6D8/IGListStickerDemo.app/PlugIns/MessagesExtension.appex/MessagesExtension
Reason: image not found

Check out https://github.com/ishabazz/IGListKitMessagesExtensionDemo for a sample project that exhibits this error.

Diffing challenge: Swift vs Objective-C++

I'm proposing this mostly for fun/learning. We spent a lot of time optimizing our diffing algorithm in Objective-C++ (e.g. custom unordered_map, tables, structs). It's blazing fast, but I'm really curious how it would perform in Swift.

Parameters:

• Test with and without @objc protocol IGListDiffable { ... }
  • A big bottleneck in the diffing algorithm is objc_msgSend(...) for diffIdentifier and isEqual:
  • Should test a Swift implementation with and without the Objective-C messages
• The same input and output
  • Can omit experiments
• Compile for production
  • -Os for Objective-C
  • ??? for Swift

My hunch is that the current implementation will be faster, but I'd love to be proven wrong!

"deque" spelling error, should be "dequeue"

dequeReusableCell... should be dequeueReusableCell...

e.g. https://developer.apple.com/reference/uikit/uicollectionview/1618063-dequeuereusablecell

Add a README and legal docs

Need some "getting started" documentation as well as license, patents, and contributing (for CLA).

Breaking-changes workflow

This is mostly for @jessesquires but figured we could ideate in the open on this.

What is the best strategy for making breaking changes to IGListKit, while:

• We always use the latest master
• Cocoapods users always use a stable version
• Breaking changes should happen in one "major" update

We're launching with IGListKit 1.0, so should we store up all breaking changes in IGListKit 2.0? My only fear with that is that internally we sync w/ the master branch. Can we tell Cocoapods to use a release branch or something in our podspec?

It does look like we can specify the branch that Cocoapods uses :git => :branch. Should we create a release branch for this then?

Also, React has a seperate branch per stable version. Thoughts there?

[Swift] reference type and value type conformances to IGListDiffable

The handy NSObject+IGListDiffable category doesn't really help with Swift objects like String and Int. This seems a little tricky because String is a struct but is convertible to an NSString. Doing that conversion gives us the NSObject<IGListDiffable> conformance, but that's kind of lame. I wonder if there's a way we can get this to work a little better?

For example, the Swift 3.0 compiler wont allow this:

let letters: [IGListDiffable] = ["a", "b", "c"]

But you can get this to work a few ways:

let strings: [NSString]  = ["a", "b", "c"]
let letters = strings as [IGListDiffable]
// or
let letters = ["a" as IGListDiffable, "b" as IGListDiffable, "c" as IGListDiffable]
// or
let letters: [IGListDiffable] = ["a" as NSString, "b" as NSString, "c" as NSString]

Also adding an extension to String isn't easy either, since String is a struct and IGListDiffable is an Objective-C protocol...

Note that this also stunts using IGListDiffable with Swift structs

Sample project

I've got the samples built, but need to add them along w/ a readme, similar to this.

NSObject equality naming conflict

Issue

Since this project extends NSObject to make it conform to IGListDiffable and that protocol has a method with a similar isEqual signature as the standard NSObject one, it is creating naming conflicts with other, completely unrelated, objects in the project that use the vanilla isEqual comparison.

You should consider uniquely naming the IGListDiffable method, e.g.:

- (BOOL)isEqualToDiffableObject:(nullable id<IGListDiffable>)object;

I looked into opening a PR for this, but honestly there are too many vague isEqual calls in the codebase so I'm not sure which should be the diffable equality check and which should be the vanilla NSObject ones.

New issue checklist

• I have reviewed the README and documentation
• I have searched existing issues and this is not a duplicate

General information

• Library version(s): 1.0.0
• iOS version(s):
• Devices/Simulators affected:
• Reproducible in the demo project? (Yes/No): N/A
• Related issues:

Add examples for ASDK, ComponentKit, etc.

Follow up task from #86.

Add examples using:

• ComponentKit
• AsyncDisplayKit
• UIKit
• WKWebView

⚠️ If submitting a PR, please submit 1 PR per type of example

How to deal with JSON data?

Hi,
Firstly, I think this IGListKit is awesome and so useful!

This is more of a question than an issue, but I have JSON data returned from my servers that I want to populate my list with. Usually I would use SwiftyJSON to handle the data, and everytime -cellForItemAt is called, use something like data[indexPath.row]["text"].stringValue to retrieve the right part of the data and input it into the cell. However, I'm trying to figure out how to make this data work with IGListKit. As far as I can work out, I need to be able to some how separate each JSON object and combine it into an array that implements IGListDiffable to be returned in -objects(for:).

Would it be possible to provide me with some pointers, and possibly give an example of downloading and parsing JSON data from the web in the IGListKit example app? I think it would be super useful as I can see most people using this framework with data downloaded from online!

Thanks!

Objects with duplicate diffIdentifiers but different values break updates

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.

- (void)test_ {
  [self setupWithObjects:@[
                           // using string values IGTestDelegateController always returns 1 cell
                           genTestObject(@1, @"a"),
                           genTestObject(@2, @"a"),
                           genTestObject(@3, @"a"),
                           genTestObject(@4, @"b"), // problem item w/ key 4, value "b"
                           ]];

  // delete the last object from the original array
  self.dataSource.objects = @[
                              genTestObject(@1, @"a"),
                              genTestObject(@5, @"a"),
                              genTestObject(@6, @"a"),
                              genTestObject(@7, @"a"),
                              genTestObject(@4, @"a"), // key 4 but value "a", so this needs reloaded
                              genTestObject(@8, @"a"),
                              genTestObject(@4, @"b"), // key 4 but value didn't change
                              ];
  XCTestExpectation *expectation = genExpectation;

  [self.adapter performUpdatesAnimated:YES completion:^(BOOL finished) {
    [expectation fulfill];
  }];

  [self waitForExpectationsWithTimeout:15 handler:nil];
}

This throws within -[UICollectionView performBatchUpdates:completion:]:

*** Assertion failure in -[IGListCollectionView _endItemAnimationsWithInvalidationContext:tentativelyForReordering:animator:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIKit_Sim/UIKit-3599.6/UICollectionView.m:5569
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid update: invalid number of sections.  The number of sections contained in the collection view after the update (7) must be equal to the number of sections contained in the collection view before the update (4), plus or minus the number of sections inserted or deleted (5 inserted, 3 deleted).'
*** First throw call stack:
(
    0   CoreFoundation                      0x000000010228f34b __exceptionPreprocess + 171
    1   libobjc.A.dylib                     0x0000000101cf021e objc_exception_throw + 48
    2   CoreFoundation                      0x0000000102293442 +[NSException raise:format:arguments:] + 98
    3   Foundation                          0x0000000101886edd -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 195
    4   UIKit                               0x00000001030e8115 -[UICollectionView _endItemAnimationsWithInvalidationContext:tentativelyForReordering:animator:] + 16065
    5   UIKit                               0x00000001030f120a -[UICollectionView _endUpdatesWithInvalidationContext:tentativelyForReordering:animator:] + 71
    6   UIKit                               0x00000001030f154c -[UICollectionView _performBatchUpdates:completion:invalidationContext:tentativelyForReordering:animator:] + 432
    7   UIKit                               0x00000001030f1379 -[UICollectionView _performBatchUpdates:completion:invalidationContext:tentativelyForReordering:] + 91
    8   UIKit                               0x00000001030f12fb -[UICollectionView _performBatchUpdates:completion:invalidationContext:] + 74
    9   UIKit                               0x00000001030f1250 -[UICollectionView performBatchUpdates:completion:] + 53
    10  IGListKit                           0x000000010e097eff -[IGListAdapterUpdater performBatchUpdatesWithCollectionView:] + 3375
    11  IGListKit                           0x000000010e09ad8d __54-[IGListAdapterUpdater queueUpdateWithCollectionView:]_block_invoke + 429

This makes sense because the update that is applied looks like:

• Delete sections 1, 2, 3
• Insert sections 1, 2, 3, 5, 6

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.

Add an example for `workingRangeSize`

Currently in the read.me the workingRangeSize value proposed is a double (0.5), while the method actually requires an UInt, could you please add an example to show how it is properly used?

Unit test -[IGListAdapter scrollToItem:...]

This method is only tested manually and not backed by any type of automation. We should get a test up to make sure that all conditions pass:

• Vertical/horizontal scrolling
• No supplementary view
• Single supplementary view
• Multiple supplementary views
• Empty feed
• Item not in feed

(flagging as a bug since unit test coverage should be a requirement)

Setup travis CI

Should just need a .travis.yml file w/ steps to generate the tests w/ Cocoapods. Would be nice to build the sample app too so we can make sure that's always building.

Compile Error In Examples

Error in SpinnerCell.swift

IGListKit-master/Example/IGListKitExamples/Views/SpinnerCell.swift:25:53: Cannot convert value of type '(IGListCollectionContext) -> CGSize' to expected argument type 'IGListSingleSectionCellSizeBlock' (aka '(Optional<IGListCollectionContext>) -> CGSize')

Error in SingleSectionViewController.swift

IGListKit-master/Example/IGListKitExamples/ViewControllers/SingleSectionViewController.swift:65:74: Cannot convert value of type '(IGListCollectionContext) -> CGSize' to expected argument type 'IGListSingleSectionCellSizeBlock' (aka '(Optional<IGListCollectionContext>) -> CGSize')

Xcode suggests fix using casting that allows project to build so that line goes from:

return IGListSingleSectionController(cellClass: SpinnerCell.self,
                                         `configureBlock:` configureBlock,
                                         sizeBlock: sizeBlock)

To:

return IGListSingleSectionController(cellClass: SpinnerCell.self,
                                         configureBlock: configureBlock,
                                         sizeBlock: sizeBlock as! IGListSingleSectionCellSizeBlock)

and from:

let sectionController = IGListSingleSectionController(nibName: NibCell.nibName,
                                                              bundle: nil,
                                                              configureBlock: configureBlock,
                                                              sizeBlock: sizeBlock)

To:

let sectionController = IGListSingleSectionController(nibName: NibCell.nibName,
                                                              bundle: nil,
                                                              configureBlock: configureBlock,
                                                              sizeBlock: sizeBlock as! IGListSingleSectionCellSizeBlock)

However, this causes crash once the Single Section Controller or Tail Loading sections are accessed.

New issue checklist

• [+ ] I have reviewed the README and documentation
• [+ ] I have searched existing issues and this is not a duplicate

General information

• Library version(s): 1.0.0 and master
• iOS version(s): 10.0.2 and 9.3.5
• Devices/Simulators affected: se/6
• Reproducible in the demo project? (Yes/No): yes
• Related issues:

.gitignore file

I think we should ignore:

• .xcworkspace
• Cocopoads generated stuff
  • e.g. lock file, Pods dir

Anything else?

Issue and PR templates

In addition to a CONTRIBUTING.md, we should add issue and pull request templates:

https://github.com/blog/2111-issue-and-pull-request-templates

And put all of these in .github/

Conversion from value of type NSIndexPath* to incompatible type IGListMoveIndexPath*

XCode's static analyser shows issue:
/Users/someuser/somepath/IGListKit/Source/IGListDiff.mm:179:13: Conversion from value of type 'NSIndexPath *' to incompatible type 'IGListMoveIndexPath *'

New issue checklist

• [*] I have reviewed the README and documentation
• [*] I have searched existing issues and this is not a duplicate

General information

• Library version(s):
  1.0.0
• iOS version(s):
  Not relevant
• Devices/Simulators affected:
  Not relevant
• Reproducible in the demo project? (Yes/No):
  Not relevant
• Related issues:
  None

Storyboard support

I thought that storyboards would work out-of-the-box, but they don't. The adapter will attempt to register the cells, which probably writes over the cell registered as a prototype in the storyboard.

I think all we need to do is provide a dequeue method specifically for storyboards. This would skip checking and registering the cells. Something like:

- (__kindof UICollectionViewCell *)dequeueReusableCellFromStoryboardWithIdentifier:(NSString *)identifier forIndexPath:(NSIndexPath *)indexPath;

Note that we don't need to provide a cell class, unlike the current dequeue method, because the identifier is set in the storyboard.

RFC: View-model, auto diffing section controller

We generate view models to drive all of the cells in a particular section controller on Instagram. These models are derived from a top-level model that is created from server data. The view models are then used to configure things like image and text cells within a section controller.

We can represent this transformation:

protocol ViewModel: IGListDiffable {...}

func map(object: Any) -> [ViewModel] {...}

We could create a section controller that diffs its own array of ViewModel objects, then apply those diffs at the item (e.g. "cell") level.

There are a few gotchas to doing this, that's why I think a built-in and tested version of this would be valuable (similar to the embedded adapter idea in #31).

You end up with diffing of sections/section-controllers and the items/cells within them. It totally converts your setup to being data-driven all the way down to the cell level.

Add #51 to CHANGELOG

Need to note #51 in the changelog for next release.

Setup Cocoapods

• Add podspec file
• Add to Cocoapods.org
• Tag 1.0.0
• Push to pod repo

'Search autocomplete' example crashes with 'Section controller nil for cell'

New issue checklist

• I have reviewed the README and documentation
• I have searched existing issues and this is not a duplicate

General information

• Library version(s): 1.0.0
• iOS version(s): 10.1
• Devices/Simulators affected: iPhone 5s simulator (14B70)
• Reproducible in the demo project? (Yes/No): Yes
• Related issues: None

Repro steps

1. Run the example app
2. Go to 'Search autocomplete' example
3. Type a character in the search bar
4. Tap the cancel button in the search bar
5. Swipe the collection view halfway down
6. Swipe the collection view all the way up
7. Repeat 5 and 6 three times

The app will crash with:

IGListKitExamples[42894:733170] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Section controller nil for cell <IGListKitExamples.SearchCell: 0x7fd5bd41e2c0; baseClass = UICollectionViewCell; frame = (0 0; 320 44); hidden = YES; layer = <CALayer: 0x6000000396a0>>'
*** First throw call stack:
(
    0   CoreFoundation                      0x000000010d37634b __exceptionPreprocess + 171
    1   libobjc.A.dylib                     0x000000010cdd721e objc_exception_throw + 48
    2   CoreFoundation                      0x000000010d37a442 +[NSException raise:format:arguments:] + 98
    3   Foundation                          0x000000010c9a3d79 -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 166
    4   IGListKit                           0x000000010c8153e8 -[IGListAdapter visibleSectionControllers] + 1320
    5   IGListKit                           0x000000010c819390 -[IGListAdapter scrollViewDidScroll:] + 192
    6   UIKit                               0x000000010e1f3afd -[UIScrollView(UIScrollViewInternal) _notifyDidScroll] + 69
    7   UIKit                               0x000000010e1de525 -[UIScrollView setContentOffset:] + 478
    8   UIKit                               0x000000010e1ee06c -[UIScrollView _smoothScrollWithUpdateTime:] + 3141
    9   QuartzCore                          0x000000010de8ac35 _ZN2CA7Display15DisplayLinkItem8dispatchEy + 57
    10  QuartzCore                          0x000000010de8aaf5 _ZN2CA7Display11DisplayLink14dispatch_itemsEyyy + 449
    11  CoreFoundation                      0x000000010d308964 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
    12  CoreFoundation                      0x000000010d3085f3 __CFRunLoopDoTimer + 1075
    13  CoreFoundation                      0x000000010d30817a __CFRunLoopDoTimers + 250
    14  CoreFoundation                      0x000000010d2fff01 __CFRunLoopRun + 2065
    15  CoreFoundation                      0x000000010d2ff494 CFRunLoopRunSpecific + 420
    16  GraphicsServices                    0x00000001115dba6f GSEventRunModal + 161
    17  UIKit                               0x000000010e109964 UIApplicationMain + 159
    18  IGListKitExamples                   0x000000010c6ecb6f main + 111
    19  libdyld.dylib                       0x000000011040968d start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException

Can IGListKit be used with AsyncDisplayKit?

Can IGListKit be used with AsyncDisplayKit
https://github.com/facebook/AsyncDisplayKit

Code coverage service

Maybe Codecov.io. Need to get approval and setup.

Add analyze action to .travis.yml xcodebuild calls

New issue checklist

• I have reviewed the README and documentation
• I have searched existing issues and this is not a duplicate

Steps

• Fix remaining analyzer warnings.
• Add the analyze action to xcodebuild calls in .travis.yml, and ensure that builds that fail the analyzer fail the build.

[Gardening] Fix comment headers in IGListKitExamples/ project files

Some files in IGListKitExamples/ have incorrect comment headers, like:

https://github.com/Instagram/IGListKit/blob/master/Example/IGListKitExamples/ViewControllers/WorkingRangeViewController.swift#L1-L7

Should be:

https://github.com/Instagram/IGListKit/blob/master/Example/IGListKitExamples/ViewControllers/DemosViewController.swift#L1-L13

cc @rnystrom 😏

Add a UICollectionViewLayout similar to flow layout that doesn't newline sections, a section-based grid layout

If you use UICollectionViewFlowLayout and your item controllers return individual cells that should be in a grid (see Instagram Explore tab), they will stick vertically in new rows instead of fitting into rows/columns as if they were all in the same section.

We have this internally for our Explore product (which uses IGListKit) but the layout is pretty specific for that instance. It'd be amazing to have a general layout as part of the framework.

Error when running ./build_docs.sh

New issue checklist

• I have reviewed the README and documentation
• I have searched existing issues and this is not a duplicate

General information

I just tried to build a new version of the documentation but I ran into the following issue:

.../IGListKit/Source/IGListKit.h:18:9: fatal error: 'IGListKit/IGListAssert.h' file not found

I am using Jazzy version 0.7.2

Add jazzy docs

Let's generate jazzy docs from all of the header docs that we already have. We should also make sure Dash import works.

Move emptyView API to a property on IGListAdapter

There's really no need for this to be a required method on IGListAdapterDataSource. It could simply be a property, defaulted to nil. When you set the property we use it when the adapter is empty.

Not sure if we need to bother what happens if you set the property after everything has been updated.

Does not work with collection view self-sizing cells (.estimatedItemSize)

• [✅ ] I have reviewed the README and documentation
• [✅ ] I have searched existing issues and this is not a duplicate
• Library version(s):1.0.0
• Xcode Version(s):8.0
• iOS version(s):10.0
• Devices/Simulators affected:Simulators
• Reproducible in the demo project? (Yes/No):Yes
• Related issues:

I was trying to remove layout logic from view to SectionController,
and i add some layoutConstraints to cell's subviews and estimatedItemSize to UICollectionViewFlowLayout

But IGListKit does not work on auto-size.iOS will log craze.

    static var flowLayout = { () -> UICollectionViewFlowLayout in
        var layout = UICollectionViewFlowLayout()
            layout.estimatedItemSize = CGSize(width: 300, height: 300)
        return layout
    }()

IGListDiffable and Non-class type

New issue checklist

• I have reviewed the README and documentation
• I have searched existing issues and this is not a duplicate

General information

Is there any reason IGListDiffable could not be implemented on Struct?
the following code returns this error:
Non-class type 'Foo' cannot conform to class protocol 'IGListDiffable'

struct Foo: IGListDiffable {
  let id: String

  func diffIdentifier() -> NSObjectProtocol {
    return id as NSObjectProtocol
  }

  func isEqual(object: Any?) -> Bool {
    return false
  }
}

• Library version(s): 1.0.0
• iOS version(s): 10.0

Support cells created from nibs

The adapter registers and dequeues cells by converting the class name to a string as the reuse identifier. That means that we can only register class+identifier pairs and not use -[UICollectionView registerNib:forCellWithReuseIdentifier:]. Even though we don't use nibs in Instagram.app, it doesn't mean that we support this. It shouldn't be too difficult to add.

Add more asserts for view dequeueing in IGListAdapter

Noticed this in #90, it looks like there are some asserts that should be cleaned up:

• Assert elementKind.length > 0 for supplementary views

  • IGListKit/Source/IGListAdapter.m

    Line 746 in ce4b851

    - (__kindof UICollectionReusableView *)dequeueReusableSupplementaryViewOfKind:(NSString *)elementKind

• Assert index > 0

  • IGListKit/Source/IGListAdapter.m

    Line 714 in ce4b851

    atIndex:(NSInteger)index {

Reusable identifier methods should be c functions

These methods should just be C functions since they don't use any state on self. Would be awesome to just have a single function too to generate an identifier given a class and element kind. We will also probably use this when registering cells from UINibs, so consider a nib-name param.