Today I am deprecating my open source library, JSQDataSourcesKit. I have already marked the CocoaPod as deprecated and archived the repo on GitHub. I will not be taking additional contributions.
I am not sure how many folks are using this library. Maybe a few dozen? A few hundred? They only way I could track this before was with CocoaPods stats, which has been dead for a while now.
Anyway, I have not made any substantial contributions since version 7.0.0 was released over two years ago. Subsequent releases were just upgrading Swift versions and dropping support for older OS versions. So really, it has been in a minimal maintenance mode for some time now.
My thanks goes out to all of the contributors over the years, in particular Panagiotis Sartzetakis, David Snabel-Caunt, and Kevin.
* * *
If you aren’t familiar with this library, this post has a good overview. It was an interesting approach to solving the “data source boilerplate” problem for UITableView and UICollectionView for iOS apps. However, it was not really a sustainable or practical design, which eventually backed me into a corner. It became difficult to modify, which is a code smell.
The main problem was all the generics and protocols with associated types. It was a cool idea, and interesting academically, but ultimately it proved too difficult to use in most real-world cases. If you were able to declare all the components in-line, it was very elegant as Swift could infer all the types (though early version of Swift struggled with this). However, you pretty much always needed to declare properties, resulting in code like this:
// For a view controller with a collection view
typealias Source = DataSource<CellViewModel>
typealias CollectionCellConfig = ReusableViewConfig<CellViewModel, CollectionViewCell>
typealias HeaderViewConfig = TitledSupplementaryViewConfig<CellViewModel>
let dataSourceProvider: DataSourceProvider<Source, CollectionCellConfig, HeaderViewConfig>
The type aliases help, but all the generics are simply overwhelming and unwieldy.
The other main issue was mapping a view model type to a cell type, and restricting the entire table view or collection view to a single cell type and thus, a single view model type. In other words, your data and cells had to be entirely homogeneous. But in practical iOS apps, as you know, you almost always need to display heterogeneous data and cells in a table view or collection view. There were workarounds for this, but they were not great. And let’s be honest, this should not be something you have to “work around” in a library like this.
Interestingly, certain aspects of this library informed the design of IGListKit, which I co-authored with Ryan. It also helped inform improvements to parts of ReactiveLists, after I joined PlanGrid and started contributing to that project. Overall, it at least turned out to be a great learning experience.
* * *
If you are currently using this library, I would suggest migrating to something else eventually — however, I do not think there is any reason to rush. It still works, but it will not be updated again. If you need to patch it, you can fork it on GitHub. It has very good test coverage at 90 percent.
You may be wondering, what would I do differently if I had to build this library again? Well, I have good news, too. I am working on a replacement. After writing, maintaining, and/or contributing to three different “list” libraries for iOS (JSQDataSourcesKit, IGListKit, ReactiveLists), I think the fourth time is the charm. So stay tuned.