Modularize View Controllers

[ashfurrow]

Judging by our conversations with Facebook, it doesn't sound like one of the big selling features of ReactNative is to share code between Android and iOS, as was our hope. Worth continuing to investigate, but in the mean time, I have some thoughts about breaking our apps into smaller pieces so at the very least, we can share code between eigen/energy/eidolon.

So this is what I'm thinking:

We have different pods for different view controllers. They are well tested. They abstract things away. In apps, like eigen, energy, and eidolon, you subclass them and get a bunch of stuff for free. They'd live in their own pods – open source, but not on Trunk.

OK, so that we can all agree on. What about the architecture of these (abstract-ish) view controllers?

• I'd like them to provide protocols that their model objects conform to.
• I'd like them to use MVVM to provide support for common actions. For example, getting artwork details or whatever. I like MVVM because it'll keep the view controllers light and provide a way for individual apps to customize/extend behaviour (by subclassing the view models).
• I'd like them to rely on a centralized auth method.
• I'd like them to avoid referring to self.view if possible, to avoid loading the view hierarchy unintentionally.
• I'd like them to work with a common routing strategy.
• I'd like them to use ReactiveCocoa. Hear me out:
  • I honestly believe that signals represent a fantastic abstraction for network calls. They're lazily loaded, support cancellation, there's AFNetworking support, and provide a good "I got data, I finished, I errored" semantics.
  • View controllers would use ReactiveCocoa with their view models to expose signals that can be used with bindings by the view controller subclasses.
  • Additionally, they would expose methods to do the same work, but with callback blocks. That way projects aren't forced to do things "the reactive way." For example, something really basic like:

- (void)whatever:(void (^)(NSArray *whatevs))callback
    [self.signal subscribeNext:^(id x) {
        if (callback) {
            callback(x);
        }
    }];
}

Or whatever we need (error handling, etc). It would be awesome to find a way to make writing the "subscribe to a signal and return whatever is next" sorts of methods easy/fast. Maybe a C macro? Or auto-generated code? Dunno.

Next steps would be pulling small, similar view controllers out of both eigen and energy to see how much overlap there is. Do this a few times and we'll have an idea of how much effort this would be, the potential benefits of doing this, and a rough timeline of steps.

[alloy]

Judging by our conversations with Facebook, it doesn't sound like one of the big selling features of ReactNative is to share code between Android and iOS, as was our hope.

That wasn’t my take-away, mine was that code sharing was a nice side-effect of their choice to use ReactNative, not necessarily the reason they chose to use it.

[orta]

I also didn't get dissuaded from taking React Native more seriously, quite the opposite. Beating deadlines, developer productivity and separation of app code vs foundational are really interesting aspects of a tech that I've yet to see other paradigms take. Being able port work to Android in the future is great, it's just not there yet.

I don't want to be forced into using RAC for my VCs. I think it's a nice abstraction but I won't build things in it. Just as right now we don't have rules around its usage in Eigen, I would imagine the same here. A View Controller can have its public API and so long as we have established patterns around User Auth, Routing, Networking and Global State it shouldn't matter if it's RAC, React Native or Stacks.

Agree with thing like model categories. MVVM sounds like an internal PodVC choice too, just like NetworkModels.

I occasionally write tests in Energy about ViewControllers inits not creating a view - think this is a good call, could get something like that in https://github.com/artsy/mobile/issues/31#issuecomment-95180856

[ashfurrow]

I don't think I accurately communicated what I meant about ReactNative; I'm not dissuaded at all from using it, just that my impression was that sharing code between Android/iOS is not its main selling point. As Orta said, beating deadlines and all that is :+1:

I definitely don't want to force the VCs to use RAC – but I would push for a network layer written in signals. One that is also exposed as regular callbacks. The VC shouldn't care or know that it's RAC, but exposing the RAC signals would be helpful in many cases.