[WWDC19] Data Flow Through SwiftUI - Part 1

Principles of Data Flow

Tools for Data Flow

• SwiftUI 에서 소개되는 Property, BindableObject,@Environment , @Binding ,@State
  • 미리 스포하자면 BindableObject -> ObservableObject 로 이름이 변경됨
• 이번 영상을 통해서 해당 툴들이 어떻게, 언제 쓰이는지 알게 될 것이다!

 

Principle

SwiftUI 데이터 플로우를 디자인하기 위한 두개의 원리를 알아보자.

 

First principle "Data Access as a Dependency"

• 토글을 생각해보자. 토글 뷰를 그리기 위해서는 Bool 타입의 데이터가 필요하고, 데이터가 새로운 값으로 변경될 때마다 뷰를 변경해줘야 한다.
• 데이터가 변경될 때마다 뷰를 변경하기 위해서는 서로 의존을 갖게하는 복잡한 코드를 작성해야만 한다. 
• SwiftUI 를 사용하면 뷰와 데이터간 의존성을 쉽게 표현할 수 있고, 프레임워크에서 동작을 구현되어 있기 때문에 개발자는 유저의 경험에만 집중하면 된다.

 

Second priciple "Source of Truth"

• 같은 뷰를 그릴 때 필요한 데이터가 여러개의 소스에서 온다면 데이터가 꼬이게 되고 버그를 만들기 쉽다.
• 최상위 뷰에서 하위의 뷰를 그리기 위한 데이터를 갖고 있고, 해당 데이터를 뷰에게 전달하면 두개의 뷰간에 데이터 싱크가 맞게 된다.
• Binding 을 이용한다면 하나의 데이터를 여러개의 자식뷰로 전달해 같은 데이터의 원천을 바라보도록 할 수 있다.

Example

SwiftUI View 는 immutable 하기 때문에, 일반적인 변수의 값을 변경할 수 없다.

@State property wrapper 를 붙여줌으로써 해당 변수는 뷰에서 의존해서 값이 변경될 때마다 뷰를 변경하도록 하는게 가능함을 보여준다. 프로퍼티 래퍼를 붙이는 것이 시스템에게 해당 변수는 시간이 지남에 따라 값이 변경되고 뷰에서 해당 변수에 의존함을 알려주는 것이다.

 

유저가 버튼을 클릭하면 @State 변수의 값이 변경되고, 프레임워크는 뷰에 대한 새로운 바디를 만들어낸다.

 

Property Wrapper

Swift 5.1 에서 등장한 기능으로, 변수를 래핑해서 값을 읽거나 쓸 때 특정한 동작을 할 수 있게 해준다. @State 도 property wrapper 의 일종이다.

 

@State property wrapper 를 붙이면 어떤 동작이 있는걸까?

 

@State 를 사용하면 SwiftUI 프레임워크는 우리가 갖고 있는 뷰에서 변수를 위한 영구 저장소(persistent storage)를 할당하고, 종속적으로 추적한다. 그리고 동일한 뷰의 여러 업데이트에서 스토리지를 유지해야 한다는 것을 알고 있게 된다.

 

일반적으로 @State property 는 명시적으로 private 을 표기해서 state 가 해당 뷰에 의해 소유되고 관리된다는 걸 나타낸다.

 

Anatomy of an Update

 

유저가 실제로 버튼을 누를 때 어떤 동작들이 일어날까?

• 유저가 Button 을 누르면 @State 변수인 isPlaying 의 값이 변경된다.
• PlayerView 의 @State 변수이므로 해당 뷰를 업데이트하는데,
• 해당 뷰와 하위의 뷰들, 즉 뷰 계층을 전부 새로 만든다.

여기서 중요한 점은 모든 @State 는 데이터의 원천이고, View 는 event 에 대한 시퀀스가 아닌 state 에 대한 함수라는 점이다.

Every @State is a source of truth
Views are a function of state, not of a sequence of events

 

User interaction and SwiftUI

유저 인터렉션과 SwiftUI 에서 새로운 뷰를 그리는 흐름을 나타낸 그림이다. 유저의 상호작용으로 액션이 발생하고, 액션으로 State 에 변경이 일어나고, View 를 새로 만들고, 새로 만든 View 를 유저에게 보여준다. 

 

🚧 Code Refactoring

최상위 뷰 PlayerView 에서 PlayButton 을 따로 분리해보자.

 

우선, PlayButton 내에서는 @State 변수를 사용하면 안된다.

데이터의 원천을 다른것으로 둘 수 없고, 해당 뷰는 재사용되는 뷰이기 때문에 데이터의 원천을 가질 수 없다. 부모뷰인 PlayerView 의 변수를 사용해서 같은 데이터의 원천을 바라봐야 한다.

 

PlayButton 내에서는 @Binding property wrapper 를 사용해 데이터를 나타내자.

Binding 변수는 초기값을 갖지 않고, 타입만 지정한다.

 

State 변수에 달러 표시를 붙여서 PlayButton 에 전달해준다.

$ 달러 표시는 property wrapper 의 또다른 기능이다. $ 를 붙여 State 변수를 binding 변수로 전달한다.

 

😇 UIKit vs SwiftUI 

UIKit 에서는 ViewController 에서 버튼의 타겟 액션을 설정하거나, delegate 를 정의해서 데이터를 전달하는 작업을 전부 수행했기 때문에 헤비해졌다.

 

개발자가 직접 설정해줘야했던 뷰와 뷰 사이의 데이터 싱크 맞추기 등을 이제 SwiftUI 에서 담당해주기 때문에, ViewController 는 더이상 사용할 필요가 없다 😇👏👏

 

 

Toggle, TextField, Slider 모두 생성자에서 Binding 변수를 받도록 되어있다. SwiftUI 프레임워크에서 sourth of truth 를 보장해주기에 더 이상 데이터를 복사해서 전달하거나, 데이터의 싱크를 맞출 필요가 없다.