ReactiveCocoa 5.0 之后版本的区别和选择

这两天注意到了ReactiveCocoa,好多个版本,然后找了下原因,看到了原因。

logo.png

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 。

转载出处

ReactiveCocoa 5.0 初窥:可能是最痛的一次升级

Last modification:February 17th, 2017 at 04:56 pm
如果看了这个文章可以让你少加会班,可以请我喝杯可乐
已打赏名单
微信公众号

2 comments

  1. 总裁商学

    原来如此,学习了

    1. 东东
      @总裁商学

      恩啊,共同学习

Leave a Comment