Eliminate context property to improve type safety by making Row a protocol

[ryanworl]

I played around with this idea a bit this morning but it isn't fully baked yet and I'm definitely not a Swift generics expert, but what do you think about this:

1. Add a new protocol (RowType?) with all the current properties of Row, minus the context property.
2. Make Row implement RowType.
3. Sprinkle in RowType everywhere Row current exists outside of the Example project (this is where I ran into a bunch of road blocks with generics, need to re-watch that WWDC session with Krusty...)

This would let users of Static define their own implementations of Row and then (this is the important part!) overload the configure method on their cell in an extension with their custom Row type and do everything in a type-safe manner within.

Am I crazy or is this do-able?

[soffes]

I actually started down this route, but it got complicated quickly. The main reason is you can't make RowType equatable. For example something like TextFieldRow can't be compared with Row since they are different types all together. Maybe we can drop equatable and do it with protocols instead.

I thought context as a bit better. WKInterfaceController uses contexts. That's where I got the idea. Basically, if you make a TextFieldRow, now this Row needs to know about the presentation. The goal was to make Row a view model totally agnostic of its view.

Thoughts? cc @ayanonagon @hyperspacemark

[ryanworl]

Why wouldn't Equatable work with RowType? Assuming you stick with just comparing UUID strings like the current implementation, I don't see a problem.

And about separating concerns, the example I was thinking about would be a cell with three labels and a VM with three strings of text. Conceivably there could be many cells displaying those three strings depending on the context and the VM doesn't really need to know anything other than that it has three strings.

I'll play around with this more as I have time. Thanks for the work so far! 😀

[soffes]

You can't equate a protocol. Try implementing it ;)

Ya that's fair. I'd love to have this if you can make it work. Properties are better than context any day

[ryanworl]

That's annoying! I wrote it out this morning as func ==<T: RowType>(lhs: T, rhs: T) thinking it would work when the compiler didn't complain. Actually trying to use it doesn't work though. That's rough.

[soffes]

Yep. Makes sense though. Say you had a protocol like Accountable that required a var account: Account { get set } property or something. If you made a UIView subclass called AvatarView conform and then made Double conform it's total nonsense to compare a Double and AvatarView. I see why they picked to make it work this way, but it's definitely frustrating in this case.