[WWDC19] Data Flow Through SwiftUI - Part 2

Working With External Data

💬 Part1 에서는 ...

• 유저와 SwiftUI 뷰 간 데이터 흐름에 대해 얘기해봤었다.
• @State 프로퍼티 래퍼를 통해 값이 변경됨을 트래킹하는 변수를 둘 수 있고,
• @Binding 을 통해 자식뷰에서도 같은 데이터를 바라보도록 할 수 있었다.

🙋‍♀️ Part2 에서는?

• 뷰 내부에서의 동작을 관리하는 @State 변수로는 불가능한 외부에서 발생하는 이벤트, 외부에서 관리되는 데이터는 어떻게 처리해야할지 다뤄본다.
• 결론적으로 유저 인터렉션이 아닌 timer, notification 처럼 외부에서 발생하는 이벤트도 동일한 흐름으로 동작한다.
  • action 생성 -> State 값 변경 -> 뷰에 대한 새로운 카피 -> 유저에게 새롭게 보여줌
• SwiftUI 에서는 요러한 지속적으로 값이 변경되는 외부 이벤트를 나타내기 위한 추상화 타입인 Publisher 가 있다.

 

Combine Publisher

Combine 은 비동기 이벤트를 핸들링하기위한 프레임워크이고, Publisher 는 Combine 프레임워크에서 소개된 타입이다.

• Publisher 는 시간이 지남에 따라 값을 보낼 수 있는 타입으로, RxSwift 의 Observable 는 비슷한 개념이다.
• SwiftUI 뷰에서 Publisher 의 값을 구독해서 사용하려면 main thread 에서 값을 방출해야하고, 스케쥴러 지정을 위한 .receive(on:) 메소드를 제공한다.

💡 Publisher (Protocol)
Declares that a type can transmit a sequence of values over time.

💡 Combine
Customize handling of asynchronous events by combining event-processing operators.

func receive<S>(
    on scheduler: S,
    options: S.SchedulerOptions? = nil
) -> Publishers.ReceiveOn<Self, S> where S : Scheduler

 

⌚️🥑 example

podcast player 에 재생시간을 표시하는 뷰를 추가해보자.

• @State 변수인 currentTime 을 추가
• currentTime 을 표시해줄 Text 뷰를 추가
• 뷰에 대해서 onReceive 메소드를 추가
  • 메소드의 인자로 지정한 publisher 가 값을 방출할 때 마다 closure 가 수행된다.
• 이제 SwiftUI 와 Publisher 간 디펜던시가 생기게 되었다!
  • currentTimePublisher 값 변경 > state 변수 값 변경 > view 새로 그려짐

💡onReceive(_:perfome:)
Adds an action to perform when this view detects data emitted by the given publisher.

func onReceive<P>(
    _ publisher: P,
    perform action: @escaping (P.Output) -> Void
) -> some View where P : Publisher, P.Failure == Never

 

BindableObject ObservableObject Protocol

⚠️ BindableObject is replaced by the ObservableObject protocol from the Combine framework. (50800624)

2019 WWDC 예제와 변경사항이 좀 있네요 🥺

• BindableObject -> ObservableObject 로 변경됨
• didChange 를 필수로 구현해야함 -> willChange 를 필수로 구현해야함
  • 직접 구현하지 않아도 @Published 를 붙인 프로퍼티는 값이 변경되기전에 자동으로 값을 방출함
  • 뷰에서 해당 모델에서 사용할 프로퍼티에 대해서만 @Published 를 붙여주면 됨.

class Contact: ObservableObject {
    @Published var name: String
    @Published var age: Int

    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }

    func haveBirthday() -> Int {
        age += 1
        return age
    }
}

let john = Contact(name: "John Appleseed", age: 24)
cancellable = john.objectWillChange
    .sink { _ in
        print("\(john.age) will change")
}
print(john.haveBirthday())
// Prints "24 will change"
// Prints "25"

 

Creating Dependencies on ObservableObject

SwiftUI 뷰에서 ObservableObject 로 설정된 모델에 대한 디펜던시를 연결하는 방법

• 뷰에서 @ObservedObject 프로퍼티 래퍼를 통해 해당 모델 타입의 변수를 선언한다.
• 뷰를 초기화할때 model instance 를 넘겨준다.
• ObservableObject 모델에 대한 subscribe 를 자동으로 하는것!
• 아래 예제에서 변경된 점
  • BindableObject → ObservableObject
  • @ObjectBinding → @ObservedObject

Creating Dependencies Indirectly

뷰의 자식뷰에서만 필요로하는 데이터의 디펜던시를 연결하는 방법

• @EnvironmentObject 프로퍼티 래퍼를 통해 계층을 전부 거치지 않고, 하위 뷰에서 모델에 대한 의존성을 갖게할 수 있다.
• 여러개의 뷰에서 같은 모델을 사용할 수도 있다. 데이터가 변경될 때 여러개의 뷰에서 자동으로 업데이트가 된다.
  • 지난번에 언급된 source of truth 가 생각나는 것 👍

💡EnvironmentObject
A property wrapper type for an observable object supplied by a parent or ancestor view.

💡environmentObject(_:)
Supplies an ObservableObject to a view subhierarchy.

 

PlayerView()
    .environmentObject(player)

 

ObservedObject vs EnvironmentObject

초록색 뷰에서만 Model 을 사용해야하는 경우

• @ObservedObject 를 이용하면 뷰계층에서 자식뷰로 내려가면서 모델을 계속 전달해야한다.
  • @ObjectBinding → @ObservedObject
• @EnvironmentObject 를 사용하게되면 필요한 뷰에만 모델을 전달하면 된다.

 

Sources of Truth

SwiftUI 는 두가지 방법으로 sources of truth 를 제공한다.

• state : view 에서만 사용하는 value 타입, 메모리에 할당되고 생성되는걸 프레임워크에서 관리한다.
• ObservedObject : view 외부의 데이터, DB 모델 등,, 개발자에 의해 관리된다.

 

sources of truth 가 보장되고나면, reusable component 에 집중할 수 있게 된다.

• 뷰 내에서 직접 데이터를 변경하는 일이 적어지고, read-only 데이터를 선호하게 될 것이다.
• SwiftUI 내에서 일반적인 데이터와 Environment 는 read-only

 

만약 값 변경이 필요한 경우에는 Binding 을 사용하면 된다.

• State 뿐 아니라, ObservedObject, Binding 변수에 대해서도 바인딩이 가능하다.

 

🆚 State vs ObservedObject

• State property 는 뷰 내에서만 사용되는거라, 프로토타이핑에 적합하다.
• 일반적으로 데이터는 DB 등 SwiftUI 뷰 외부에서 관리되기 때문에 ObservableObject 프로토콜을 채택하는 객체로 관리되는 것이 좋다.

 

State 쓰기전에 생각해보자 🤔 정말 진짜 리얼로 뷰에서만 관리될 데이터인가?

• Button 처럼 사용자가 눌렀을때 하이라이트 컬러를 설정하는 등 정말 버튼이라는 뷰에서 관리되어야하는 데이터는 State 가 적절하다.
• 하지만 그게 아니라면, ObservableObject 처럼 SwiftUI 에서 제공되는 다른 방법을 택하자.

 

요것이 SwiftUI 로 재사용가능한 뷰를 만드는 방법이고, 모든 소프트웨어에서 일반적으로 적용되는 방법이다.

• 모든 소프트웨어에는 데이터가 있고, 데이터에 액세스 할 수 있다.
• 데이터의 원천을 최소화하고, 재사용가능한 컴포넌트를 만듬으로써 앱의 전체적인 버그를 제거할 수 있다.
• SwiftUI 를 사용한다면 이런 개념을 적용하는게 매우 쉬워진다. 😉