Crash when update occurs as side effect of view configuration

[composed-swift]

Crash when update occurs as side effect of view configuration

[shaps80]

This doesn't really make sense. The whole point of calling performBatchUpdates for every single update is to ensure it enqueues those correctly. So it shouldn't be possible to NOT have index-0. That being said I do remember reading somewhere that the call to performBatchUpdates is sync while the internal execution is async. So it'll return immediately but potentially execute later. I believe this is to ensure you can call this quite rapidly without issue.

The most common cause of issues here is usually the data being out of sick. Are you updating the model inside the performBatchUpdates as well, you should be?

[JosephDuffy]

The most common cause of issues here is usually the data being out of sick. Are you updating the model inside the performBatchUpdates as well, you should be?

Moving to the closure-based design is aimed to ensure that the models are updated inside performBatchUpdates (Composed is currently not guaranteeing this).

---

One way this crash seems to happen is when the configuration of a header (possibly cells, I've not tested this yet) triggers an update. This is probably impossible to support without capturing the updates closure and I think should be classed as a misuse of the API (note that I wrote part of this 😬).

The workaround I've found (after a few separate debugging sessions) is to invalidate all if this scenario is detected:

• performBatchUpdates has been called on the collection view
• All updates have been applied to the collection view

After the updates have been applied the collection will layout, dequeuing views as necessary. If any of these views then trigger an update it will enter CollectionCoordinator.mapping(_:willPerformBatchUpdates:) again, so the logs make sense now.

I've added a long print statement when this happens so consumers can debug this a little easier. Invalidating everything fixes the crash so I think this is a good compromise?

At first I thought this might work because collection view apparently supports nested batch updates:

But I would guess their logic is along the lines of:

• Call updates
• Dequeue views
• Commit changes
• async wait for animations
• Call completion

Because the crash is essentially:

• Call updates
  • updates inserts 0,0
• Dequeue views
  • Dequeuing deletes 0,0
• Crash because 0,0 doesn't exist