Open zdavison opened 10 years ago
You may want to add map:
in a category on NSArray
. It helps me a lot.
This belongs in the parent view model, IMO. For example, if you have a ListViewModel
, it should be responsible for creating ListItemViewModel
s out of ListItem
s.
You can also use -[RACSequence map:]
and friends to make the implementation less verbose.
I've created a helper class that makes it easy to bind a collection of view model objects to a table view, as follows:
// create a cell template
UINib *nib = [UINib nibWithNibName:@"CETweetTableViewCell" bundle:nil];
// bind the ViewModels 'searchResults' property to a table view
[CETableViewBindingHelper bindingHelperForTableView:self.searchResultsTable
sourceSignal:RACObserve(self.viewModel, searchResults)
templateCell:nib];
The above binds the viewModel.searchResults
property, which is of type NSArray
, to the searchResultsTable
, rendering each item in the array as a CETweetTableViewCell
. Each item in the array is itself a view model which is bound to the respective cell view.
You can read more about it here:
http://www.scottlogic.com/blog/2014/05/11/reactivecocoa-tableview-binding.html
I am currently in the process of updating it to support mutable arrays.
I have made a similar helper class called HFTableCollectionBindingHelper. It supports mutable arrays and multiple sections. You can find it here:
https://github.com/haifengkao/HFTableCollectionBindingHelper.
One problem I've yet to find a solution to using MVVM is where to neatly take care of Model > ViewModel conversion/wrapping.
I tend to have a ViewModel class per each TableViewCell/CollectionViewCell, and hence when I create a datasource that initializes itself with a set of Model objects, I need to do something like the following:
This is....kind of gross, and also leads to creeping complexity and difficulty of use whenever you have to unwrap viewmodels to get to their underlying models (eg, when handing off a viewmodel to another class that wants to create it's own viewmodel).
I've thought of a few solutions to this but none really work:
model
property of the viewModel. This also means we don't get any nice caching of our viewModel properties, and limits us to functions that expose/transform the underlying models properties in realtime as they are called.MVVM_ADAPT(collection, targetClass)
. This is sort of okay.I still haven't come up with a nice way around this, it's my only gripe with MVVM right now. What do you do in your projects?