Blocking up the main thread. Some public API adjustments.
opened this issue · comments
I attempted to implement Dwift with a library called CollapsableTable.
I planned to make so many changes to Dwift, I decided to pull each file out individually and work on it in isolation. So you'll notice the library is actually called Difter (in attached file) at the moment.
The public API of Dwift recommends the use of a table view calculator, which takes the table view and does some magical stuff to it. This was taking a bit too much control away from me, so I wanted to avoid using it.
The changes are quite extensive so I didn't want to issue a pull request for it until I get some feedback on what you think about the approach.
If the data model is 500 items or more, the main thread gets blocked up. Take a look at the attached code and run the Example Xcode scheme.
I've put a loading screen in place.
The public API of Dwift recommends the use of a table view calculator
Not so - you're welcome to call Dwifft.diff on two arrays, and do whatever you like with the results (that said, TableViewDiffCalculator exists because there are some important nuances when performing incremental updates on a table/collection view, so I recommend you look at the source if you're considering building something similar).
If the data model is 500 items or more, the main thread gets blocked up.
I think you'll find that if you're managing a data model that large, you'll run into performance issues with UIKit much sooner than you'll run into them with Dwifft (for example, trying to insert that many rows into a UITableView using insertRows can take several seconds).
I don't think this is a direction I'd like to take Dwifft, but best of luck with your fork. For what it's worth, I think you can implement the effect you're trying to achieve fairly trivially on top of TableViewDiffCalculator and SectionedValues.
Not much of a discussion