Refine TableEditingController design

[jessesquires]

We added TableEditingController in #67.

There's one awkward thing about the design:

You have to capture the dataSource in the commitEditing closure, as seen here in the example. This also makes it awkward to test. There's a kind of "chicken and egg" problem.

Suggested solution:

Maybe we pass DataSourceProtocol back in this closure? I think that would work.

This would then require moving the remove(at:) methods from the DataSource to the DataSourceProtocol. And we would need to figure out a solution for FetchedResultsController here — probably the hardest part.

[jessesquires]

@dcaunt @psartzetakis - thoughts here?

[dcaunt]

I think it makes sense to pass something back in a closure when you have this kind of chicken and egg scenario.

[psartzetakis]

I agree with you, it looks kind of weird now.. However I was thinking the following as well.
Since removing/inserting requires action with the tableView as well (tableView.deleteRows), do you think that it would be a good idea to handle that as well (even optionally...) 🤔

[jessesquires]

do you think that it would be a good idea to handle that as well (even optionally...)

Hm... not sure at the moment. For now, I would say let's not do that. Let's see how it feels without this first. 😃

[psartzetakis]

I had a quick play with the recommended solution 😀.
So I reached to the point where:

         commitEditing:{ [unowned self] (tableView, editingStyle, indexPath, dataSource) in
               if editingStyle == .delete {
                   var dataS = dataSource
                   if let _ = dataS.remove(at: indexPath) {
                      tableView.deleteRows(at: [indexPath], with: .automatic)
                   }
               }

And I realised that the dataSource is a struct so we have value semantics. So eventually I will have a copy of the dataSource which is not what we want.. Do I miss something...?🤔
I can push my code in a PR if need be ..

[jessesquires]

@psartzetakis ugh dammit. you're right. 😅

hm... let's think about this more 🤔

I think we can pass the Provider's data source as inout

[jessesquires]

Also, in this example, you do not want to create a local var -- that's also a problem. you want to mutate the dataSource param directly.

[psartzetakis]

you do not want to create a local var -- that's also a problem. you want to mutate the dataSource param directly.

I am getting a compiler error since it is coming as let from the closure...

I think we can pass the Provider's data source as inout

I already did that quickly but it didn't seem to work... 😅

I think we should elaborate it a bit more.. 😁

[jessesquires]

Ha. Damn. Ok, I'll play around with this. 😄