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 的命名空間。好比：

1 2 3

let appearing = view.reactive.trigger( for : #selector(viewWillAppear(_:)))   let producer = object.reactive.values(forKeyPath: #keyPath(key))

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

還有一部分與 UI 相關的屬性命名也改了，多是受 rex 的影響。好比：

1 2 3 4

// 原來是 rac_text viewModel.searchString <~ textField.reactive.textValues   button.reactive.pressed = CocoaAction(viewModel.commit)

還增長了生命週期 lifetime 的屬性。好比：

1	signal.take(during: object.reactive.lifetime)

當 object 被回收的時候信號也中止獲取 value 。

最後

讓咱們一塊兒笑着活下去????。

歡迎關注個人微博：@沒故事的卓同窗

相關連接：RAC change log