Summary: These methods are currently correctly annotated as `nullable`, because they can return `nil`. However, this is not practical for writing actual Swift code that uses the APIs. Overrides of `cellForItem(at:)` //must// return a `UICollectionViewCell`. Without a collection context, there's no good way to get one, so callsites must either: - Force-unwrap the `collectionContext`. - `guard let`/`else fatalError` the `collectionContext`. - Return a default `UICollectionViewCell`, which just hides the bug. None of these are good: we don't want to encourage things force-unwraps and `fatalError` in idiomatic product code, because people will see them and get the idea that these patterns are okay to use elsewhere, and they are not. This also happens with `IGListGenericSectionController`'s `object` value: to use it when creating a cell, it must be explicitly unwrapped. We could make these `nonnull`, since there's no enforcement of the annotations in Objective-C, that feels a bit too far, and it would break existing code that uses the optional API, because you can't force-unwrap (etc.) a non-optional value. Instead, we can use `null_resettable` explicitly. [While it's not covered by name in the Apple docs](https://developer.apple.com/documentation/swift/objective-c_and_c_code_customization/designating_nullability_in_objective-c_apis): > Without a nullability annotation or with a null_resettable annotation—Imported as implicitly unwrapped optionals ...it bridges the property to Swift as an implicitly-unwrapped optional. I suppose it's implied as the equivalent of "without a nullability annotation". This works even for `readonly` properties that can't be reset, and it solves both issues: it feels like less of a "100% `nonnull`" guarantee, and it's backwards-compatible with code using optionals. To demonstrate that this is backwards-compatible with existing Swift code, this test code, which runs through various optional/non-optional APIs, compiles: ``` final class TestSectionController: ListSectionController { override func cellForItem(at index: Int) -> UICollectionViewCell { let cell = collectionContext.dequeueReusableCell(for: self, at: index) let optional = collectionContext?.dequeueReusableCell(for: self, at: index) if let _ = collectionContext {} return optional ?? cell } } final class TestGenericSectionController: ListGenericSectionController<NSString> { override func cellForItem(at index: Int) -> UICollectionViewCell { let label = UILabel() // imagine it's from a cell label.text = object as String label.text = (object as String) + "Suffix" // wouldn't work with optional label.text = object.map { $0 as String } if let object = self.object { label.text = object as String } return collectionContext.dequeueReusableCell(for: self, at: index) } } ``` Reviewed By: patters, lorixx Differential Revision: D23603716 fbshipit-source-id: e4750dcfe0072d482951dbf2e9efb1ee3de46884 |
||
|---|---|---|
| .github | ||
| docs | ||
| Examples | ||
| Guides | ||
| IGListKit.xcodeproj | ||
| IGListKit.xcworkspace | ||
| Pods | ||
| remodel-plugin | ||
| Resources | ||
| scripts | ||
| Source | ||
| Tests | ||
| .gitignore | ||
| .slather.yml | ||
| .travis.yml | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| Dangerfile | ||
| Gemfile | ||
| Gemfile.lock | ||
| IGListDiffKit.podspec | ||
| IGListKit.podspec | ||
| IGListSwiftKit.podspec | ||
| LICENSE.md | ||
| Package.swift | ||
| Podfile | ||
| Podfile.lock | ||
| README.md | ||
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 master branch in the Instagram app.
Requirements
- Xcode 9.0+
- iOS 9.0+
- tvOS 9.0+
- macOS 10.11+ (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
For advanced usage, see our Installation Guide.
Getting Started
$ git clone https://github.com/Instagram/IGListKit.git
$ cd IGListKit/
$ ./scripts/setup.sh
- 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.