ReactiveCocoa 利弊

[nagato]

新公司项目全是Reactive去构建的，本人实在无法习惯。一个简单到可以直接用IBAction搞定的UIButton响应事件，Reactive要写三倍代码去搞定，TargetAction绑定那个UIButton，在响应里面创建一个RACCommand，完了还得在另外一个地方Subscribe。完全想不到用Reactive的点在哪。。。


而且Reactive代码写多了之后显得一团糟，各种signal的关系里不清，还造成block的过分使用导致各种Strong weak self 的过分使用很容易导致retain circles。

当然我也许接触Reactive还不够久，了解还不够深入。有没有对Reactive比较熟的来分析下利弊？

[chmlai]

首先, 在 Button 的绑定方式对项目的复杂度几乎没有影响. 如果你没有写足够多的代码, 确实很容易纠结这个上面.

"Reactive代码写多了之后显得一团糟", 这很可能是你还没学会 RAC(FRP);
假设业务的复杂度不变, 与 RAC 的声明式编程比各种 delegate, action-target, block-callback 混在一起,定义各种状态那才叫一团糟.

循环引用根本不是什么问题.

没什么办法, 多写点代码, 多看点资料, 多体会一下就好了.

[Elethom]

我能說用了 RAC 之後代碼可讀性提升了一個數量級麼⋯⋯

不明白為什麼要把代碼分開寫，需要響應一個 control event 只需要一行 subscribe 就夠了。

[nagato]

@Elethom
目前是这样的,
1. ViewModel里面先构建一个RACCommand，create RACSignal 什么的就不说了
2. 在UIView的子类里把某个UIButton进行绑定之前那个command，addTarget：action
3. 在需要相应UIButton事件的地方，subscribe ViewModel里的那个RACCommand

但是所有这些，其实一个IBAction就可以搞定了。领导给的解释是，为了保持Reactive的风格，请还是保持前者

[chmlai]

@nagato
业务逻辑一般写在 RACCommand 里的 Signal generation block里面;
你的第3步 subscribe 一般不大需要.

[WeeTom]

http://www.teehanlax.com/blog/model-view-viewmodel-for-ios/
看看作者怎么说。
一个UIButton 是很简单，但是当你的项目足够大，Controller里面会包含太多的业务逻辑代码，非常难以维护。。这点我也是深有体会~而且很乱。。
我在做新项目也是准备使用ReactiveCocoa的~

[kepenj]

ReactiveCocoa 个人觉得作为快速构建一个新的应用，同时具备vc瘦身和单元测试非常方便和极优。但是理解RAC和整体框架源码是要花费不少时间；同时如果项目规模较大后，所有逻辑和模块还是得自己写和维护。