cdzombak/thingshub — pull request #1 by andrewsardone (2014-01-15 16:02:38+00:00)
Title: Clean up authentication manager to expose a signal-based API

@cdzombak, this is in response to some concerns we discussed about the “callback-hell” nature of [`CDZGithubAuthManager`](https://github.com/cdzombak/thingshub/blob/45e118e9d73e8f7e4bb9920f04a495539ab8247d/thingshub/CDZGithubAuthManager.m).

I think the callback-hell and approachability of the code derives from the fact that the method returns `void`. The method *is* an accessor of sorts – we simply want an authenticated `OCTClient`. Unfortunately, without raising our level of abstraction we have to resort to a callback block, [despite our language actually having a notion of return types][gif].

So, starting from the interface, let's restructure the method like so:

```objc
/// Returns a `RACSignal` that will send the appropriate `OCTClient` for the
/// given `githubLogin`.
+ (RACSignal *)authenticatedClientForUsername:(NSString *)githubLogin;
```

Now client code could bind to that change over time. It looks like you create a `CDZIssuesSyncEngine` from authenticated clients, so you could make that relationship explicit with something like this:

```objc
RAC(self, syncEngine) = [[RACSignal authenticatedClientForUsername:@"cdzombak"] map:^id(id client) {
return [[CDZIssueSyncEngine alloc] initWithAuthenticatedClient:client];
}];
```

It's a somewhat trivial example. but the goal is to declare these functional relationships as opposed to imperatively writing code within callbacks.

I could walk through some of the changes or you could ping me with questions in-line.

[gif]: https://f.cloud.github.com/assets/14554/1921777/16b7afc6-7dfe-11e3-942b-d0ecf3d9bf56.gif