我翻译的RAC4的文档
ReactiveCocoa 4 官方文档翻译
ReactiveCocoa 4 文档翻译：基本操作符(一)
ReactiveCocoa 4 文档翻译：基本操作符(二)
ReactiveCocoa 4 文档翻译：框架组成介绍
ReactiveCocoa 4 文档翻译：兼容Objective-C
ReactiveCocoa 4 文档翻译--设计指南(一)：事件的规范
ReactiveCocoa 4 文档翻译:设计指南(二)：信号的规范
[翻译]ReactiveCocoa 4 最佳实践

兼容性

关于 RAC 4的文档是在Swift 2.1.x下使用。对于Swift 1.2的支持请看 RAC 3.

介绍

ReactiveCocoa来源于functional reactive programming(Input and Output)。
区别于使用不断变化修改的变量，RAC提供了“事件流”，通过 Signal 和 SignalProducer 类型来表示, 它们随着时间发送值。
事件流统一了Cocoa用于事件和异步处理的常用模式，包括：

• 委托方法
• 回调blocks
• 通知
• 控件的actions和响应事件链
• Futures and promises
• Key-value observing (KVO)

因为这些不同的机制能够用一种相同的方式处理，可以很容易的声明成链（chain）并且把它们联合在一起，用更少的代码和状态连接它们。
更多关于RAC里的概念可以查看Framework Overview.

例子：在线搜索

假设你有一个text field，每当用户输入文字时，你都会发起一个网络请求根据输入的关键字查询。

实时观察文字变化

实现这个目的的第一步，使用RAC中UITextField的一个扩展方法：
<pre><code>
let searchStrings = textField.rac_textSignal()

.toSignalProducer()

.map { text in text as! String }
</code></pre>
这样产生了一个signal producer 来发送输入的字符串。 ( text as! String这种类型映射在当前是必需的，为了从OC桥接当前的扩展方法

发送网络请求

获得了每次输入的字符串，我们想要发送一个网络请求。RAC也为我们提供了NSURLSession的一个扩展方法来实现：
<pre><code> let searchResults = searchStrings

.flatMap(.Latest) { (query: String) -> SignalProducer<(NSData, NSURLResponse), NSError> in

let URLRequest = self.searchRequestWithEscapedQuery(query)

return NSURLSession.sharedSession().rac_dataWithRequest(URLRequest)
}

.map { (data, URLResponse) -> String in

let string = String(data: data, encoding: NSUTF8StringEncoding)!

return self.parseJSONResultsFromString(string)
}

.observeOn(UIScheduler())
</code></pre>
这段代码将字符串的producer转换成了一组包含了搜索结果的producer，并且会在主线程中处理(由于UIScheduler的作用).。
另外这里的flatMap(.Latest)确保只有最后的一次搜索会被执行。
如果当一个请求还在处理中，此时用户输入新的字符，在发起新的请求之前会取消之前的请求。想想这些如果自己实现的需要写多少代码！

接收结果

这样实际上还没有执行，因为producers必须started后才执行（对于返回结果没有被使用时做的优化）。这个很简单：
<pre><code>searchResults.startWithNext {

results in print("Search results: (results)")

}
</code></pre>
我们获取值用于<code>Next</code>中的event：包含了请求结果，并且把他们log到了控制台。这里也可以写其他UI控制的代码，比如reload一个table view。

失败处理

到目前为止，这个例子中，任何的网络错误都会产生一个<code>Failed</code> event,这会导致整个事件流终止。不幸的是，这意味着之后请求不会被发起。
为了避免这样的情况，我们需要决定当失败发生时怎样处理。最快速的解决方案就是记录它们，然后忽略它们：
<pre><code>.flatMap(.Latest) { (query: String) -> SignalProducer<(NSData, NSURLResponse), NSError> in

let URLRequest = self.searchRequestWithEscapedQuery(query)

return NSURLSession.sharedSession()

.rac_dataWithRequest(URLRequest)

.flatMapError { error in

print("Network error occurred: (error)")

return SignalProducer.empty

}

}
</code></pre>
通过将失败替换为空事件流，可以有效的忽略它们。
然而，在放弃前最好重试几次。在一次，使用retry可以方便的达到这个目的。
改进后的searchResults producer会像这样：
<pre><code>
let searchResults = searchStrings

.flatMap(.Latest) { (query: String) -> SignalProducer<(NSData, NSURLResponse), NSError> in

let URLRequest = self.searchRequestWithEscapedQuery(query)

return NSURLSession.sharedSession()

.rac_dataWithRequest(URLRequest)

.retry(2)

.flatMapError { error in

print("Network error occurred: (error)")

return SignalProducer.empty } }

.map { (data, URLResponse) -> String in

let string = String(data: data, encoding: NSUTF8StringEncoding)!

return self.parseJSONResultsFromString(string) }

.observeOn(UIScheduler())
</code></pre>

降低请求频率

现在，我们假设你只希望在用户输入暂停时才发起请求以减少网络请求。
RAC通过<code>throttle</code>操作符可以用于实现这个需求：
<pre><code>
let searchStrings = textField.rac_textSignal()

.toSignalProducer()

.map { text in text as! String }

.throttle(0.5, onScheduler: QueueScheduler.mainQueueScheduler)
</code></pre>
这样当间隔小于0.5秒时值不会被发送出去，意味着用户必须停止编辑0.5秒后我们才会使用输入的字符串去搜索。
如果用自己实现这个功能，真是要写不少代码，而且还会影响代码的可读性。但是在RAC中，只需要一个操作符就可以方便将时间控制加入事件流。

Objective-C 和 Swift

虽然RAC是作为一个OC的框架开始的，但是从 版本3.0开始，所有的主要特性开发都是基于 Swift API。
RAC的Objective-C API和Swift API是完全分开的，但是有一个bridge可以将他们互相转换。这主要是为了兼容使用RAC的一些老项目，或者用于一些还没有被加入Swfit API的一些Cocoa扩展。
Objective-C API将继续存在，在可预计的未来将提供支持，但是不会有新的改进。关于使用这些API的信息可以参考：legacy documentation。
我们强烈建议所有的新项目采用Swift API。

ReactiveCocoa和Rx的关系

ReactiveCocoa 受了 Microsoft’s Reactive Extensions (Rx)库的不少影响。有很多对于Rx的实现，包括 RxSwift,但是ReactiveCocoa无意于成为Rx的一个实现子集。
RAC和 Rx的区别,主要有以下一些：

• 更简洁的API
• 解决了令人困惑的常见问题
• 更贴近Cocoa的编程习惯

命名

在大部分Rx的版本中，流被称为Observables，对应于.NET中的<code>Enumerable</code>类型。
另外， Rx.NET大部分的操作符参考了 LINQ，而LINQ是用于操作传统关系型数据库的，比如<code> Select </code>和<code> Where </code>。
RAC则最关注于匹配Swift的命名规范, 使用 <code> map </code> 和<code> filter </code>来替换select和where。其他的一些命名来源于Haskell或Elm（使用“signal”的始祖）。

Signals and Signal Producers (“hot” and “cold” observables)

Rx中的“hot”, “cold”, and “warm” observables (对应RAC中的事件流)很容易让人困惑。

对于这个部分和Typed errors的区别，因为在我翻译的iOS响应式编程：ReactiveCocoa vs RxSwift 选谁好中有更详细的对比说明，这里就不翻译了。

Typed errors

处理错误时方式

UI编程

很多人不知道Rx怎么用。即使用Rx进行UI的编程很常见，它有几个特性用于一些特别的场景。
RAC从ReactiveUI借鉴了很多，包括 Actions的基础操作。
不像ReactiveUI不能直接将Rx改变的对于UI编程更友好，为了这个目的则进行了很多次的改动—即使这意味着和Rx的区别越来越大.

欢迎关注我的微博：@没故事的卓同学