RxSwift之traits后篇：RxCocoa traits

这里是原文：Traits (formerly Units)
这一篇是整篇翻译的后半部分，建议先看看前半部分：RxSwift之traits前篇：RxSwift traits

RxCocoa traits

---

Driver

这是最复杂的trait，它的目标是提供一种简便的方式在UI层编写响应式代码，或者任何你想模拟驱动你的App的数据流的情况。

• 不能抛出错误
• 监听发生在主线程
• 分享副作用（shareReplayLatestWhileConnected)

为什么命名为Driver

它的目标用例是作为驱动你的App的序列模型。
例如：

• 由CoreData模型驱动UI
• 使用其他UI元素（绑定）的值驱动UI

就像正常的操作系统驱动程序一样，假如一个序列抛出错误，你的应用程序就会停止响应用户操作。
那些元素在主线程被监听，这极其重要，因为UI元素和程序逻辑通常不是线程安全的。
此外，Driver建立了一个分享副作用的可观察序列。
例如：

实际使用的例子

这是一个典型的初学者例子：

let results = query.rx.text
    .throttle(0.3, scheduler: MainScheduler.instance)
    .flatMapLatest { query in
        fetchAutoCompleteItems(query)
    }

results
    .map { "\($0.count)" }
    .bind(to: resultCount.rx.text)
    .disposed(by: disposeBag)

results
    .bind(to: resultsTableView.rx.items(cellIdentifier: "Cell")) { (_, result, cell) in
        cell.textLabel?.text = "\(result)"
    }
    .disposed(by: disposeBag)```
以上代码的预期行为是：
* 节流用户输入
* 联系服务器并获取用户结果列表（每次查询一次）
* 绑定结果到两个UI元素：results table view和一个显示结果数字的label

那么，这个代码有什么问题呢？
* 如果`fetchAutoCompleteItems `可观察序列抛出错误（连接失败或者是解析错误），这个错误将会解绑所有元素，并且UI不会再响应新的查询。
* 如果`fetchAutoCompleteItems`在某个后台线程返回结果，这些结果将会从一个后台线程绑定到UI元素上，这将会导致不确定的崩溃。
* 结果被绑定到两个UI元素上，这就意味着，对于每个用户查询，都会建立两个HTTP请求，每个UI元素对应一个，这并不是预期的行为。

一个更为合适的代码版本如下：

let results = query.rx.text
.throttle(0.3, scheduler: MainScheduler.instance)
.flatMapLatest { query in
fetchAutoCompleteItems(query)
.observeOn(MainScheduler.instance) // results are returned on MainScheduler
.catchErrorJustReturn([]) // in the worst case, errors are handled
}
.shareReplay(1) // HTTP requests are shared and results replayed
// to all UI elements

results
.map { "($0.count)" }
.bind(to: resultCount.rx.text)
.disposed(by: disposeBag)

results
.bind(to: resultsTableView.rx.items(cellIdentifier: "Cell")) { (_, result, cell) in
cell.textLabel?.text = "(result)"
}
.disposed(by: disposeBag)```
确保所有这些要求在大型系统中被正确处理很有挑战性，但有一种简单的使用编译器和traits来证明这些要求得到满足的方法。
下面的代码看起来几乎一样：

let results = query.rx.text.asDriver()        // This converts a normal sequence into a `Driver` sequence.
    .throttle(0.3, scheduler: MainScheduler.instance)
    .flatMapLatest { query in
        fetchAutoCompleteItems(query)
            .asDriver(onErrorJustReturn: [])  // Builder just needs info about what to return in case of error.
    }

results
    .map { "\($0.count)" }
    .drive(resultCount.rx.text)               // If there is a `drive` method available instead of `bindTo`,
    .disposed(by: disposeBag)              // that means that the compiler has proven that all properties
                                              // are satisfied.
results
    .drive(resultsTableView.rx.items(cellIdentifier: "Cell")) { (_, result, cell) in
        cell.textLabel?.text = "\(result)"
    }
    .disposed(by: disposeBag)```
那么这里发生了什么？
第一个`asDriver`方法把trait`ControlProperty `转换成trait`Driver `。

query.rx.text.asDriver()```
注意没有任何特别的事情需要做。Driver拥有ControlProperty所有的属性，加上一些其他的。底层的可观察序列只是被封装成了一个Drivertrait，就是这样。

第二个变化是：

.asDriver(onErrorJustReturn: [])```
任何可观察序列都能被转化为`Driver`，只要它满足三个属性：
* 不能抛出错误
* 在主线程监听
* 分享副作用（`shareReplayLatestWhileConnected `）

那么如何确保这些属性得到满足呢？只使用标准的Rx操作符。
`asDriver(onErrorJustReturn: []) `和以下代码是等价的。

let safeSequence = xs
.observeOn(MainScheduler.instance) // observe events on main scheduler
.catchErrorJustReturn(onErrorJustReturn) // can't error out
.shareReplayLatestWhileConnected // side effects sharing
return Driver(raw: safeSequence) // wrap it up```
最后一件事是用drive代替bindTo。
drive只在Driver特性里定义。这就意味着，如果你在某些代码里看到drive，那个可观察序列绝不会抛出错误，并且它在主线程监听，这对于绑定一个UI元素来说是安全的。

注意，然而理论上，别人仍然可以为ObservableType或者是一些其他接口定义一个drive方法来工作，因此为了更加安全，在绑定UI元素之前用let results: Driver<[Results]> = ...创建一个临时的定义是有必要的。然而，我们将留给读者来决定这是否是一个现实的方案。

ControlProperty / ControlEvent

• 不能抛出错误
• 订阅发生在主线程
• 监听发生在主线程
• 分享副作用