Bu çok iyi bir soru. İki dünyayı karşılaştırmak çok zor. Rx, C #, Java veya JS gibi diğer dillerde Reaktif Uzantıların bulunduğu bir bağlantı noktasıdır.
Reaktif Kakao, Fonksiyonel Reaktif Programlama'dan esinlenmiştir , ancak son aylarda Reaktif Uzantılardan da ilham aldığı belirtilmiştir . Sonuç, bazı şeyleri Rx ile paylaşan, ancak FRP'de kökenleri olan bir çerçevedir.
İlk söylenecek şey, Conal'ın kavram tanımına göre ne RAC ne de RxSwift'in Fonksiyonel Reaktif Programlama uygulamaları olmadığıdır . Bu noktadan itibaren her şey, her bir çerçevenin yan etkileri ve diğer birkaç bileşeni nasıl ele alacağına indirgenebilir.
Topluluk ve meta-teknoloji konuları hakkında konuşalım :
- RAC, Objective-C'de doğan ve Objective-C üzerinde devam eden çalışmaları tamamen bıraktıktan sonra 3.0 sürümü için Swift'e (köprülerle) taşınan 3 yıllık bir projedir.
- RxSwift birkaç aylık bir proje ve şu anda toplumda bir ivme var gibi görünüyor. RxSwift için önemli olan bir şey, ReactiveX organizasyonu altında olması ve diğer tüm uygulamaların aynı şekilde çalışmasıdır, RxSwift ile nasıl başa çıkılacağını öğrenmek Rx.Net, RxJava veya RxJS ile çalışmayı basit bir görev ve sadece bir konu haline getirecektir dil sözdizimi. Bunun bir kez öğrenmek, her yere uygulamak felsefesine dayalı olduğunu söyleyebilirim .
Şimdi teknoloji işleri zamanı.
Varlıkları Üretme / Gözlemleme
RAC 3.0'ın 2 ana varlığı vardır Signalve SignalProducerbirincisi bir abonenin bağlı olup olmadığına bakılmaksızın olayları yayınlar, ikincisi startise gerçekten sinyaller / olayların üretilmesini gerektirir. Bu tasarım, birçok geliştirici için karışıklık kaynağı olan sıkıcı sıcak ve soğuk gözlemlenebilir konseptini ayırmak için yaratılmıştır. Bu nedenle farklılıklar yan etkileri nasıl yönettiklerine indirgenebilir .
RxSwift olarak, Signalve SignalProducerçevirir Observable, bu kafa karıştırıcı ses olabilir, ama bunlar 2 kişiler aslında Rx dünyada aynı şeyler. ObservableRxSwift'te s olan bir tasarım , sıcak veya soğuk olup olmadıklarını düşünerek oluşturulmalıdır, gereksiz karmaşıklık gibi gelebilir, ancak nasıl çalıştıklarını anladıktan sonra (ve tekrar sıcak / soğuk / sıcak, abone olurken / gözlemlerken yan etkilerle ilgilidir) ) evcilleştirilebilir.
Her iki dünyalarda, abonelik kavramı RAC tanıtıldı ve olduğunu küçük bir fark var, temelde aynı olan interruptionbir olay Signaltamamlama olayı gönderilmeden önce bertaraf edilir. Her ikisini de özetlemek gerekirse aşağıdaki türden olaylar var:
Next, yeni alınan değeri hesaplamak içinError, bir hata hesaplamak ve akışı tamamlamak, tüm gözlemcileri iptal etmek içinComplete, akışı tüm gözlemcileri abonelikten çıkmadan tamamlandı olarak işaretlemek için
Ek olarak RAC, interrupteda Signaldoğru bir şekilde veya bir hata ile tamamlanmadan a atılırken gönderilir .
Elle Yazma
RAC'de, Signal/ SignalProducersalt okunur varlıklar, dışarıdan yönetilemezler, ObservableRxSwift için de aynı şey geçerlidir. Bir açmak için Signal/ SignalProducerbir yazma seçebilir, varlık içinde kullanmak zorunda pipe()elle kontrol edilen öğeyi döndürmek için işlev. Rx uzayında, bu denilen farklı bir türdür Subject.
Okuma / yazma kavramı alışılmadık geliyorsa, güzel bir benzetme Future/ ' Promiseyapılabilir. A Future, Signal/ gibi salt okunur bir yer tutucudur SignalProducerve Observablediğer yandan a ve Promiseiçin manuel olarak gerçekleştirilebilir .pipe()Subject
Schedulers
Bu varlık her iki dünyada da benzer kavramlara benzer, ancak RAC yalnızca seri olarak kullanılır, bunun yerine RxSwift aynı zamanda eşzamanlı zamanlayıcılara sahiptir.
Kompozisyon
Kompozisyon, Reaktif Programlamanın temel özelliğidir. Akarsu oluşturmak her iki çerçevenin de özüdür, RxSwift'te bunlara sekanslar da denir .
RxSwift'teki tüm gözlemlenebilir varlıklar türdedir ObservableType, bu nedenle herhangi bir ek endişe duymadan aynı işleçlerin örneklerini Subjectve Observableaynı işleçleri oluştururuz.
RAC alanı üzerinde Signalve SignalProducer2 farklı varlıklardır ve sahip olduğumuz liftüzerindeki SignalProducerörnekleri ile üretilen şeyin oluşturmak mümkün Signal. İki varlığın kendi operatörleri vardır, bu yüzden bir şeyleri karıştırmanız gerektiğinde, belirli bir operatörün kullanılabilir olduğundan emin olmalısınız, diğer tarafta sıcak / soğuk gözlemlenebilirleri unutursunuz.
Bu bölüm hakkında, Colin Eberhardt güzelce özetledi:
Mevcut API'ya bakıldığında, sinyal işlemleri esas olarak değerleri dönüştürmenize, atlamanıza, gecikmenize, farklı iş parçacıklarını birleştirmenize ve gözlemlemenize olanak tanıyan 'sonraki' olaya odaklanır. Sinyal üreticisi API'sı çoğunlukla sinyal yaşam döngüsü olaylarıyla (tamamlandı, hata) ilgiliyken, flatMap, takeUntil ve catch gibi işlemlerle ilgilidir.
Ekstra
RAC ayrıca bir kavramdır Actionve Propertybirincisi, esas olarak kullanıcı etkileşimi ile ilgili yan etkileri hesaplamak için bir türdür; ikincisi, değer değiştiğinde bir görevi yerine getirmek için bir değeri gözlemlerken ilginçtir. RxSwift'te Actiontekrar çevirileri bire Observable, bu güzel bir şekilde gösteriliyor RxCocoa, hem iOS hem de Mac için Rx ilkellerinin bir entegrasyonu. RAC en Propertytercüme edilebilir Variable(veya BehaviourSubjectRxSwift cinsinden).
O anlamak önemlidir Property/ Variableüçüncü parti kütüphaneleri veya iOS / Mac uzay temel işlevlerine ile uğraşırken biz, Reaktif Programlama bildirim doğaya zorunlu dünyayı köprü zorunda yolu bazen temel bir bileşenidir olduğunu.
Sonuç
RAC ve RxSwift, 2 tam farklı hayvan, birincisi Kakao alanında uzun bir geçmişe ve çok sayıda katılımcıya sahip, ikincisi oldukça genç, ancak Java, JS veya diğer dillerde etkili olduğu kanıtlanmış kavramlara dayanıyor .AĞ. Hangisinin daha iyi olduğuna karar vermek tercih edilir. RAC, sıcak / soğuk gözlemlenebilir ayrılmanın gerekli olduğunu ve çerçevenin temel özelliği olduğunu belirtir, RxSwift bunların birleştirilmesinin ayırmadan daha iyi olduğunu söyler, yine yan etkilerin nasıl yönetildiği / gerçekleştirildiği ile ilgilidir.
RAC 3.0, sıcak / soğuk gözlemlenebilirleri ayırma, operatörleri 2 birim arasında bölme ve startsinyal üretmeye başlamak gibi bazı zorunlu davranışlar gibi sıcak / soğuk gözlemlenebilirleri ayırma ana hedefi üzerine beklenmedik bir karmaşıklık getirmiş gibi görünüyor . Bazı insanlar için bu şeyler sahip olmak güzel bir şey olabilir, hatta katil bir özellik olabilir, bazıları için sadece gereksiz veya hatta tehlikeli olabilirler. Hatırlanması gereken bir başka şey de, RAC'ın Kakao sözleşmelerine olabildiğince uymaya çalıştığıdır , bu yüzden deneyimli bir Cocoa Dev iseniz , RxSwift yerine onunla çalışmak daha rahat hissetmelisiniz.
Öte yandan RxSwift, sıcak / soğuk gözlemlenebilirler gibi tüm olumsuz taraflarla, aynı zamanda Reaktif Uzantıların iyi şeyleriyle yaşar. RxJS, RxJava veya Rx.Net'ten RxSwift'e geçmek basit bir şeydir, tüm kavramlar aynıdır, bu yüzden malzeme bulmayı oldukça ilginç hale getirir, belki de şu anda karşılaştığınız aynı sorun, RxJava'daki bir kişi tarafından çözülmüştür ve çözüm platform dikkate alınarak yeniden uygulanabilir.
Hangisinin seçilmesi kesinlikle bir tercih meselesidir, nesnel bakış açısından hangisinin daha iyi olduğunu söylemek imkansızdır. Tek yol Xcode'u ateşleyip her ikisini de denemek ve çalışmak için daha rahat hisseden birini seçmek. Aynı hedefe ulaşmaya çalışan benzer kavramların 2 uygulamasıdır: yazılım geliştirmeyi basitleştirme.