Natasha_Murashev_-_Protocol_oriented_MVVM.md

Natasha Murashev - Protocol oriented MVVM

• Amazing talks by Andy Matushak (Controlling complexity in Swift & Making friends with value types) made her dive into value types more. Every time she made a value type she needed to subclass and she turned out using a class anyway. Then the talk about POP at WWDC 2015 happened. “Swift is protocol-oriented programming language” -Dave Abrahams.

• The power of protocols is know to most because of stuff like UITableViewDataSource, UITableViewDelegate and more. These patterns are beautiful and we all love them. But at work it’s hard to suddenly transition to a new paradigm.

• Reading: MVVM in Swift. MVVM is all about abstracting model, formatting and other data related things out of your ViewController. View models are very testable and clean. The view controller should keep track of the view model state. When view models are static the view controller will determine what is displayed to the user, the view model just hold the (computed) data.

• Problem: configuring a simple UITableViewCell can be a lot more complex than it seems. In Swift you can put default values for method parameters but it’s still a very complex method. Protocols can help here. Solution: If you have a protocol that implements all the values you want to configure you can make a viewModel conform to that protocol. Then when calling a large configure method you could just pass it a delegate in the form of a protocol. That protocol would contain all information about the cell state. Splitting this protocol in two (dataSource and delegate) makes it more like Apple’s table delegate and dataSource. The dataSource could just contain a label and a boolean (on/off). Delegate would be handlers and other config data. The configure method would get both a delegate and a dataSource instead of a single protocol.

• In game development subclassing makes a lot of sense. There’s usually a pretty obvious hierarchy in games so it seems very good. But, if suddenly a build should become able to shoot you get a bit of a messy architecture. If you could use mixins in the form of protocol extensions you can slap functionality onto objects without getting a complex class hierarchy. You can use a generic to make sure a delegate conforms to multiple protocols. Example: configure(T<where T: SomeProtocol, T: OtherProtocol>) .

• Because Swift is a new language it still changes a lot. As a community we should look for best practices and make sure that we can make changes fast.

• Some rules of thumbs:

  1. Use protocols to configure your views
  2. Use protocol extensions for defaults (fonts, colors, config)
  3. Use ViewModels to provide data for the protocols

• Question: Have you tried using FetchedResultController at all?

• No but you would fetch the model and pass that to a VM, the VM would convert it to displayable data.

• Question: How do you have the ViewModels? Are they just wrappers around Models?

• Kind of, yes. They take the values and they convert the data into displayable data.

• Question: If you want to change something on the view, would you replace the whole ViewModel?

• Yes, you would replace the whole model. You could mutate state on structs and all that but it’s cleaner to just replace the whole ViewModel.

• Question: You said it was hard to come up with a use case. Do you think this is it or is there still room for improvement?

• Yes, there’s room for improvements. When I was testing some code I used protocols like MinionTestable that made it very easy to have a testable API call instead of a real one.

• Question: Have you seen pitfalls with this? Like you could write models and extensions to fulfil you protocols?

• Well I like to use ViewModels because it’s very clear about it’s intent. Also, let’s say you’re dealing with a form. You don’t want optionals on your models. The viewmodel could handle optionals and when it’s all valid you have a clean model that can be sent off to the API. The ViewModel can be the messy part.

• Question: You had pattern with the cell, setting datasource and delegate. The delegate had a callback. It would have to know which cell is calling that delegate function.

• Yes, your ViewModel should be unique for the cell. So the ViewModel communicates back to the cell with for example a completion black.

Some links: blog post, github