I have a couple of examples of edit steps that are incorrect.

'64927513' -> '917546832': delete 4 at index 1 replace with 1 at index 1 replace with 4 at index 4 move 6 from index 0 to 5 insert 8 at index 6 insert 2 at index 8 UICollectionView error: attempt to delete and reload the same index path (path = 0 - 1)

'8C9A2574361B' -> '897A34B215C6': replace with 3 at index 4 delete 5 at index 5 move 7 from index 6 to 2 replace with B at index 6 replace with 2 at index 7 replace with 5 at index 9 move C from index 1 to 10 insert 6 at index 11 UICollectionView error: attempt to perform a delete and a move from the same index path (path = 0 - 6)

I'd love to use this with Carthage on my macOS projects, but the project was configured to provide iOS only (this is an Xcode limitation, I know). I've used the xcconfig approach in this PR on a few projects now, and it works quite well, but I'd understand any reluctance to merge it in.

The main downside is that the iOS Test App now thinks it can build on macOS and presents that option in the Xcode scheme switcher. Both the framework and tests can build across everything presented.

Added an iPhone app target to explore using Changeset while updating UICollectionView.

A naive implementation is provided for comparison.

Some of the problems identified in issue #12 are demonstrated. This example app will aid in resolving those problems, and will thereafter serve as a good example for people interested in using Changeset.

This PR adds a hook to the UIKit extensions on batch updates did begin. This permits users to update their data model inside the performBatchUpdates block – a measure which can prevent crashes with dynamic and/or inconsistent collection layouts.

This set of changes is about making Edit a type of a collection instead of a collection’s equatable elements plus the resulting changed requirements, including tests and test app. Merges into the version 3 branch.

An Edit needs to have a concept of the collection type so we can ensure we can do arithmetic on the collection’s index distance type, see discussion on #39.

I wasn’t able to declare …where C.IndexDistance: SignedInteger on Edit, Changeset while doing enumerations and additions/subtractions on offsets in a compatible way. At least I couldn’t figure out how to. So for now, we require Int index distances on the collections.

Note: I prefer to ensure all commits are compilable (git-bisect), hence all files in one commit.

FYI: I’m planning a general cleanup for version 3 (including using the C shorthand for Collection types, probably splitting up Edit and Changeset in separate files).

I have some thoughts and suggestions, but I'm not sure about if we need them resolved. Why I want to raise the issue is because maybe someone out there might be interested. They are mostly concerning substitution/reload and how UIKit and its documentation seems to treat it inconsistently.

Expose edit's origin (source) index, at least for substitution.

My translation from changeset's edit operations to UITableView's row operations is as follow:

| Edit | Row | | --- | --- | | Insert | Insert | | Delete | Delete | | Move | Move | | Substitution | Reload |

When executing row operations between beginUpdates and endUpdates, like delete, reload index is expected to be the ones prior to any updates. As stated in its API documentation:

The indexes that UITableView passes to the method are specified in the state of the table view prior to any updates.

Changeset provides the index after update instead. Making it unavailable to be mixed with other operations within beginUpdates and endUpdates.

Makes reducing edits to move optional.

As of 1.0.x, in order to use it with UITableView's row operation, I have to do something like this.

        var deletedIndexPaths = [NSIndexPath]()
        var insertedIndexPaths = [NSIndexPath]()
        var movedIndexPaths = [(from: NSIndexPath, to: NSIndexPath)]()
        var reloadIndexPaths = [NSIndexPath]()

        for edit in changeset.edits {
            switch edit.operation {
            case .Insertion:
                let insertedIndexPath = NSIndexPath(forRow: edit.destination, inSection: 0)
                insertedIndexPaths.append(insertedIndexPath)
            case .Deletion:
                let deletedIndexPath = NSIndexPath(forRow: edit.destination, inSection: 0)
                deletedIndexPaths.append(deletedIndexPath)
            case .Substitution:
                let reloadIndexPath = NSIndexPath(forRow: edit.destination, inSection: 0)
                reloadIndexPaths.append(reloadIndexPath)
            case .Move(origin: let origin):
                let fromIndexPath = NSIndexPath(forRow: origin, inSection: 0)
                let toIndexPath = NSIndexPath(forRow: edit.destination, inSection: 0)
                movedIndexPaths.append((from: fromIndexPath, to: toIndexPath))
            }
        }

        self.tableView.beginUpdates()

        if deletedIndexPaths.count > 0 {
            self.tableView.deleteRowsAtIndexPaths(deletedIndexPaths, withRowAnimation: .Automatic)
        }

        if insertedIndexPaths.count > 0 {
            self.tableView.insertRowsAtIndexPaths(insertedIndexPaths, withRowAnimation: .Automatic)
        }

        for (from, to) in movedIndexPaths {
            self.tableView.moveRowAtIndexPath(from, toIndexPath: to)
        }

        self.tableView.endUpdates()

        if reloadIndexPaths.count > 0 {
            self.tableView.reloadRowsAtIndexPaths(reloadIndexPaths, withRowAnimation: .Automatic)
        }

Reload is outside the beginUpdates and endUpdates for reason stated previous. But if I exposes the origin index for substitution edit operation, theoretically, I probably can wrap all operations in beginUpdates and endUpdates.

But this is not the case. It seems a little counter intuitive but the exception thrown by UITableView is as follows:

2016-01-23 22:58:35.504 ChangesetTest[3247:111068] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'attempt to perform an insert and a move to the same index path (<NSIndexPath: 0xc000000003800016> {length = 2, path = 0 - 28})'

It stated that we are trying to attempt an insert and a move row operation but those code have not change. Funny thing is that if I commented out the reload row operation code (which is possible here as their value will just remain outdated), it will no longer complain.

I believe this is more of a wording bug, UIKit probably meant insert and reload of the same index. But this I can't be sure.

The funny things is that the API documentation for move only mention that it can work with insert and delete, but avoid mentioning reload.

As for UICollectionView, its API documentation for batch update only mention that it can work with insert, delete and move but did not mention about reload. Which will make the current solution for UITableView seems correct.

If I remove the reduce edit step. I can make it work nicely with reload in table view.

But the thing about reload is that it is the least obvious row operation visually. And there are several other options that are reasonable as well. For example, we can get visible rows and update the cell manually (no animation), or just not batching it like above (not an issue as well).

Hey, I just read the readme. I like this a lot. Do you think this could be applied to trees as well? Imagine I have a tree of lightweight structs. Can I compare two trees and find the minimum changes required going from one to the other?

I have a comment regarding terminology.

The indices the library computes for the Edit steps are currently always integers and always zero-based (i.e. the first index is 0). This works great for the intended main use case (table and collection view updates) because the index paths of a table or collection view are also zero-based and composed of integers.

However, it doesn't reflect the reality of Swift's collection types. For example, ArraySlice uses integer indices, but they aren't zero-based. If you compute the changeset for two ArraySlice instances, the result is arguably wrong or at least confusing:

let source = [2,3,4,5].dropFirst() // ArraySlice<Int>
let target = [3,4,5,6].dropFirst() // ArraySlice<Int>
let edits = Changeset.edits(from: source, to: target)
print(edits)
// Prints "[delete 3 at index 0, insert 6 at index 2]"

If you tried to apply this changeset literally to the source collection (i.e. delete the element at index 0 from source), youʼd get a crash because source doesnʼt have an "index" 0.

In a way, a similar issue is when you compute changesets for strings (as most of the unit tests do) because string indices are not integers, so saying something like "insert "a" at index 5" doesn't strictly make sense in Swift.

I find this a little confusing and misleading. Changeset appears to be generic for any collection, and yet it doesn't follow Swift's conventions where the term "index" has a very specific meaning.

When I first noticed this "problem" I wanted to suggest replacing the integer indices in Edit and EditOperation with the collection's index type (i.e. something like T.Index). On second thought, this doesn't make sense because a changeset would have to compute "virtual" indices for a collection that doesn't really exist, and since collections are free to invalidate any existing index upon mutation, I don't think you could compute the indices in a generic way. Moreover, using real collection indices would make supporting table/collection view updates harder, not easier.

After writing all this, I realize that the way this works is actually the best solution for the given problem. Having written this, I'm going to submit it too, even though I don't have a specific suggestion. Feel free to close this issue, and maybe it will help others understand this better when they find it in search.

My only suggestion would be to make it clear that Changeset and Edit aren't concerned with indices, but with offsets. I think if the debugDescription read "delete x at offset 0" etc. I would have been less confused. This is exemplified by the use of enumerated() to compute the column value in edits(from:to:), since enumerated() computes offsets from 0 and not indices (see http://khanlou.com/2017/03/you-probably-don't-want-enumerated/ for more info on enumerated() and how it's often misinterpreted).

It's not enough to use a default values equality for my project and I extended the code with ability to init a Changeset with a custom comparator. If you will find this change helpful, please, consider it to merge to your project.

I'm using Changeset v2.0, and I've run into an issue where I'm applying a batch delete which produces something akin to:

[0] { operation = .delete, value = …, destination = 0 }
[1] { operation = .delete, value = …, destination = 1 }
[2] { operation = .delete, value = …, destination = 2 }
[3] { operation = .delete, value = …, destination = 3 }

If I process this in order by applying the deletes to a table, this will (pretty obviously) crash when it tries to remove destination 3 (which in the target collection, no longer exists).

Is this something that Changeset should be handling for me? I don't recall this being an issue with v1.

• unreduced edits are edits without converting insertion/deletion pairs into .Move edits
• unreduced edits is also good for manual changes in a UITableView or UICollectionView, since UITableView's only allow insertion, deletion, and update on rows.
• converted tabs into spaces

Currently with Xcode 12 using Changeset produces warning:

The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.0.99.

This PR changes minimum iOS deployment target for CocoaPods to 9.0, and removed platforms from Package.swift.

Please note, that platforms inside Package.swift do not specify supported platforms, but rather minimum versions of supported platforms, which is only needed if package minimum deployment target is higher than SPM supported deployment targets.

Are there any plans for supporting Carthage? I don't really want to add Pods to my project, and the Swift Package Manager option is currently failing with:

  ~ swift package generate-xcodeproj
Fetching https://github.com/osteslag/Changeset.git
Completed resolution in 4.39s
Cloning https://github.com/osteslag/Changeset.git
Resolving https://github.com/osteslag/Changeset.git at 3.1.1
warning: PackageDescription API v3 is deprecated and will be removed in the future; used by package(s): Changeset
'Changeset' /Users/pcferreira/Projects/OnboardingReactiveSwift/.build/checkouts/Changeset.git--4643115965670364357: error: package has unsupported layout; found loose source files: /Users/pcferreira/Projects/OnboardingReactiveSwift/.build/checkouts/Changeset.git--4643115965670364357/Tests/ChangesetTests.swift
'OnboardingReactiveSwift' /Users/pcferreira/Projects/OnboardingReactiveSwift: error: product dependency 'Changeset' not found

I can't figure out how to make the compiler happy when trying to express something like this:

public protocol ChangesetApplying: class {
    associatedtype T
    func apply(changeset: Changeset<T>)
}

The above will complain that Type 'Self.T' does not conform to protocol 'Collection'.

Changing it to associatedtype T: Collection yields a different error: Type 'Self.T.Iterator.Element' does not conform to protocol 'Equatable'.

Changing it to associatedtype T: Collection where T.Iterator.Element: Equatable, T.IndexDistance == Int yields the error 'where' clause cannot be attached to an associated type declaration, which appears to be the subject of SE-0142.

Any ideas?