Discussion: alternative to completion handlers on reload/endUpdates, etc

[garrettmoon]

From @eanagel on July 26, 2015 15:53

I've been thinking about this since adding the completion handlers for reloadData and endUpdates and #581 by @frankenthumb got me thinking about it more. The essential issue is that, without these completion handlers, there is no guarantee that the UITableView's data is in sync with the asyncDataSource. You can handle some things by always relying on ASTableView (or ASCollectionView) as the source of truth for your data, but sometimes you just need them to be in sync. (My #1 use case is positioning to a specific row after reload.)

I've been thinking it might be simpler and more elegant to introduce a new method that solves this problem more generally. One that basically says "run this block when all changes up to this point have been committed." Technically, that's what these completion blocks are, but they are only available for these two methods currently.

I've been struggling with what this method sholud be called, but let's say we call it -(void)syncEditsWithCompletion:(void (^)())completion;. This would call completion on the main thread as soon as all currently scheduled updates (which should include reloadData begin/endUpdates or any of the editing commands) have completed and before any others have been initiated.

@appleguy I'm thinking we can just schedule this completion on the editingTransationQueue to accomplish this easily. That would work, right? I'm also wondering exactly how reloadData works W.R.T. the editingTransactionQueue and if that approach would work with that.

Would love some feedback on this idea.

Copied from original issue: facebookarchive/AsyncDisplayKit#587

[garrettmoon]

From @nguyenhuy on September 6, 2015 19:20

I've been thinking about #638 for the last few days and eventually came up with an idea similar to this one. So thanks @eanagel, @levi and @connor for bringing this up.

Regarding the implementation of this new method, I suspect that it would look similar to (if not exactly like) what I've done in -relayoutAllRows here, of course, with a parameterized block. Once we have that new method, -relayoutAllRows will simply call it with its own block.

With that, I guess the main issue left is the naming (assuming there is no objection against this new method).