Skip to content

Latest commit

 

History

History
392 lines (267 loc) · 26.1 KB

6.md

File metadata and controls

392 lines (267 loc) · 26.1 KB

이 글은 ReactiveCocoa vs RxSwift(https://www.raywenderlich.com/126522/reactivecocoa-vs-rxswift)에 대한 번역입니다.
(번역 허락을 받은 것은 아니지만, 도움이 필요하신 분들을 위해서 올려봅니다. 문제가 될 경우 바로 삭제하겠습니다. ㅡㅜ)

ReactiveCocoa vs RxSwift

Functional Reactive Programming 은 Swift 개발자들 사이에서 인기가 높아지고 있는 프로그래밍 방법론입니다. Functional Reactive Programming 은 복잡한 비동기 코드를 작성하기 쉽고, 이해하기 쉽게 만듭니다.

이 글에서는, Functional Reactive Programming 에 대한 가장 있기 있는 두가지 라이브러리를 비교할 겁니다.:RxSwift vs ReactiveCocoa.

Functional Reactive Programming 이 무엇인지에 대한 간략한 리뷰로 부터 시작할 겁니다. 그리고 그런 다음 두 framework를 자세히 비교해볼 겁니다. 끝날 무렵에는, 어떤 framework이 여러분에게 적합할지 결정할 수 있을 겁니다.

Reactive를 알아 봅시다!

Functional Reactive Programming은 무엇일까요?

주의: Functional Reactive Programming의 개념과 이미 친숙하다면, "ReactiveCocoa vs RxSwift" 섹션으로 넘어가세요.

심지어 Swift가 발표되기 이전부터, Objective Oriented Programming 에 대비하여 Functional Reactive Programming(FRP) 은 수년동안 엄청난 인기 상승을 보여왔습니다. Haskell 에서 Javascript에 이르기까지, FRP에 영감을 받은 구현체들을 찾을 수 있을 겁니다. 왜 이럴까요? FRP에서 뭐가 그렇게 특별할까요? 아마도 가장 중요한 것은 Swift에서 어떻게 이 패러다임을 적용할 수 있을까?일 겁니다.

Functional Reactive Programming은 Conal Elliott( https://twitter.com/conal )에 의해서 창안된 programming 패러다임입니다. 그의 정의에는 매우 구체적인 문법이 있습니다. 그리고 여기( https://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming ) 에서 그것을 살펴보는 것을 환영합니다. 더 느슨하고 간단한 정의로서 Functional Reactive Programming 은 두가지 개념의 조합입니다.:

1.Reactive Programming: Reactive Programming 은 비동기 data stream들에 집중합니다. 그리고 listen 할 수 있고 그에 따라 반응(react)할 수 있습니다. 더 많이 것을 배우기 위해서, 이 훌륭한 소개( https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 )를 확인해 보세요.

2.Functional Programming: Functional Programming은 수학 스타일 함수들을 통한 계산, 불변성(immutable)그리고 표현성을 강조합니다. 그리고 변수들과 상태의 사용을 최소화합니다. 더 많이 배우기 위해서, Swift Functional programming 튜터리얼( https://www.raywenderlich.com/82599/swift-functional-programming-tutorial )을 확인해세요.

주의: André Staltz( https://twitter.com/andrestaltz )는 그의 글 "FRP를 이야기할 수는 없지만 단지 FRP를 했던 이유"( https://medium.com/@andrestaltz/why-i-cannot-say-frp-but-i-just-did-d5ffaa23973b#.62dnhk32p )에서 본래 FRP 공식과 실용적인 접근사이의 차이점을 경험을 탐험합니다.

간단한 예제

Functional Reactive Programming를 가장 쉽게 이해하는 방법은 예제를 통하는 것입니다. 사용자의 위치를 추적하여 그녀가 커피숍 근처에 있을 때 알려주는 앱을 생각해 봅시다.

만약 여러분이 FRP 방식으로 이 앱을 프로그래밍했다면,

  1. 여러분이 반응(react)할 위치 이벤트의 stream을 발생시키는(emit) 객체를 생성할 겁니다.

  2. 그런 다음 커피숍 가까이에 있는 위치 이벤트들만 보기 위해서 발생한(emitted) 위치 이벤트들을 거를 겁니다.

여기 ReactiveCocoa 코드가 있습니다.

locationProducer // 1
  .filter(ifLocationNearCoffeeShops) // 2
  .startWithNext {[weak self] location in // 3
    self?.alertUser(location)
  }

섹션 별로 이걸 살펴봅시다. 1.locationProducer는 위치가 변경될 때마다 이벤트를 발생시킵니다(emit). ReactiveCocoa에서는 "signal"이라고 불리고 그리고 RxSwift 에서는 "sequence"라고 불린다는 것을 알아두세요.

2.그런 다음 위치 변경에 응답하기 위해서 Functional Programming 기술들을 사용합니다. filter 메소드는 ifLocationNearCoffeeShops 함수을 실행합니다. filter메소드는 ifLocationNearCoffeeShops 에 배열의 개별 값들을 (파라미터로) 넘겨줍니다. 만약 함수가 true를 리턴하면, 그 이벤트는 다음 단계에 처리되는 것이 허용됩니다.

3.마지막으로 startWithNext는 이 (filter된) signal에 구독(subscription)을 형성합니다. 이벤트가 도착할 때마다 실행될 클로저 표현 코드와 함께 구독을 형성합니다.

위의 코드는 값의 배열을 변형할때 사용되는 코드와 유사합니다. 그러나 명확한 점은 코드가 비동기로 실행된다는 점입니다. filter 함수와 클로저 표현은 위치 이벤트가 발생하면 '요구가 있는 즉시'('on demand'로) 호출됩니다.

문법은 조금 이상하게 느껴질 수도 있습니다. 하지만 다행히도 이 코드의 의도는 명확합니다. 그것이 functional programming의 아름다움입니다. 그리고 그것이 'values on time' 전체 개념과 잘 어울리는 입니다.: 선언적(declarative)입니다. 어떻게 이루어졌는지의 상세함 대신에 무엇이 발생하고 있는지 보여 줍니다.

주의: ReactiveCocoa 문법에 대해서 더 배우기를 원하다면, 깃헙에( https://github.com/RuiAAPeres/RACNest ) 제가 만든 몇개의 예제를 살펴보세요.

이벤트 변형하기

위치 예제에서, stream을 관찰하기 시작했고, 커피숍 근처에 있는 위치들만 걸러내는 것을 빼고는 별 다른 것을 하지 않았습니다.

FRP 패러다임의 또 다른 기초 퍼즐은 이런 이벤트들을 합치고, 의미있는 어떤 것으로 변형시키는 변형시키는 기능입니다. 이것을 위해서, 고계 함수(higher order function - 다른 함수를 파라미터로 받거나 출력으로 전달하는 함수)들을 사용합니다.

기대하다시피, Swift functional programming 튜터리얼( https://www.raywenderlich.com/82599/swift-functional-programming-tutorial ) 에서 용의자들(map, filter, reduce, combine 그리고 zip)을 찾을 수 있을 겁니다.

반복되는 위치를 건너뛰고, 들어오는 위치(CLLocation)를 사용자 친화적인 메시지로 변형되도록 위치 예제를 수정합시다.

locationProducer
  .skipRepeats() // 1
  .filter(ifLocationNearCoffeeShops)
  .map(toHumanReadableLocation) // 2
  .startWithNext {[weak self] readableLocation in
    self?.alertUser(readableLocation)
  }

여기에서 추가된 새로운 두중을 봅시다.

1.첫 단계로 locationProducer signal 에서 발생한 이벤트들에 대해 skipRepeats 연산을 적용합니다. 출력 배열이 입력 배열에 비례하지 않는 연산입니다.:이것은 ReactiveCocoa 특화된 함수입니다. 그것이 수행하는 기능은 꽤 명확합니다. 중복된 이벤트들(equality에 기반해서)이 걸려집니다.

2.filter 함수가 실행된 이후에, 이벤트 데이터를 다른 타입으로 변환시키기 위해서 map 이 사용됩니다.(아마도 CLLocation 에서 String 으로)

이제 FRP의 이점들이 보이기 시작해야 합니다.

*간단하지만, 강력합니다.

*코드를 더 이해하기 쉽게 만드는 선언적인 접근입니다.

*복잡한 흐름이 관리하고 표현하기 쉬워집니다.

ReactiveCocoa vs RxSwift

이제 FRP가 무엇이고 어떻게 여러분의 복잡한 비동기 흐름을 더 관리하기 쉽게 만들어 주는지 더 잘 이해할 수 있을 겁니다. 이제 가장 인기있는 두 FRP framework들을 살펴 봅시다. - ReactiveCocoa 와 RxSwift 그리고 하나를 선택할 이유도 살펴 봅시다.

ReactiveCocoa

ReactiveCocoa( https://github.com/ReactiveCocoa/ReactiveCocoa ) framework는 Github에서 시작되었습니다. GitHub에서 Mac client 작업을 하는 동안, 개발자들은 자신들이 애플리케이션 data-flows 를 관리하느라 고생하고 있다는 것을 발견했습니다. 그들은 마이크로소프트의 ReactiveExtension들( https://msdn.microsoft.com/en-gb/data/gg577609.aspx?f=255&MSPPError=-2147217396 )과 C#을 위한 FRP framework을 받았고, 그들 자신들의 Objective-C 구현체를 만들었습니다.

개발팀이 Objective-C로 v3.0을 작업하고 있는 동안에 Swift가 발표되었습니다. 그들은 Swift의 함수형 성격들이 ReactiveCocoa에 매우 보완적이라는 것을 알게 되었고, 그래서 (v3.0이 될)Swift 구현체에 대해서 즉시 작업하기 시작했습니다. ( ReactiveCocoa/ReactiveCocoa#1382 ) 버전 3.0 문법은 매우 함수형(deeply functional)이고, currying 과 pipe-forward ( http://blog.scottlogic.com/2015/04/24/first-look-reactive-cocoa-3.html )를 지원합니다. (currying은 여러개의 파라미터를 받는 함수를 하나의 파라미터를 받는 함수의 체인으로 만드는 것을 의미합니다. 예를 들어 add(3,4)를 add(3)(4)로 변환하는 것입니다., pipe-forward는 syntatic sugar로 값에 대한 함수 호출을 객체의 메소드 호출처럼 postfix notation을 사용해서 표시하는 것입니다. 예를 들어 f(x)는 x|>f 로 표시하고, h(g(f(x)))는 x |> f |> g |> h 로 표시합니다.)

Swift 2.0은 protocol-oriented programming을 소개했습니다. 이 protocol-oriented programming 은 의미있는 ReactiveCocoa API 변경을 초래하였습니다. 버전 4.0 릴리즈에서는 protocol extension들 덕분에 pipe-forward 연산자를 버렸습니다.

ReactiveCocoa 는 매우 인기 있는 라이브러이 입니다. 작성 시점에 깃헙에 13,000개 이상의 별을 받았습니다.

RxSwift

마이크로소프트의 ReactiveExtension들은 다른 많은 framework들에게 영감을 주었습니다. 그 framework들은 FRP 개념을 Javascript, Java, Scala 그리고 많은 언어들로 가져왔습니다. 이것을 결과적으로 ReactiveX ( http://reactivex.io/ )의 구성을 이끌었습니다. ReactiveX는 FRP 구현체의 공통 API를 만드는 그룹입니다. 이것은 다양항 framework 작성자들이 공동으로 작업할 수 있게 해줍니다. 결과로서 Scala의 RxScala와 친숙한 개발자는 상대적으로 쉽게 Java로 이전할 수 있는 RxJava를 발견할 수 있어야 합니다.

RxSwift( https://github.com/ReactiveX/RxSwift )는 상대적으로 ReactiveX에 최근에 추가되었습니다. 그리고 현재 ReactiveCocoa의 인기에 못 미칩니다.(작성 시점에 깃헙에서 약 4,000개의 별). 하지만, RxSwift가 ReactiveX의 일부라는 사실은 의심의 여지가 없이 RxSwift의 인기와 장수에 기여할 것입니다.

RxSwift와 ReactiveCocoa가 둘다 ReactiveExtension들에 공통 조상을 공유하고 있는 것을 안다면 재미있을 겁니다!

RxSwift vs. ReactiveCocoa

이제는 자세히 살펴볼 시간입니다. RxSwift 와 ReactiveCocoa는 FRP의 몇몇 관점을 다르게 다룹니다. 그런 것들 중 몇가지를 살펴 봅시다.

Hot vs. Cold Signals

네트워크 요청을 만들고, 응답을 해석하고, 유저에게 그것을 보여줄 필요가 있다고 상상해 보세요.

let requestFlow = networkRequest.flatMap(parseResponse)

requestFlow.startWithNext {[weak self] result in
  self?.showResult(result)
}

(startWithNext를 사용할 때) signal 에 구독(subscribe)할 때, 그 네트워크 요청이 초기화 될 겁니다. 여러분이 추측하시듯이, 실제로 구독(subscribe)할 때까지 얼어있는("frozen") 상태이기 때문에, 이런 signal들은 cold 라고 불립니다.

다른 한편으로 hot signal들이 있습니다. hot signal에 subscribe할 때, hot signal은 이미 시작되어 있을 것이고, 그래서 세번째 혹은 네번째 이벤트를 관찰하고(observing) 있을지도 모릅니다. 정형적인 예로 키보드를 탭하는 것이 될 겁니다. 서버 요청을 하는 것처럼 탭을 "시작" 하는 것은 실제로 이치에 맞지 않습니다.

요약해 봅시다.

  • cold signal 은 signal 에 구독(subscribe)를 할 때 시작되는 일중 하나입니다. 각각의 새로운 subscriber 가 작업을 시작합니다. requestFlow 에 3번 구독(subscribe)하는 것은 네트워크 요청을 3번하는 것을 의미합니다.

  • hot signal 은 이미 보내고 있는 이벤트일 수 있습니다. 새로운 subscriber는 새로운 signal을 시작시키지 않습니다. 보통 UI 상호작용이 hot signal들입니다.

ReactiveCocoa는 hot 과 cold signal 둘 다 제공합니다.:각각 따로, Signal<T, E> 과 SignalProducer<T, E> 그러나, RxSwift는 Observable 라고 불리는 둘다 지원하는 하나의 타입만 가집니다.

hot 과 cold signal들을 표현하는 타입이 다른 것이 문제가 될까요?

개인적으로는, 특정 상황에서 signal이 어떻게 쓰이는지 기술하는데 더 좋기 때문에, signal들을 문법적으로 구별할 있다는 것이 중요하다는 것을 알게 되었습니다. 복잡한 시스템을 다룰 때, 큰 차이가 납니다.

다른 타입을 가지고 안 가지고와는 별개로, hot 과 cold signal들을 아는 것은 매우 중요합니다. André Staltz( https://twitter.com/andrestaltz ) 가 말했던 것 처럼,

"이것 무시하나면, 나중에 엄청 후회 할 겁니다. 경고했습니다."
(“If you ignore this, it will come back and bite you brutally. You have been warned.”)

만약 hot signal을 다루고 있고, 그것이 cold signal이 된다고 가정하면, 각각의 새로운 subscriber에 대한 side effect들을 시작하게 될 겁니다. 이것은 애플리케이션에 커다란 영향을 주게 될 겁니다. 공통의 예로, 앱에 네트워크 요청을 관찰하는(observer) 3개 혹은 4개의 엔티티가 존재하게 될 겁니다. 그리고 각각의 새로운 구독(subscribe)에 대해서 다른 요청이 시작될 겁니다.

ReactiveCocoa +1 포인트!

에러 처리

에러 처리에 대해서 이야기 하기 전에, RxSwift 와 ReactiveCocoa 에서 받는 이벤트의 속성에 대해서 간략하게 요약해 봅시다. 두 framework 들에는 3가지 주된 이벤트들이 있습니다.

1.Next: 새로운 (T 타입의)값이 이벤트들의 stream에 발생될 때마다 이 이벤트는 보내집니다.

2.Completed: 이벤트들의 stream이 끝났음을 표시합니다. 이 이벤트 후에, 어떤 Next 혹은 Error도 보내지지 않습니다.

3.Error: 에러를 가리킵니다. 서버 요청 예에서, 서버 에러가 발생하면 이 이벤트가 보내질 겁니다. E 는 ErrorType 프로토콜을 가지고 수행되는 type을 나타냅니다. 이 이벤트 후에는, 어떤 Next 혹은 Completed 도 보내지지 않습니다.

ReactiveCocoa의 Signal<T, E> 와 SignalProducer<T, E>는 두개의 파라미터 타입을 가지고, 반면에 RxSwift의 Observable는 하나의 파라미터 타입을 가지는 hot 과 cold signal들에 대한 섹션에서 알았을 수도 있습니다. 두번째 타입(E)는 ErrorType 프로토콜으로 컴파일되는 타입입니다. RxSwift에서는 그 타입이 발생하고, 내부적으로 ErrorType 프로토콜로 컴파일되는 타입으로 처리 됩니다.

그래서 이 모든 것이 무엇을 의미할까요?

실용적인 관점에서, RxSwift에서 다양한 방법으로 에러가 발생할(emitted) 수 있다는 것을 의미합니다.

create { observer in
  observer.onError(NSError.init(domain: "NetworkServer", code: 1, userInfo: nil))
}

위의 코드는 signal을 생성합니다.(혹은 RxSwift 용어로는 Observable sequence) 그리고 즉시 에러를 발생시킵니다.(emit)

여기 다른 방법이 있습니다.

create { observer in
  observer.onError(MyDomainSpecificError.NetworkServer)
}

Observable 은 단지 타입이 ErrorType 프로토콜로 컴파일되어야 하는 것을 강제하기 때문에, 보내기 원하는 것을 꽤 많이 보낼 수 있습니다. 하지만 다음의 경우에는 조금 이상할 수 있습니다.

enum MyDomainSpecificError: ErrorType {
  case NetworkServer
  case Parser
  case Persistence
}

func handleError(error: MyDomainSpecificError) {
  // Show alert with the error
}

observable.subscribeError {[weak self] error in
  self?.handleError(error)
 }

이 코드는 동작하지 않을 겁니다. handleError 함수가 ErrorType 이 아니라 MyDomainSpecificError를 기대하고 있기 때문입니다. 2가지 일을 하도록 강제됩니다.

1.error를 MyDomainSpecificError으로 변환(cast) 시도.

2.error가 MyDomainSpecificError으로 변환 가능하지 않은 경우에 대해서 처리.

첫번째 것은 쉽게 as? 로서 고쳐집니다. 하지만, 두번째 것은 더 어렵습니다. 가능한 해결책은 Unknown 인 경우를 추가하는 겁니다.

enum MyDomanSpecificError: ErrorType {
  case NetworkServer
  case Parser
  case Persistence
  case Unknown
}

observable.subscribeError {[weak self] error in
  self?.handleError(error as? MyDomanSpecificError ?? .Unknown)
}

ReactiveCocoa에서는 Signal<T, E> 혹은 SignalProducer<T, E>를 생성할때 type을 수정("fix")하기 때문에, 컴파일러는 그밖에 다른 것을 보내려고 한다면 불평할 겁니다. 결론: ReactiveCocoa에서 컴파일러는 기대하는 에러 말고 다른 에러를 보내는 것을 허용하지 않을 것입니다.

ReactiveCocoa 또 1점!

UI Bindings

UIKit 같은 표준 iOS API들은 FRP 언어로 동작하지 않습니다. RxSwift 혹은 ReactiveCocoa 둘중 하나를 사용하기 위해서는 이들 API들을 bridge 해야 합니다. 예를 들어 (target-action을 이용해서 endcode 되는)탭들을 signal들 혹은 Observable들로 변환해야 합니다.

여러분이 상상할 수 있듯이, 이건 모두 많은 노력이 필요하고, RxSwift, ReactiveCocoa 둘다 독창적으로 많은 bridge들과 bindings 을 제공합니다.

ReactiveCocoa는 Objective-C의 날들로 부터 많은 것들을 가져왔습니다. Swift와 연계하여 동작하도록 bridge 되어온 이미 많이 처리된 것들(https://github.com/ReactiveCocoa/ReactiveCocoa/tree/master/ReactiveCocoa/Objective-C)을 찾을 수 있습니다. 이것들은 UI Bind들과 Swift로 변환된 다른 연산들을 포함합니다. 물론 이것은 조금 이상합니다.:(RACSignal과 같은)Swift API의 일부가 아닌 타입들을 다룹니다. 이런 것들은 사용자가 Objective-C 타입을 Swift 타입으로 변경하도록 강제합니다.(예를들어 toSignalProducer()메소드를 사용할 때)

단지 그런 것뿐만 아니라, 시간이 지남에 따라 천천히 사라지는 문서보다는 소스코드를 보는데 더 많은 시간을 소비했다고 느낍니다. 이론적인/마음의 관점으로 부터의 문서가 뛰어나긴하지만, 유용성의 관점에서는 문서가 별로 없다는 것을 알아야 합니다.

이에 대한 보상으로, 많은 ReactiveCocoa 튜터리얼을 찾을 수 있습니다.

반면에, RxSwift binding들은 사용하기 즐겁습니다! 방대한 카탈로그(https://github.com/ReactiveX/RxSwift/blob/master/Documentation/API.md)를 가지고 있을 뿐아니라, 수많은 예제(https://github.com/ReactiveX/RxSwift/blob/master/Documentation/Examples.md)도 있습니다. 게다가 더 완성된 문서(https://github.com/ReactiveX/RxSwift/tree/master/Documentation)도 있습니다. 몇몇 사람들에게 이것은 ReactiveCocoa 보다는 RxSwift를 선택할 충분한 이유가 됩니다.

RxSwift +1점!

Community

ReactiveCocoa는 RxSwift보다 훨씬 더 오래전 부터 있었습니다. 다룰 수 있는 수많은 사람들과 온라인에 많은 튜터리얼이 있습니다. 그리고 Stackoverflow에 ReactiveCocoa tag는 도움을 위한 좋은 소스입니다.

ReactiveCocoa는 Slack 그룹이 있습니다. 하지만 단지 209명의 작은 그룹입니다. 그래서 (저 스스로 혹은 다른 사람들에 의한)많은 질문들이 대답되지 않고 있습니다. 급할 때, 저는 ReactiveCocoa 핵심 멤버에게 요청합니다. 그리고 저는 다른 사람들도 그렇게 하고 있다고 가정하고 있습니다. 특정 문제를 설명하는 온라인 튜터리얼을 문서를 아마 대부분의 경우에 찾을 수 있을 겁니다.

RxSwift는 더 최신입니다. 그리고 요즘에는 거의 원맨쇼입니다.( https://github.com/ReactiveX/RxSwift/graphs/contributors ) 또한 Slack 그룹도 있습니다. 그리고 961의 멤버로 더 큽니다. 그리고 더 큰 토론 분량이 있습니다. 거기에서 질문에 도움을 줄 누군가를 찾을 수 있을 겁니다.

종합적으로, 지금 두 커뮤니티는 서로 다른 방면에서 훌륭합니다. 그래서 이 카테고리에서는 동점입니다.

여러분은 어떤 것을 선택해야 할까요?

Ash Furrow( https://twitter.com/ashfurrow )가 "Reactivecocoa vs Rxswift"( https://ashfurrow.com/blog/reactivecocoa-vs-rxswift/ ) 에서 말했던 것처럼:

들어보세요, 당신이 초보자라면, 그건 정말 문제가 아닙니다. 네, 물론 기술적인 차이점이 있을 수 있지요. 하지만 그런 차이점은 초보자에게 의미있는 것이 아닙니다.
한 framework를 시도해 보세요. 그런 다음, 다른 framework을 시도해 보세요. 어떤 것이 당신에게 적당한지 알아 보세요.
그런 다음 당신이 그 framework를 선호하는 이유를 알게 될 겁니다.

저도 똑같이 할 것을 추천합니다. 충분한 경험이 쌓이면 그들사이에 미묘한 차이를 알게될 겁니다.

하지만, 충분한 시간이 없고, 하나 골라야 할 필요가 있는 상황이라면 저의 제안은 이렇습니다.

만약 이렇다면, Reactivecocoa를 선택하세요

  • 시스템을 더 잘 묘사하기를 원합니다. hot 과 cold signal들를 구분할 수 있는 type이 있고, 게다가 오류 상황에 대한 파라미터 타입을 가지고 있는 것은 시스템에 효과적일 것입니다.

  • 많은 프로젝트에서 많은 사람들에 의해서 사용되는 검증된 framework를 원한다.

만약 이렇다면, RxSwift를 선택하세요

  • UI Bind 가 프로젝트에서 중요하다.

  • FRP에 초보이고, 당장 간단히 적용할 수 있는 것들이 필요할 수도 있다.

  • RxJs 혹은 RxJava를 이미 알고 있다. 그들과 RxSwift는 모두 ReactiveX 조직 아래에 있기 때문에, 하나를 안다면, 다른 것을은 단지 문법의 차이만 있다.

여기서 가야할 곳

RxSwift 혹은 Reactivecocoa 를 선택하던지 간에, 후회하지 않을 겁니다. 둘다 시스템을 더 잘 묘사하는데 도움을 줄 매우 유용한 framework 입니다.

RxSwift 혹은 Reactivecocoa 를 알기만 하면, 하나에서 다른 하나로 점프하는 것은 시간 문제라고 하는 말하는 것은 중요합니다. 연습으로, Reactivecocoa 에서 RxSwift로 간 저의 경험으로 부터, 가장 문제가 되는 부분은 오류 처리 부분이었습니다. 무엇보다도 가장 큰 마음 상태 전환은 FRP로 들어 가는 겁니다. 특정 구현이 아닙니다.

다음의 링크들은 Functional Reactive Programming, RxSwift 와 Reactivecocoa 로의 여행에 도움을 줄 겁니다.

이 훌륭한 라이브러리들 중 하나를 여러분의 미래의 프로젝트에서 사용할 수 있기를 희망합니다.

만약 이 튜터리얼을 통해서 배우는 것이 즐거우셨다면, 스토어에 있는 RxSwift book( https://store.raywenderlich.com/products/rxswift?_ga=1.9745141.1558722521.1451401789 )을 확인해보는 것은 어떠세요?

이것은 이 책에 있는 맛보기 입니다.:

  • 시작하기: Reactive programming 패러다임에 대한 소개를 얻고, 포함된 용어를 배우세요. 그리고 여러분의 프로젝트에서 어떻게 RxSwift를 시작할지 알아 보세요.

  • Event Management: Rx- Observable들과 Observer들의 두가지 개념을 가지고 비동기 이벤트 sequence들을 처리하는 방법을 배우세요.

  • Selective 되기: filter, transform, combine, 과 time operator들과 같은 개념을 이용해서 다양한 이벤트들을 처리하는 방법을 알아 보세요.

  • UI Development: RxSwift는 RxCocoa를 사용하는 앱의 UI작업을 쉽게 합니다. RxCocoa는 Cocoa와 UIKit 둘의 통합을 제공합니다.

  • intermediate Topics: reactive networking, multi-threading, error handling에 관한 여러분의 RxSwift 지식을 레벨업하세요.

  • Advanced Topcis: MVVM 앱 구조, scene-based navigation, service들을 통한 데이터 노출에 대해 배움으로써 RxSwift 교육을 마무리 지우세요.

  • 그리고 더 더 더!

이 책의 끝 쯤에 reactive 패러다임에서 일반적인 이슈를 해결하는 실제 겸험을 얻을 수 있습니다. - 그리고 여러번 자신의 Rx 패턴과 솔루션들을 생각해 내는데 제대로 접근하게 될 것입니다.

질문이 있으시거나 제공할 다른 Rx 리소스가 있으시다면? 아래에 코멘트를 남겨 주시거나 포럼에 남겨 주세요.

감사합니다.