ReactiveCocoa vs RxSwift - 優點和缺點？

Question

所以現在有了swift， ReactiveCocoa人員已經在3.0版本中為swift重寫了它

此外，還有另一個名為RxSwift的項目。

我想知道人們是否可以添加關於兩個框架的設計/ api /哲學的差異的信息（請在SO的精神中，堅持真實的事情，而不是關於哪個是“最好的”的意見）

[注意StackOverflow mods：這個問題有確切的答案，答案是兩個框架之間的差異。 我認為這也是SO的主題

首先，我閱讀ReadMe的最初印象是：

• 作為熟悉微軟“真正的”C＃Rx的人，RxSwift看起來更容易識別。
• ReactiveCococa似乎已經進入了它自己的空間，引入了新的抽象，如Signals vs SignalProducers和Lifting。 一方面，這似乎澄清了一些情況（什么是熱與冷信號），但另一方面，這似乎增加了框架的復雜性很多

Answer 1

這個問題問得好。 比較兩個世界是非常困難的。 Rx是Reactive Extensions在其他語言（如C＃，Java或JS）中的端口。

Reactive Cocoa的靈感來自功能反應式編程 ，但在過去的幾個月中，也被反應性擴展所啟發 。 結果是一個與Rx共享某些東西的框架，但其名稱起源於FRP。

首先要說的是，根據Conal對概念的定義 ，RAC和RxSwift都不是功能反應式編程實現。 從這一點來看，一切都可以簡化為每個框架如何處理副作用和一些其他組件。

我們來談談社區和元技術的東西：

• RAC是一個已有3年歷史的項目，在完全放棄Objective-C的正在進行的工作后，出生於Objective-C，后來移植到Swift（帶橋）。
• RxSwift是一個幾個月的項目，現在似乎在社區中有動力。 對於RxSwift而言重要的一點是，在ReactiveX組織下，並且所有其他實現都以相同的方式工作，學習如何處理RxSwift將使Rx.Net，RxJava或RxJS成為一項簡單的任務而只是一件事語言語法。 我可以說這是基於哲學學習一次，適用於所有地方 。

現在是技術人員的時候了。

制作/觀察實體

RAC 3.0有2個主要實體， Signal和SignalProducer ，第一個發布事件而不管用戶是否連接，第二個實體需要start實際生成信號/事件。 這個設計是為了區分熱和冷可觀察的乏味概念而創建的，這對很多開發人員來說都是混亂的根源。 這就是為什么差異可以減少到他們如何管理副作用 。

在RxSwift中， Signal和SignalProducer轉換為Observable ，它可能聽起來令人困惑，但這兩個實體在Rx世界中實際上是相同的。 RxSwift中的Observable設計必須考慮它們是熱還是冷，它聽起來可能是不必要的復雜性，但是一旦你理解了它們是如何工作的（再次熱/冷/溫暖就是訂閱時的副作用/觀察）他們可以被馴服。

在這兩個世界中，訂閱的概念基本相同，RAC引入的一點點差異是在發送完成事件之前處理Signal時的interruption事件。 回顧兩者都有以下類型的事件：

• Next ，計算新接收的值
• Error ，計算錯誤並完成流，取消訂閱所有觀察者
• Complete ，將流標記為已完成取消訂閱所有觀察者

此外，RAC在Signal處理之前發送interrupted ，在正確完成或出錯之前發送Signal 。

手動寫作

在RAC中， Signal / SignalProducer是只讀實體，它們不能從外部管理，RxSwift中的Observable也是如此。 要將Signal / SignalProducer轉換為可寫實體，必須使用pipe()函數返回手動控制的項目。 在Rx空間中，這是一個名為Subject的不同類型。

如果讀/寫概念聽起來不熟悉，可以與Future / Promise進行很好的類比。 Future是一個只讀占位符，如Signal / SignalProducer和Observable ，另一方面， Promise可以手動完成，比如pipe()和Subject 。

調度程序

這個實體在兩個世界中都是相似的，相同的概念，但RAC只是串行的，而RxSwift也是並發調度器。

組成

組合是反應式編程的關鍵特性。 組合流是兩個框架的本質，在RxSwift中它們也稱為序列 。

RxSwift中的所有可觀察實體都是ObservableType類型，因此我們使用相同的運算符組合Subject和Observable實例，而不需要任何額外的關注。

在RAC領域， Signal和SignalProducer是兩個不同的實體，我們必須lift SignalProducer才能組合Signal實例產生的內容。 這兩個實體有自己的操作符，所以當你需要混合時，你必須確保某個操作符可用，另一方面你忘記了熱/冷可觀察量。

關於這一部分， Colin Eberhardt很好地總結了這一點：

查看當前的API，信號操作主要關注“下一個”事件，允許您在不同的線程上轉換值，跳過，延遲，組合和觀察。 而信號生成器API主要關注信號生命周期事件（已完成，錯誤），其中包括flatMap，takeUntil和catch等操作。

額外

RAC還有Action和Property的概念，前者是一種計算副作用的類型，主要與用戶交互有關，后者在觀察值以改變值時執行任務時很有意義。 在RxSwift中， Action再次轉換為Observable ，這在RxCocoa很好地展示， RxCocoa是iOS和Mac的Rx原語的集成。 RAC的Property可以在RxSwift中轉換為Variable （或BehaviourSubject ）。

重要的是要理解Property / Variable是我們必須將命令式世界與反應式編程的聲明性本質聯系起來的方式，因此有時在處理第三方庫或iOS / Mac空間的核心功能時是一個基本組件。

結論

RAC和RxSwift是兩個完全不同的野獸，前者在Cocoa領域有很長的歷史和很多貢獻者，后者相當年輕，但依賴於已被證明在Java，JS或其他語言中有效的概念。凈。 關於哪個更好的決定取決於偏好。 RAC指出熱/冷可觀察的分離是必要的，這是該框架的核心特征，RxSwift說它們的統一優於分離，再次只是關於如何管理/執行副作用。

RAC 3.0似乎已經介紹的分離熱/冷可觀，像中斷2個實體之間的概念，拆分運營商和引進像一些必要的行為的主要目標頂部一些意想不到的復雜性start ，開始產生信號。 對於某些人來說，這些東西可能是一件好事，甚至是一個殺手級的功能，對於其他人來說，這些東西可能只是不必要甚至是危險的。 另一件需要記住的事情是RAC試圖盡可能地遵守Cocoa約定，所以如果你是一個經驗豐富的Cocoa Dev，你應該感覺更舒服，而不是RxSwift。

另一方面，RxSwift存在所有缺點，如熱/冷可觀測量，但也有反應性擴展的好處。 從RxJS，RxJava或Rx.Net遷移到RxSwift是一件簡單的事情，所有概念都是相同的，所以這使得查找材料非常有趣，可能是您現在面臨的同樣問題，已經被RxJava中的某個人解決了可以考慮平台重新應用。

必須選擇哪一個肯定是一個偏好的問題，從客觀的角度來看，不可能分辨哪一個更好。 唯一的方法是解雇Xcode並試用它們並選擇一個感覺更舒適的工作。 它們是類似概念的兩種實現，試圖實現相同的目標：簡化軟件開發。