RxSwift) why

RxSwift/Why.md at main · ReactiveX/RxSwift

GitHub - RxSwift document 를 번역 및 정리한 내용입니다.

Why

Rx 를 사용하면 declarative way(선언적 방식)으로 앱을 빌드할 수 있습니다.

Bindings

Observable.combineLatest(firstName.rx.text, lastName.rx.text) { $0 + " " + $1 }
    .map { "Greetings, \($0)" }
    .bind(to: greetingLabel.rx.text)

이것은 UITableView 와 UICollectionView 에서도 작동합니다.

viewModel
    .rows
    .bind(to: resultsTableView.rx.items(cellIdentifier: "WikipediaSearchCell", cellType: WikipediaSearchCell.self)) { (_, viewModel, cell) in
        cell.title = viewModel.title
        cell.url = viewModel.url
    }
    .disposed(by: disposeBag)

공식적인 제안은 단순한 바인딩에서 필요하지 않더라도 .disposed(by: disposeBag) 을 사용하는 것입니다.

Retries(재시도)

API 가 실패하지 않으면 좋겠지만, 불행하게도 실패합니다. 다음과 같은 API 메서드가 있다고 해보겠습니다.

func doSomethingIncredible(forWho: String) throws -> IncredibleThing

이 기능을 그대로 사용하면 실패할 경우 재시도하기가 정말 어렵습니다. exponential backoffs 모델리의 복잡성은 말할 것도 없습니다. 물론 가능하지만, 코드에는 당신이 신경 쓰지 않는 일시적인 상태가 많이 포함되어 있고, 이는 재사용할 수 없습니다.

이상적으로, 재시도의 본질을 파악하고, 이를 모든 작업에서 적용할 수 있기를 원할 것입니다.

이것이 Rx 로 간단한 재시도를 할 수 있는 방법입니다.

doSomethingIncredible("me")
    .retry(3)

사용자 지정 재시도 연산자 역시 쉽게 만들 수 있습니다.

Delegates

지루하고 non-expressive 한 일을 하는 대신

public func scrollViewDidScroll(scrollView: UIScrollView) { [weak self] // what scroll view is this bound to?
    self?.leftPositionConstraint.constant = scrollView.contentOffset.x
}

다음과 같이 작성할 수 있습니다.

self.resultsTableViewㅡ
    .rx.contentOffset
    .map { $0.x }
    .bind(to: self.leftPositionConstraint.rx.constant)

KVO(Key-Value-Observing)

Instead of:

`TickTock` was deallocated while key value observers were still registered with it. Observation info was leaked, and may even become mistakenly attached to some other object.
// key value observers 가 등록되어 있는 동안 'TickTock' 이 할당 해제되었다고 하겠습니다. 이때 observation info 가 유출되어서 다른 object 에 연결될 수도 있습니다.

and

-(void)observeValueForKeyPath:(NSString *)keyPath
                     ofObject:(id)object
                       change:(NSDictionary *)change
                      context:(void *)context

rx.observe 와 rx.observeWeakly 를 사용하여 다음과 같이 사용할 수 있습니다.

view.rx.observe(CGRect.self, "frame")
    .subscribe(onNext: { frame in
        print("Got new frame \(frame)")
    })
    .disposed(by: disposeBag)

or

someSuspiciousViewController
    .rx.observeWeakly(Bool.self, "behavingOk")
    .subscribe(onNext: { behavingOk in
        print("Cats can purr? \(behavingOk)")
    })
    .disposed(by: disposeBag)

Notifications

Instead of using:

@available(iOS 4.0, *)
public func addObserverForName(name: String?, object obj: AnyObject?, queue: NSOperationQueue?, usingBlock block: (NSNotification) -> Void) -> NSObjectProtocol

just write

NotificationCenter.default
    .rx.notification(NSNotification.Name.UITextViewTextDidBeginEditing, object: myTextView)
    .map {  /*do something with data*/ }
    ....

Transient state(일시적인 상태)

비동기 프로그램을 작성할 때 transient state(일시적인 상황) 에도 많은 문제가 있습니다. 일반적인 예는 자동 완성 검색 상자입니다.

Rx 없이 코드를 작성한다면 첫 번째 문제는 abc 의 c 가 입력되고 ab 에 대한 보류 중인 요청이 있을 때 이 요청이 취소된다는 것 입니다. 그리 어렵지 않습니다. 보류 중인 요청에 대한 참조를 가질 추가 변수를 생성하면 됩니다.

다음 문제는 요청이 실패하면 지저분한 재시도 로직을 수행해야 합니다. 하지만, 정리해야 하는 재시도 횟수를 캡처하는 필드가 몇개 더 있습니다.

프로그램이 서버에 대한 요청을 실행하기 전에 일정 시간 기다리면 좋을 것 같습니다. 누군가가 매우 긴 내용을 입력하는 과정을 대비하여 서버에 스팸 메일을 보내고 싶지 않습니다. 추가적인 타이머 필드가 있을까요?

검색이 실행되는 동안 화면에 표시되어야 하는 항목과 모든 재시도에도 실패할 경우에 표시되어야 하는 항목은 어떻게 해야할까요?

이 모든 것을 작성하고 테스트하는 것은 지루할 것입니다. Rx 로 동일한 논리를 작성해 보겠습니다.

searchTextField.rx.text
    .throttle(.milliseconds(300), scheduler: MainScheduler.instance)
    .distinctUntilChanged()
    .flatMapLatest { query in
        API.getSearchResults(query)
            .retry(3)
            .startWith([]) // clears results on new search term
            .catchErrorJustReturn([])
    }
    .subscribe(onNext: { results in
      // bind to ui
    })
    .disposed(by: disposeBag)

추가적인 플래그나 필드가 필요하지 않습니다. Rx 는 일시적인 혼란을 처리합니다.

Compositional disposal(구성 폐기)

table view 에 흐린 이미지를 표시하려는 시나리오를 가정하겠습니다.

• 먼저, 이미지를 URL 에서 가져온 다음 디코딩한 다음 흐리게 처리해야 합니다.
• 블러 처리를 위한 비용이 존재하기 때문에 셀이 보이는 table view 영역을 벗어나면 프로세스가 취소될 수 있다면 좋을 것입니다.
• 사용자가 매우 빠르게 스와이프하면 많은 요청들이 시작되고 취소될 수 있기 때문에 셀이 보이는 영역에 들어가면 이미지를 가져오는 것을 즉시 시작하지 않아도 좋을 것입니다.
• 또한, 동시에 이미지 작업의 수를 제한할 수 있다면 좋을 것입니다.

아래는 Rx 를 사용하여 구현한 것입니다.

// this is a conceptual solution
let imageSubscription = imageURLs
    .throttle(.milliseconds(200), scheduler: MainScheduler.instance)
    .flatMapLatest { imageURL in
        API.fetchImage(imageURL)
    }
    .observeOn(operationScheduler)
    .map { imageData in
        return decodeAndBlurImage(imageData)
    }
    .observeOn(MainScheduler.instance)
    .subscribe(onNext: { blurredImage in
        imageView.image = blurredImage
    })
    .disposed(by: reuseDisposeBag)

이 코드는 모든 작업을 수행하며 imageSubscription 이 삭제되면, 종속된 모든 비동기 작업ㅇ르 취소하고 불량 이미지가 UI 에 바인딩되지 않도록 합니다.

Aggregating network requests(네트워크 요청 집계)

두 개의 요청을 실행하고 둘 다 완료되었을 때 결과를 집계해야 하는 경우는 어떻게 해야할 까요?

zip operator 가 있습니다.

let userRequest: Observable<User> = API.getUser("me")
let friendsRequest: Observable<[Friend]> = API.getFriends("me")

Observable.zip(userRequest, friendsRequest) { user, friends in
    return (user, friends)
}
.subscribe(onNext: { user, friends in
    // bind them to the user interface
})
.disposed(by: disposeBag)

그렇다면 이러한 APIs 가 백그라운드 스레드에서 결과를 반환하고 main UI 스레드에서 바인딩이 발생해야 하는 경우에는 어떻게 할까요?

observeOn 이 있습니다.

let userRequest: Observable<User> = API.getUser("me")
let friendsRequest: Observable<[Friend]> = API.getFriends("me")

Observable.zip(userRequest, friendsRequest) { user, friends in
    return (user, friends)
}
.observeOn(MainScheduler.instance)
.subscribe(onNext: { user, friends in
    // bind them to the user interface
})
.disposed(by: disposeBag)

State(상태)

mutation 을 허용하는 언어를 사용하면 전역 상태에 쉽게 접근할 수 있고 변경 할 수 있습니다. 공유된 전역 상태의 제어되지 않은 mutation 은 쉽게 combinatorial explosion(문제의 조합이 받는 영향에 따라 문제의 복잡성이 급격히 증가)을 일으킬 수 있습니다.

그러나 다른 한편으로는, 스마트한 방식으로 사용될 때 명령형 언어는 하드웨어에 더 가깝게 더 효율적인 코드를 작성할 수 있습니다.

combinatorial explosion 과 싸우는 일반적인 방법은 상태를 가능한 단순하게 유지하고, unidirectional data flows(단방향 데이터 흐름)을 사용하여 파생 데이터를 모델링하는 것입니다.

이것은 Rx 가 정말 빛나는 곳입니다. Rx 는 기능적 세계와 명령적 세계 사이의 sweet spot 입니다. 변경할 수 없는 정의와 순수 함수를 사용하여 안정적인 구성 가능한 방식으로 변경 가능한 상태의 스냅샷을 처리할 수 있습니다.

실제적인 예시가 있나요?

Easy integration(쉬운 통합)

자신만의 observable 을 생성해야 한다면?

꽤나 쉽습니다. 아래의 코드는 RxCocoa 에서 가져왔으며 URLSession 으로 HTTP 요청을 래핑하는데 필요한 모든 것입니다.

extension Reactive where Base: URLSession {
    public func response(request: URLRequest) -> Observable<(Data, HTTPURLResponse)> {
        return Observable.create { observer in
            let task = self.base.dataTask(with: request) { (data, response, error) in

                guard let response = response, let data = data else {
                    observer.on(.error(error ?? RxCocoaURLError.unknown))
                    return
                }

                guard let httpResponse = response as? HTTPURLResponse else {
                    observer.on(.error(RxCocoaURLError.nonHTTPResponse(response: response)))
                    return
                }

                observer.on(.next(data, httpResponse))
                observer.on(.completed)
            }

            task.resume()

            return Disposables.create(with: task.cancel)
        }
    }
}

Benefits(이익)

요약하면 Rx 를 사용하면 코드가 다음과 같이 만들어 집니다.

• Composable(구성 가능한) ← Rx 는 composition 의 별명이기 때문입니다.
• Reuable(재사용 가능) ← composable 하기 때문입니다.
• Declarative(선언적) ← 정의는 변경할 수 없고 오직 데이터만 변경되기 떄문입니다.
• Understandable and concise(이해하기 쉽고 간결합니다.) ← 추상화 수준을 높이고 일시적인 상태를 제거합니다.
• Stable(안정성) ← Rx 코드는 철저하게 단위 테스트를 거쳤기 때문입니다.
• Less stateful ← 애플리케이션을 단방향 데이터 흐름으로 모델링하기 때문입니다.
• Without leaks(누수 없음) ← 리소스 관리가 쉽기 때문입니다.

It’s not all or nothing

Rx 를 사용하여 최대한 많은 애플리케이션을 모델링하는 것이 좋습니다.

그러나 모든 operator 를 알지 못하고 특정 사례의 모델링하는 연산자가 있는지 여부도 모른다면 어떻게 될까요?

Rx 연산자는 수학을 기반으로 하며 직관적이어야 합니다. 좋은 소식은 약 10-15명의 operators 가 일반적인 사용사례를 다룬다는 것입니다. map, filter, zip, observeOn 등이 있습니다.

all Rx operators 의 목록이 있습니다.

각 operators 에 대해 작동 방식을 설명하는데 도움이 되는 marble diagram 이 있습니다.

하지만 해당 목록에 없는 operator 가 필요하면 어떻게 할까요? 나만의 operator 를 만들 수 있습니다.

어떤 이유로 그런 종류의 operator 를 만드는 것이 정말 어렵거나 작업해야하는 일부 레거시 상태 저장 코드가 있는 경우 어떻게 할까요? Rx monads 에서 쉽게 빠져나와 데이터를 처리하고 다시 돌아올 수 있습니다.