Support additional UITableViewDataSource methods

[jessesquires]

The following methods from UITableViewDataSource are currently not supported.

Section index titles

• - sectionIndexTitlesForTableView:
• - tableView:sectionForSectionIndexTitle:atIndex:

Editing

• - tableView:commitEditingStyle:forRowAtIndexPath: (Issue 29 table view data source editing #67)
• - tableView:canEditRowAtIndexPath: (Issue 29 table view data source editing #67)

Reordering

• - tableView:canMoveRowAtIndexPath:
• - tableView:moveRowAtIndexPath:toIndexPath:

---

Implementation notes

For each of the 3 categories above, there should be separate protocols and structs. Generic parameters for each should include Cell and Item, and the implementations should follow the patterns established by the existing protocol TableViewCellFactoryType and struct TableViewCellFactory.

Section index titles

1. Create a protocol TableViewSectionIndexingType
2. Create a struct TableViewSectionIndexingController

Editing

1. Create a protocol TableViewEditingType
2. Create a struct TableViewEditingController

Reordering

1. Create a protocol TableViewReorderingType
2. Create a struct TableViewReorderingController

Finally, TableViewDataSourceProvider.init should optionally receive each of the above protocols.

[bonebox]

Any update on this @jessesquires? I need to be able to edit rows.

[jessesquires]

Hey @bonebox 😄 this is definitely "future work" for me right now.

However, I've tried to provide enough guidance in the issue description so that someone could get started and submit a PR. Would you be interested? (Just for the editing -- not all 3) If so, I'll be able to answer questions, review the PR, etc. 👍

[jessesquires]

There's good test coverage and a good demo app for this project, so it should be easy to get started

[jessesquires]

UPDATE: No work should happen on this until 4.0 is out, which contains many breaking changes.

[psartzetakis]

//Assuming that we have the following model for TableViewDataSourceEdit 

public protocol DataSourceEditingProtocol{
    associatedtype Item
    func configureCanEditRowAt(indexPath:IndexPath,in tableView:UITableView, for item:Item)->Bool
}

public struct DataSourceEditingController<DataSource:DataSourceProtocol>:DataSourceEditingProtocol{

    public typealias Item = DataSource.Item
    public typealias CanEditConfigurator = (IndexPath,UITableView)->Bool

    public let canEditConfigurator:CanEditConfigurator

    public init(canEditConfigurator:@escaping CanEditConfigurator){
        self.canEditConfigurator = canEditConfigurator
    }

    public func configureCanEditRowAt(indexPath: IndexPath, in tableView: UITableView, for item: DataSource.Item) -> Bool {
        return canEditConfigurator(indexPath, tableView)
    }
}
//Then I will have to pass to the `DataSourceProvider.init` an optional of `DataSourceEditingProtocol`.
//However I have a question, since the `DataSourceProvider` has the signature below

public final class DataSourceProvider
    <DataSource: DataSourceProtocol,
    CellFactory: ReusableViewFactoryProtocol,
    SupplementaryFactory: ReusableViewFactoryProtocol>
where CellFactory.Item == DataSource.Item, SupplementaryFactory.Item == DataSource.Item {}

//I need to pass one more constraint for example `DataSourceEdit:DataSourceEditingProtocol`.

How can I pass a DataSourceEditingProtocol as an optional on the DataSourceProvider.init by avoiding adding a constrain on the class's signature? I am assuming the we will need the Item.

Thanks :)

[jessesquires]

Thanks for the interest here @psartzetakis ! 😄

How can I pass a DataSourceEditingProtocol as an optional on the DataSourceProvider.init by avoiding adding a constrain on the class's signature?

Haha. Welcome to Swift's type system. 😉 This is exactly what I wanted to do for SupplementaryFactory so clients wouldn't have to provide it. Unfortunately, expressing these semantics is currently not possible.

---

I'm wondering, does DataSourceEditingProtocol even need Item ? If we pass an index path, clients could access the element from the dataSource themselves. We could also just pass back the full dataSource itself...

---

cc @dcaunt for any other thoughts

[psartzetakis]

I see... It would be nice to have the Item but since it can't be Optional we can omit it. I believe the idea with passing just the IndexPaths sounds a bit more elegant to me...

[jessesquires]

@psartzetakis 👍

Also, just FYI — we're going to be pushing releases for swift 2.3 and 3.0 very soon. branches will be changing a lot. you might want to wait to do any serious work here (or base it off of the swift3.0 branch)

[psartzetakis]

@jessesquires I have already branched from swift 3.0 :)

[psartzetakis]

Hi @jessesquires , I have done some work related to the editing functionality. I would like to do some more for the other sections of that thread but because that will be my first pull request in an open source project I would prefer to submit it for review first. By doing that I can take any feedback and apply it to any of my future work :) . Since I have branched from swift3.0 I cannot rebase now to develop. So would you like to approach this? Wait until you merge swift3.0 into the develop or submit my work in swift3.0?

[jessesquires]

@psartzetakis 🎉

Sounds awesome. 👍

1. Many, smaller PRs are always better than one giant one
2. Yeah -- submit to swift3.0 for now and we'll figure it out.