Reactive collections

[andersio]

Collections are essential to any application logic, so as collection views in any user experience. So at some point, we should consider merging ReactiveCollections into ReactiveSwift and ReactiveCocoa.

To achieve it within a reasonable time frame (Swift 4.0 and ReactiveSwift 3.0), it is proposed to scope the collection effort to the following goals:

• [ ] Define a collection snapshot & changeset format.

  444

• [ ] Collection diffing operator that computes deltas across versions of collections.

  444

• [ ] Collection diffing operator that supports nested, two-level collections.

  494

• [ ] Minimum viable binding solution: changeset application. (TBD in ReactiveCocoa)

• [ ] Full fledged a collection binding API. (TBD in ReactiveCocoa)

With the defined abstractions and the API model, the project can be deemed ready to merge into ReactiveSwift and ReactiveCocoa. Feature parity can be improved on top of these works without significant design effort, but generally just implementation effort.

ReactiveCollections

The ReactiveCollections project remains the evolving ground for dedicated, mutable containers that provide improved performance characteristics than the O(n) Heckel's diffing algorithm.

List of possible directions

• Live-updating filtered/sorted views.
• Collection aggregates (i.e. multiple collections presented as one).
• [RAC] Bindings for other AppKit and UIKit collection views.
• [RAC] CoreData and Realm integration.

/cc @ReactiveCocoa/reactiveswift @ReactiveCocoa/reactivecocoa

[andersio]

Closing this issue as agreed in https://github.com/RACCommunity/ReactiveCollections/pull/38 that ReactiveSwift should have no part in the collection binding effort.