The idea of this is that without breaking the API the collection view will batch updates.

Inserting a large number of sections is the main area of performance loss we are currently encountering, because the sections are inserted individually and not batched. This change alone has reduce the initial load time of one our screens (which has 100-150 sections added at once) from 30-45 seconds down to less than a second (at least it is not noticeable).

I had created https://github.com/composed-swift/Composed/pull/17 to try and address this, which has the advantage that it would apply to other view types (e.g. UITableView), but I believe does not offer the same performance improvements and it is restricted to a single ComposedSectionProvider.

This is a draft to collect feedback; as you can see there are some TODOs but I think there's enough implemented to provide an overview of the changes that would be required to implement this.

This does not currently work; there are situations that cause the collection NSInternalInconsistencyException', reason: 'Invalid update error. I have some failing tests that demonstrate what the result should be.

As mentioned in https://github.com/composed-swift/ComposedUI/issues/13 and https://github.com/composed-swift/ComposedUI/issues/8 there are some scenarios where the collection view’s data is out-of-sync with the data in composed.

As mentioned in https://github.com/composed-swift/ComposedUI/issues/13 calling layoutIfNeeded can trigger the data to be in sync again. In this I have added it to mappingWillBeginUpdating(_:) which appears to solve the problem.

It might be needed in replace(sectionProvider:) (because reloadData is called) and/or mappingDidInvalidate(_:) (for the same reason) but I’m still investigating.

I have validated this fix against https://github.com/composed-swift/ComposedUI/issues/8 and it fixes the crash.

https://github.com/composed-swift/ComposedUI/issues/13 still needs to be investigated and may require layoutIfNeeded to be called in mappingDidInvalidate. Marking as a draft until this is checked.

The tests are currently essentially empty but at a minimum this makes sure things compile on Xcode 11.7 and 12.0.

@shaps80 I think this will need updates to the repo settings to enable GitHub Actions.

Introduced in #9. #12 adds GitHub actions to ensure this doesn't occur again.

The completion block is called when the animation has completed, but at the end of the updates block the data has already been updated (from the perspective of the UICollectionView).

Not calling reset() and setting defersUpdate = false could cause crashes e.g. due to changes being applied multiple times.

The best way to recreate this is to have a series of updates occur very close to each other but with the "Slow Animation" setting enabled in the simulator.

This change might also apply to table views, I have not checked.

The crash would often be along the lines of "Tried to delete section at index 11 but there were only 11 sections" or would occur in elementsProvider(for:) with the error "No UI configuration available for section 11" when performing a non-data change e.g. a reload of a section

Sometimes it's useful to have multiple different cell types within a single section, for example to use sticky headers or to reduce to need for many layers of composition (which can be tricky to get animation right for).

This isn't a breaking change for consumers.

I think some of the naming should be improved if this were to be merged.

Draft because I want feedback on the impact of the feature itself rather than specifically the code.

Using embedded collection views with each one using a CollectionCoordinator would cause an infinite loop in responds(to:).

Maybe it's better to check in responds(to:)? I don't know if there are other scenarios this could happen in.