Communicating up the chain from subviews in ReactiveCocoa MVVM world

[bobspryn]

Curious when/if you guys leverage the responder chain. I've been playing with different ways of communicating events and status amongst view controllers and subviews like cells. Of most interest to me is communicating back up that chain, which is where I'm wondering if the responder chain would be a good solution.

For propagating view information down the chain, I've tried different combinations of the the cell just having access to the view controller view model (since it's technically representing some of the data coming from that view model), or subviews/cells having their own view model. The later is certainly more modular, but more work.

My main question lies with some event occurring in a subview/cell (a uibutton tap or a uiswitch flipping) somehow being propagated up to the main view model, ultimately so it can affect other views/cells in the main view (think of flipping a switch and hiding some cells). When the cell shares the view controller's view model, it's easy enough because you just call a method on that view model. When the cell has it's own view model, there are a lot of options, none of which feel quite ideal. You could call a method on the cell view model, which in turn would call a method on it's delegate (the view controller view model). You could expose a signal on the cell view model, which the parent view model observes. There are a few other possible solutions too.

So I've been wondering if it would be easier to not try and send messages back up that chain, but instead use the responder chain to call a method on the view controller, which in turn can update the view model appropriately, which would propagate any changes back down the view model hierarchy.

// cc @ashfurrow

[bobspryn]

Sorry if this is a bit in the weeds, but I just like to have a thorough grasp of patterns and their why's and why-not's.

To provide a current example:

I have a view controller that displays a post. That view controller has a view model. One of the cells displays hash tags associated with that post. The hash tags are tappable, and ultimately should cause a new view controller to be pushed onto the stack with data about that hashtag.

So I have a custom cell, with the ability to return hot words tapped in a label. Somehow I need to surface this action of tapping a hashtag, and the respective hashtag name, up to the primary view model so that it can create a view model for that hashtag detail page and supply it to the view controller.

I've went through several incarnations of this:

1. The cell having it's parent view controller's view model. This is easy as I can just call a method on that view model, but it's coupling things together that need not know of each other. Less reusable.
2. The cell has no view model, and I propagate events to the view controller either via the responder chain, or signals exposed on the cell. (The one nice thing about the responder chain in this instance is not setting up new bindings every time a cell with signals was re-used, though you would have to look at the cell's .m code to determine what selectors to respond to). Instead of actually implementing the selector, I used signalForSelector.
3. The cell has it's own view model, created from the parent view model and assigned in the view controller when preparing the cell. In this case the cell propagates events to it's view model via commands. The parent view model can then observe the signals on those commands and take the appropriate action. This has the downside of creating another file for a simple cell, and I'm not sure it makes sense for a view model to be more or less propagating/broadcasting ui events like that which it doesn't really care about.

[joshaber]

I think both (2) and (3) are legitimate ways of solving the problem. If the cell is simple enough that it doesn't need its own view model, (2) seems perfectly fine.