Ch1. Hello, Combine!

애플이 말했다.

‘The Combine framework provides a declarative approach for how your app processes events. Rather than potentially implementing multiple delegate callbacks or completion handler closures, you can create a single processing chain for a given event source. Each part of the chain is a Combine operator that performs a distinct action on the elements received from the previous step’

'컴바인은 여러분의 앱에서 발생하는 이벤트들에 Declarative한 접근을 제공할 것입니다. 수많은 delegate콜백, completion 핸들링 클로져 등을 구현하는 대신 하나의 이벤트 소스에 하나의 Processing chaing을 생성하면 됩니다. 각각의 체인은 컴바인 Operator입니다. 이전 스텝을 받아 새로운 output을 만들어 내기 때문에 체이닝 가능'

State를 공유하는 코드

‘--- Thread 1 ---
begin
  var name = "Tom"
  print(name)

--- Thread 2 ---
name = "Billy Bob"

--- Thread 1 ---
  name += " Harding"
  print(name)
end’

비동기 코드에서 Mutable State를 관리하는 것은 정말로 피곤한 일이다

Foundation and UIKit/AppKit

• NotificationCenter
• Delegate pattern
• GCD
• Closure

위와 같은 여러 수단을 사용하여 비동기 프로그래밍 하였음

Foundation SwiftUI등의 아래에 놓여 있다.

컴바인은 애플에서 제공하는 프레임워크이기 때문에 안전할 것으로 기대된다. 믿고 쓰자는 거지

Foundation of Combine

Combine은 예상했다시피 RX에서 시작되었음

Combine basic

컴바인에는 3개의 Key pieces가 있다.

• Publisher
• Operator
• Subscriber

Publisher

3종류의 이벤트를 내뿜는다.(emit)

• 특정 Output type의 output value

• completion

• Failure

Publisher 프로토콜은 2개의 타입을 갖는 제네릭이다.

• Publisher.Output은 Publisher가 뿜는 이벤트의 타입이다. such as Int, String
• Publisher.Failure는 Publisher가 에러를 발생시키는 방법을 표현한다. 절대 에러를 내지 않는다면 Never

Operators

Input을 받아 새로운 Output을 만들어 다음 step으로 전달한다.

input을 upstream, output을 downstream이라고도 한다.

Subscribers

드디어 subscribtion 체인의 마지막에 도달했다. 모든 subscription은 subscriber와 함께 끝난다.

Subscriber는 subscription의 output 데이터로 작업을 한다.

두 종류의 Subscriber가 있다.

• sink subscriber: 전달받은 이벤트로 바로 바로 작업 (rx의 subscribe개념)
• assign subsciber: 전달받은 이벤트를 다른 시퀀스로 전달 (rx의 bind개념)

Subscriptions

subscription에 subscriber가 등록되면 퍼블리셔는 그제서야 이벤트를 방출한다.

subscription의 메모리관리는 특별히 해줄 것이 없다.

위에 소개한 두 종류의 subscriber모두 Cancellable 프로토콜을 따른다. 즉, subscription의 결과물은 Cancellable을 따르는 객체다. 그 객체를 메모리에서 해제하면 subscription이 해제되고 메모리 리소스를 반납한다.

ViewController에서 Cancellable객체를 갖고 있다가 dismiss되면 메모리에서 해제해줄 수도 있고

니가 만든 클래스에서 [AnyCancellable]타입의 프로퍼티에 모두 때려박은 다음에 deinit할 때 메모리에서 해제해줄 수도 있을 것이다.

What's the benefit of Combine code over "standard" code?

컴바인 안쓴다고 앱 못만드냐?? 당연히 ㄴㄴ

근데 쓰면 무슨 장점이 있는지는 알아야 할것 아님

• 컴바인은 시스템레벨에 장착되어 있다. 즉, public하지 않은 언어레벨의 피쳐들을 사용하고 스스로 만들기 힘든 API들을 제공한다.
• delegate, IBAction, closure등을 사용하는 "old" style의 코드는 모든 커스텀 케이스들에 대해 따로따로 코드를 작성하게 만든다. 테스트할 코드도 많아 지겠네. 컴바인은 이미 잘 테스트되고 검증된 operator를 제공한다.
• 너의 모든 비동기 코드가 Publisher로 작성된다면 composition과 재사용성이 좋아질 것이다.
• 컴바인의 Operator는 많은 기능을 구성하기 쉽다(composable). 어떤 기능의 operator를 만들고 싶다면 이미 존재하는 Operator를 조합하여 만들기 쉽다.
• 비동기 코드가 동기 코드 보다 테스트하기 어려운건 인정. 하지만 컴바인을 사용한다면 operator들이 이미 잘 테스트 되어 있다. 너는 로직만 테스트하면 된다.

App architecture

컴바인은 너의 앱의 구조에 영향을 주는 프레임워크가 아니다. MVC를 써도 MVVM을 써도 상관 없다.

프로젝트 전체가 아닌 부분적인 문제 해결에만 사용해도 상관 없다.

데이터모델을 변경하는 것부터 컴바인을 시작할 수도 있고 네트워킹 레이어를 개선하는 것에서 시작할 수도 있다.

SwiftUI와 같이 사용한다면 이야기가 조금 달라진다 ㅋ

MVC에서 C를 제거해야할 것이다.