이것은 매우 좋은 질문입니다. 두 세계를 비교하는 것은 매우 어렵습니다. Rx는 Reactive Extensions가 C #, Java 또는 JS와 같은 다른 언어로 된 포트입니다.
Reactive Cocoa는 Functional Reactive Programming 에서 영감을 받았지만 지난 몇 개월 동안 Reactive Extensions 에서도 영감을 받았습니다 . 결과는 Rx와 일부 정보를 공유하지만 FRP에서 유래 한 이름을 가진 프레임 워크입니다.
가장 먼저 할 말은 개념 의 Conal 정의 에 따라 RAC와 RxSwift가 Functional Reactive Programming 구현 이 아니라는 것 입니다. 이 시점부터 모든 프레임 워크가 부작용과 몇 가지 다른 구성 요소를 처리하는 방식으로 모든 것을 줄일 수 있습니다.
커뮤니티와 메타 기술 에 대해 이야기 해 봅시다 .
- RAC는 Objective-C에서 진행중인 작업을 완전히 중단 한 후 3.0 릴리스 용 Swift (브리지 포함)로 이식 된 Objective-C에서 태어난 3 년 된 프로젝트입니다.
- RxSwift는 몇 달 전의 프로젝트이며 현재 커뮤니티에서 추진력이있는 것 같습니다. RxSwift에서 중요한 한 가지는 ReactiveX 조직 아래에 있으며 다른 모든 구현은 동일한 방식으로 작동한다는 것입니다. RxSwift를 처리하는 방법을 배우면 Rx.Net, RxJava 또는 RxJS를 사용하는 것이 간단한 작업이자 문제입니다. 언어 구문 나는 그것이 한 번만 배운 철학에 근거한다고 말할 수 있고 , 어디에나 적용 할 수 있습니다 .
이제 기술적 인 시간이다.
엔티티 생성 / 관찰
RAC 3.0 2 개 주 요소를 가지며, Signal그리고 SignalProducer, 첫 번째 이벤트가없이 가입자가 장착되지 않았거나 출판, 두번째는 필요한 start실제로 제조 신호 / 이벤트를 갖는 것. 이 디자인은 많은 개발자들에게 혼란의 원인이 된 지루한 뜨겁고 차가운 관측 가능 개념을 분리하기 위해 만들어졌습니다. 이것이 차이점을 부작용 관리 방법으로 줄일 수있는 이유 입니다.
RxSwift에서, Signal그리고 SignalProducer로 변환 Observable, 그것은 혼란 소리 수 있지만,이 두 기관은 실제로 수신 세계에서 같은 일이다. ObservableRxSwift에서 s를 사용 하는 디자인 은 뜨겁거나 차갑지 않은지를 고려하여 생성해야합니다. 불필요한 복잡한 것처럼 들릴 수 있지만 일단 작동 방식을 이해하면 가입 및 관찰 중에 뜨거운 / 차가운 / 따뜻한 부작용이 발생합니다. ) 길들일 수 있습니다.
두 세계에서 구독 개념은 기본적으로 동일하며, RAC가 도입 한 것과는 약간의 차이가 있으며 완료 이벤트가 전송되기 전에 interruptiona Signal가 폐기 될 때 의 이벤트 입니다. 두 가지 모두를 요약하면 다음과 같은 종류의 이벤트가 있습니다.
Next, 새로운 수신 값을 계산하기 위해Error, 모든 관찰자를 구독 취소하여 오류를 계산하고 스트림을 완료합니다.Complete모든 관찰자를 구독 취소하여 스트림을 완료된 것으로 표시
또한 RAC는 올바르게 완료되거나 오류가 발생하기 전에 interrupteda Signal가 폐기 될 때 전송됩니다 .
수동 작성
RAC에서 Signal/ SignalProducer는 읽기 전용 엔터티이며 외부에서 관리 할 수 없으며 ObservableRxSwift 와 동일 합니다. Signal/ SignalProducer를 쓰기 가능한 엔터티로 바꾸려면 이 pipe()기능을 사용하여 수동으로 제어되는 항목을 반환해야합니다. Rx 공간에서 이것은 다른 유형 Subject입니다.
읽기 / 쓰기 개념이 생소하게 들리면 Future/ 와의 훌륭한 비유가 Promise가능합니다. A는 Future같은 읽기 전용 자리 표시 자입니다 Signal/ SignalProducer그리고 Observable다른 한편으로는, Promise대한처럼 수동으로 성취 될 수있다 pipe()및 Subject.
스케줄러
이 엔터티는 동일한 개념으로 두 세계에서 거의 비슷하지만 RAC는 직렬 전용이며 RxSwift 기능은 동시 스케줄러도 있습니다.
구성
컴포지션은 리 액티브 프로그래밍의 핵심 기능입니다. 스트림 구성은 두 프레임 워크의 본질이며 RxSwift에서는 시퀀스 라고도 합니다 .
RxSwift의 모든 관찰 엔티티 유형입니다 ObservableType우리의 인스턴스 구성 있도록, Subject그리고 Observable여분의 걱정없이, 같은 연산자를.
RAC 공간에, Signal그리고 SignalProducer2 개의 다른 엔티티이며에 우리는이 lift에 SignalProducer의 인스턴스 생성되는 것을 구성 할 수 있도록 Signal. 두 엔터티에는 자체 연산자가 있으므로 혼합해야 할 경우 특정 연산자를 사용할 수 있는지 확인해야하며 다른 쪽에서는 고온 / 감기 관측 가능 항목을 잊어 버리십시오.
이 부분에 대해 Colin Eberhardt는 다음과 같이 훌륭하게 요약했습니다.
현재 API를 살펴보면 신호 작업은 주로 '다음'이벤트에 중점을 두어 다른 스레드에서 값을 변환, 건너 뛰기, 지연, 결합 및 관찰 할 수 있습니다. 신호 생성기 API는 대부분 flatMap, takeUntil 및 catch와 같은 작업을 통해 신호 수명주기 이벤트 (완료, 오류)와 관련이 있습니다.
특별한
RAC도의 개념을 갖는다 Action및 Property값이 변경되면 태스크를 수행하기 위해 값을 관찰 할 때, 후자는 흥미, 전자는 주로 사용자 상호 작용과 관련된, 컴퓨팅 부작용 유형이다. RxSwift에서는 Action로 다시 번역되며 Observable, 이는 RxCocoaiOS와 Mac 용 Rx 프리미티브의 통합에 잘 나와 있습니다. RAC 는 RxSwift에서 (또는 ) Property으로 번역 될 수 있습니다 .VariableBehaviourSubject
Property/ Variable가 우리가 명령형 세계를 반응성 프로그래밍의 선언적 특성에 연결해야하는 방식 이라는 것을 이해하는 것이 중요 하므로, 때로는 타사 라이브러리 또는 iOS / Mac 공간의 핵심 기능을 다룰 때 기본 구성 요소가됩니다.
결론
RAC와 RxSwift는 완전히 다른 2 마리의 짐승입니다. 전자는 코코아 공간에서 오랜 역사를 가지고 있으며 많은 공헌자 들이며, 후자는 상당히 어리지만 Java, JS 또는 .그물. 더 나은 결정은 선호에 있습니다. RAC는 핫 / 콜드 관측 가능 분리가 필수적이며 이것이 프레임 워크의 핵심 기능이라고 말합니다 .RxSwift는 통합이 분리보다 낫다고 다시 말하지만 부작용은 어떻게 관리 / 수행되는지에 관한 것입니다.
RAC 3.0은 중단 개념, 두 개체간에 연산자 분리 및 start신호 생성을 시작하는 것과 같은 일부 필수 동작을 도입하는 등 핫 / 콜드 관측 가능 항목 분리라는 주요 목표 위에 예기치 않은 복잡성을 야기한 것으로 보입니다 . 어떤 사람들에게는 이런 것들이 좋거나 살인자 기능 일 수도 있고, 어떤 사람들에게는 불필요하거나 위험 할 수도 있습니다. 기억해야 할 또 다른 점은 RAC는 경험이 풍부한 코코아 데브이다 만약 그렇다면, 당신은 가능한 한 코코아 규칙을 유지하기 위해 노력하고있다 한다 그것보다는 RxSwift와 작업에 더 편안한 느낌.
반면 RxSwift는 핫 / 콜드 옵저버 블과 같은 모든 단점뿐만 아니라 Reactive Extensions의 장점도 있습니다. RxJS, RxJava 또는 Rx.Net에서 RxSwift로 이동하는 것은 간단한 것입니다. 모든 개념은 동일하므로 재료를 찾는 것이 매우 흥미로울 수 있습니다. 현재 직면하고있는 동일한 문제 일 수도 있습니다 .RxJava 및 솔루션의 누군가가 해결했습니다. 플랫폼을 고려하여 다시 적용 할 수 있습니다.
어느 것을 선택해야하는지는 분명한 선호의 문제이며, 객관적인 관점에서 어느 것이 더 나은지 알 수는 없습니다. 유일한 방법은 Xcode를 실행하고 두 가지 모두를 시도하고 작업하기가 더 편한 것을 선택하는 것입니다. 소프트웨어 개발 단순화라는 동일한 목표를 달성하려는 두 가지 유사한 개념을 구현 한 것입니다.