ReactiveCocoa/ReactiveCocoa — pull request #910 by jspahrsummers (2013-10-31 14:11:23+00:00)
Title: [WIP] Replace RACCommand with RACAction

**:warning: NOT READY TO MERGE :warning:**

Retrying #874 from a different angle.

I think a lot of the confusion about `RACCommand` stemmed from trying to solve _two_ very different problems with the same class:

1. A control that invokes an action when tapped
1. Starting a task with some input, and eventually receiving a response

They're not _exactly_ mutually exclusive, but it's hard to create an abstraction that covers 100% of both, so this is an attempt to just focus on the first use case.

Major changes from `RACCommand`:

* **A more intuitive name.** This should be more familiar to Cocoa developers, since it evokes the idea of target-action. Thanks to @paulcbetts for the suggestion.
* **Enabledness is tracked separately.** Create a separate `RACSignal` with your enabledness condition, expose that from your view model, and bind it to your control separately. This simplifies `RACAction`, and more closely matches how controls are validated in MVC with plain AppKit/UIKit.
* **Execution is _always_ serial.** Attempting multiple executions is not erroneous — they just get deduplicated into one. If you want to do something more complicated (a la `RACCommand.allowsConcurrentExecution`), write it by hand. Uncommon cases should be hard.
* **More understandable usage.** `-[RACAction execute:]` is easy to understand and use, because it works just like a typical action method. It's pretty common to handle errors out-of-band anyways, so that method doesn't need to return a signal.
* **Removed the confusing signal of signals.** I looked at real world use of `RACCommand`, and decided that `executionSignals` isn't actually useful for _UI-driven actions_. All applications of it are actually request-response patterns, like I alluded to above.
* **Initialized with a lazy signal, or block, never both.** Since controls don't actually give you meaningful input, we don't need a block to dynamically create signals. This should make the `executing` status much clearer, since it's either subscription-based or block-based, never a weird mixture. This also helps reinforce Cold Signals All The Time™.

Thoughts?

### To do:

- [ ] Unit tests for `RACAction`
- [ ] Deprecate `rac_command` extensions and add `rac_action` equivalents
- [ ] Update standalone documentation

@jonsterling @tonyarnold @erikprice @dewind @ashfurrow @lawrencelomax