ReactiveCocoa 5.0 初窥：多是最痛的一次升级

RAC 5.0 相比于 4.0 有了巨大的变化，不只是受 swift 3.0 大升级的影响，RAC 对自身项目结构的也进行了大幅度的调整。这个调整就是将 RAC 拆分为四个库：ReactiveCocoa、ReactiveSwift、ReactiveObjC、ReactiveObjCBridge。

ReactiveCocoa

如今的 RAC 注意力主要集中在 Swift 和 UI 层上，将原来一个基于 RAC 面向 UI 层的扩展库 Rex 合并进了 RAC 。

RAC 3 和 4 的主要精力在围绕 Swift 从新打造一个响应式编程库。由于这部分的核心 API 已经很成熟，因此如今将重心放在为 AppKit 和 UIKit 提供一些更好用的扩展上。

ReactiveSwift

原来 RAC 中只和 Swift 平台相关的核心代码被单独抽取成了一个新框架：ReactiveSwift 。

Swift 正在快速成长而且成长为一个跨平台的语言。把只和 Swift 相关的代码抽取出来后，ReactiveSwift 就能够在其余平台上被使用，而不仅是局限在 CocoaTouch 和 Cocoa 中。

ReactiveObjC

在 RAC 3 和 4 中，RAC 也包含了 RAC 2 中的 OC 代码。如今这部分代码被移到了 ReactiveObjC 。

这样作的缘由是由于两个库虽然有着同样的核心编程范式，实际上倒是彻底独立的两套 API 。实际的使用中，RAC 4 和 RAC 2 是彻底不一样的两组用户群，而且维护的团队其实也是两组。以前混在一个库里也增长了管理的复杂度。拆分出去后也能够更加自由的维护 ReactiveObjC 。

ReactiveObjCBridge

在把 Swift 和 OC 的库拆分以后问题来了，并非全部的库都是纯 OC 和 Swift 的。有至关大一部分项目处于 OC 迁移到 Swift 过程当中，其中可能使用 Swift 调用了 RAC 2 中基于 OC 写的 API。为了解决这部分用户的问题，因此有了 ReactiveObjCBridge 。

在项目里如今到底要引入哪些

若是你只是纯 swift 项目，你继续使用 ReactiveCocoa 。可是 RAC 依赖于 ReactiveSwift ，等于你引入了两个库。

若是你的项目是纯 OC 项目，你须要使用的是 ReactiveObjC 。这个库里面包含原来 RAC 2 的所有代码。

若是你的项目是 swift 和 OC 混编，你须要同时引用 ReactiveCocoa 和 ReactiveObjCBridge 。可是 ReactiveObjCBridge 依赖于 ReactiveObjC ，因此你就等于引入了 4 个库。

API 从新命名😭

这部分的给个人感受就是会呼吸的痛。不少 API 须要从新找一遍，并且命名也变了。

一个方向是参照 RxSwift 采用了reactive 的命名空间。好比：

let appearing = view.reactive.trigger(for: #selector(viewWillAppear(_:)))

let producer = object.reactive.values(forKeyPath: #keyPath(key))复制代码

API 都放在了 reactive 后。再也不是原先的 rac_xx 。

还有一部分与 UI 相关的属性命名也改了，多是受 rex 的影响。好比：

// 原来是 rac_text
viewModel.searchString <~ textfield.reactive.textvalues="" button.reactive.pressed="CocoaAction(viewModel.commit)
  
  
  

 复制代码

还增长了生命周期 lifetime 的属性。好比：

signal.take(during: object.reactive.lifetime)复制代码

当 object 被回收的时候信号也中止获取 value 。

最后

让咱们一块儿笑着活下去🙃。

欢迎关注个人微博：@没故事的卓同窗

---

相关连接：
RAC change log