Це дуже гарне запитання. Порівнювати два світи дуже важко. Rx - порт того, що реактивні розширення є іншими мовами, такими як C #, Java або JS.
Реактивне какао було натхнене функціональним реактивним програмуванням , але в останні місяці також наголошувалося як натхнене реактивним розширенням . Результат - це структура, яка ділиться деякими речами з Rx, але має назви з походженням в FRP.
Перше, що потрібно сказати, це те, що ні RAC, ні RxSwift не є реалізаціями функціонального реактивного програмування , згідно з визначенням концепції Кональ . З цього моменту все можна звести до того, як кожен фреймворк обробляє побічні ефекти та кілька інших компонентів.
Давайте поговоримо про спільноту та мета-тек :
- RAC - 3-річний проект, який народився в Objective-C, пізніше перенесений на Swift (з мостами) для випуску 3.0, після повного відмови від поточної роботи над Objective-C.
- RxSwift - це проект, що триває кілька місяців, і, схоже, зараз він має силу в громаді. Одне, що важливо для RxSwift, - це те, що він знаходиться під організацією ReactiveX і що всі інші реалізації працюють однаково, навчитися працювати з RxSwift зробить роботу з Rx.Net, RxJava або RxJS простою задачею і просто питанням синтаксису мови. Я можу сказати, що заснована на філософії вчитися один раз, застосовувати всюди .
Зараз час для технічних речей.
Виробництво / спостереження за особами
RAC 3.0 має 2 основних об'єкти, Signalі SignalProducer, перший публікує події незалежно від того, підписаний або не підписався, другий вимагає, startщоб насправді вироблялися сигнали / події. Ця конструкція була створена, щоб відокремити виснажливу концепцію гарячого та холодного спостереження, що стало причиною плутанини у багатьох розробників. Ось чому відмінності можна звести до того, як вони управляють побічними ефектами .
У RxSwift Signalі в SignalProducerперекладі Observableце може здатися заплутаним, але ці 2 сутності насправді те саме, що в світі Rx. Дизайн з Observables в RxSwift повинен бути створений, враховуючи, чи вони гарячі чи холодні, це може здатися зайвою складністю, але як тільки ви зрозуміли, як вони працюють (і знову жарко / холодно / тепло - це лише побічні ефекти під час підписки / спостереження ) їх можна приручити.
В обох світах концепція підписки в основному однакова, є одна невелика різниця, яку запровадив RAC, і це interruptionподія, коли Signalанульовано до того, як подія завершення буде надіслана. Для повторного підключення обох мають такі події:
Next, для обчислення нового отриманого значенняError, щоб обчислити помилку та завершити потік, скасувавши підписку всіх спостерігачівComplete, щоб відзначити потік як закінчений, підписуючи всіх спостерігачів
Окрім того, RAC interruptedнадсилається, коли Signalвибудовується, перед тим як заповнити його правильно або з помилкою.
Написання вручну
У RAC Signal/ / SignalProducerє Observableсуто лише для читання, ними не можна керувати ззовні, те ж саме є у RxSwift. Щоб перетворити а Signal/ SignalProducerв об'єкт, який може бути записаний, вам потрібно використовувати pipe()функцію для повернення елемента, керованого вручну. На просторі Rx це інший тип, який називається Subject.
Якщо концепція читання / запису звучить незнайомо, можна зробити приємну аналогію з Future/ Promise. A Future- заповнювач місця, доступний лише для читання, як Signal/ SignalProducerі Observable, з іншого боку, aPromise може бути виконаний вручну, як pipe()і для Subject.
Планувальники
Ця сутність дуже схожа в обох світах, однакових концепцій, але RAC є лише серійним, натомість RxSwift має також паралельні планувальники.
Склад
Склад є ключовою особливістю реактивного програмування. Складання потоків - це суть обох фреймворків, в RxSwift їх ще називають послідовностями .
Усі спостережувані об'єкти в RxSwift мають тип ObservableType, тому ми створюємо екземпляри SubjectтаObservable з тими ж операторами без зайвих проблем.
На RAC просторі, Signalі SignalProducer2 різні сутності , і ми повинні liftна , SignalProducerщоб мати можливість створювати те , що виробляється з екземплярамиSignal . У двох об'єктів є свої оператори, тож коли вам потрібно змішати речі, ви повинні переконатися, що певний оператор доступний, а з іншого боку ви забудете про спостереження гарячого / холодного.
Про цю частину Колін Еберхардт добре підсумував це:
Дивлячись на поточний API, сигнальні операції в основному зосереджені на події "наступний", що дозволяє трансформувати значення, пропускати, затримувати, комбінувати та спостерігати в різних потоках. В той час, як API виробника сигналу в основному стосується подій життєвого циклу сигналу (завершено, помилка), з операціями, включаючи тоді, flatMap, takeUntil та catch.
Додатково
RAC має також поняття Actionі Propertyколишній тип з обчислювальними побічними ефектами, головним чином в зв'язку з взаємодією користувача, останній цікаво, спостерігаючи значення для виконання завдання , коли значення змінилося. У RxSwift Actionперекладені знову перетворюються на Observable, це добре показано в RxCocoaінтеграції Rx примітивів як для iOS, так і для Mac. RAC Propertyможна перекласти на Variable(або BehaviourSubject) в RxSwift.
Важливо розуміти, що Property/ Variableце спосіб, яким ми маємо передати імперативний світ до декларативного характеру Реактивного програмування, тому іноді є основним компонентом при роботі з сторонніми бібліотеками або основними функціоналами простору iOS / Mac.
Висновок
RAC та RxSwift - це 2 повні різні звірі, перший має довгу історію в просторі какао і багато учасників, другий досить молодий, але покладається на концепції, які довели свою ефективність в інших мовах, таких як Java, JS або .NET. Рішення про те, що краще, - на перевагу. RAC стверджує, що відокремлення гарячого / холодного спостереження було необхідним, і це є основною особливістю рамки, RxSwift каже, що об'єднання їх краще, ніж розділення, знову ж таки мова йде про те, як керуються / виконуються побічні ефекти.
RAC 3.0, здається, вніс деяку несподівану складність на додаток до головної мети поділу спостережуваних "гарячих / холодних", як, наприклад, концепція переривання, розділення операторів між двома об'єктами та введення деякої імперативної поведінки, як startпочати виробляти сигнали. Для деяких людей це може бути приємною річчю або навіть вбивчою рисою, для деяких інших вони можуть бути просто непотрібними або навіть небезпечними. Інша річ, яку потрібно пам’ятати, - це те, що RAC намагається якомога більше дотримуватися конвенцій про какао, тож якщо ви досвідчений розробник какао, вам слід комфортніше працювати з ним, а не з RxSwift.
RxSwift, з іншого боку, живе зі всіма недоліками, як спостереження гарячого / холодного, але і хорошого, що реагують на розширення. Перехід від RxJS, RxJava або Rx.Net до RxSwift - це проста річ, всі концепції однакові, тому це робить пошук матеріалу досить цікавим, можливо, та сама проблема, з якою ви стикаєтесь зараз, вирішила хтось із RxJava та рішення може бути застосований повторно з урахуванням платформи.
Те, кого потрібно вибрати, - це, безумовно, питання переваги, з об’єктивної точки зору неможливо сказати, який із них кращий. Єдиний спосіб - запустити Xcode і спробувати обидва, і вибрати той, з яким вам зручніше працювати. Вони є двома реалізаціями подібних концепцій, намагаючись досягти тієї ж мети: спрощення розробки програмного забезпечення.