Advanced iOS App Arcihtecture Ch 6 Architecture - Redux

Redux란?

Redux는 앱의 상태가 하나의 Container에 들어가 있는 구조로 상태를 변경하려면 현재 상태와 요구되는 변화를 바탕으로 새로운 상태를 만들어내야만 한다.

Store

Store는 앱의 모든 상태를 가지고 있다. 앱의 살아있는 스냅샷이라고 생각하면 된다.

Store는 UI를 나타내는 데이터를 가지고 있다.

State의 종류의 예

• View state: UI를 보이거나 숨기기, 활성 상태 등을 결정
• Navigation state: 어떤 뷰가 보여야 할 지를 결정
• High-level state: 유저가 로그인 / 로그아웃을 했는 지에 대한 정보를 담음
• Data from web services: API로부터 온 response를 파싱하여 모델로써 저장
• Formatted strings: 화면에 표시하기 위해 Raw data를 변환한 문자열을 저장

Store는 ‘The source of truth’로 앱의 화면에 표시하기 위한 데이터를 담아 다른 두 뷰가 다른 데이터를 표시하는 버그를 막는다.

Derived values

Store는 앱의 큰 파일 자체를 담지 않고 URL로써 저장한다. Store 객체는 앱의 메모리에 계속 올라와 있기 때문에 용량이 큰 파일을 담고 있을 경우 os가 메모리를 확보하기 위해 앱을 강제로 종료시킬 수도 있다.

###Modeling view state

Redux 아키텍쳐에서 View는 상태를 갖지 않고 Store의 상태를 감지하고 대응할 뿐이다. Store는 항상 초기 상태를 가지며 invalid한 상태를 가지지 않는다. Redux는 개발자가 앱의 모든 가능한 상태를 정의하도록 강제한다.

Subscription

View가 그려지기 위해, Store의 변화를 구독한다. 변화가 일어날 때마다 View는 모든 상태에 따른 변화를 받는다. 이는 한 번에 한 프로퍼티의 조작이 가능한 MVVM과 다른 점이다.

View는 로드될 때마다 store의 현재 상태를 필요로 한다. 로드될 때 View는 항상 빈 상태로 있고 Store를 구독한 다음에 업데이트를 하여 뷰가 다시 그려지게 된다. 이러한 짧은 지연이 발생하기 때문에 빈 상태일 때의 View를 잘 표시하여야 한다.

Action & Reducer

Action

• 상태 변화를 나타내는 immutable한 데이터이며 유저 인터랙션으로 생성한다.
• Dispatch하여 Store의 변화를 일으킬 수 있다.

Reducer

• Store의 상태를 변화시키는 유일한 곳이다.
• Action을 dispatching하는 것과 Store의 상태를 변화시키는 것의 중간 단계이다.
• Side-effect를 일으키지 않아야 하며, 때문에 scope 밖에서 상태를 변화시킬 수 있는 API를 제공하지 않는다.
• 비즈니스 로직을 실행한다. 예) 데이터 가공
• 많은 비즈니스 로직이 들어갈 경우 sub-reducer를 구성하여 로직을 나눈다.

Threading

Redux에서는 모든 Reducer를 같은 스레드 하에서 실행하는 것이 중요하다. 다른 스레드에서 할 경우, 데이터를 무결성을 해칠 수 있다.

UI와 Store의 상태는 항상 Sync되어야 하기 때문에, 가장 쉬운 방법은 main 큐에서 돌리는 것이다.

알게된 점

• Store는 앱의 모든 상태들을 보관한다.
• Store는 항상 메모리에 존재하기 때문에 메모리 관리에 힘써야 한다.
• Reducer는 Side-Effect를 일으키지 않도록 pure한 함수만 가져야 한다.
• 상태 관리를 효율적으로 할 수 있게 해주지만 이 상태를 어떤 식으로 짤 지에 대해 고민이 필요할 것 같다.