Summary MVI 직접 작성 해야/하지 않아야 하는 이유

https://www.youtube.com/watch?v=E6obYmkkdko 를 정리만 해둔 글 입니다.

 

주요 컨셉

• 단방향 데이터 흐름 (unidirectional cycle of data)
• 논블록킹(non blocking)
• 불변상태(immutable state)

 

• 모델(Model)에서 유저(User)의 인텐트(Intent =의도)를 처리하는 시간이 오래걸릴 수 있기 때문에, 데이터 사이클(cycle of data) 을 논블럭(non-blocking) 하는 것이 매우 중요 합니다

 

• 상태(state)의 무결성을 보장하는 것이 모델이 하는 일
• 외부에 의해 상태가 변화 되지 않습니다(immtable)
• 내부에서는 상태가 변화합니다
• 인텐트는 네트워크 작업과 같은 비즈니스 작업을 수행하는 변환기(transformer)를 거치게 됩니다
• 리듀서(reducer) 는 변환기를 통해 전달된 결과와 이전 상태를 전달 받아서 새로운 상태를 만들어 냅니다
• 새로운 상태를 뷰는 전달 받습니다

 

직접 구현 하는 경우

• 리덕스(redux) 스타일은 의도를 모델에 전달하기 위한 인텐트 스트림을 구현합니다
• 인텐트에 공통의 슈퍼 타입을 지정해서 인텐트 스트림 전송하고, 이후에 디스패처에 의해 해당 유형 정보가 다시 만들어지고 흐름에 맞는 변환기를 선택 합니다
• 하지만 단점으로는 슈퍼 타입으로 치환되기 때문에 이후에 강제 형 변환이 필요하고, 이것은 인텐트가 많은 경우 좋지 못합니다.
• 또한 값을 copy 하고 update 할 떄, 멀티 스레드의 이슈가 발생하여 가시성 보장이 필요합니다.
• 인텐트를 상태로만 표현하는 것에는 한계(일회성의 너무 많은 상태를 필요로 하거나, 이전 화면으로의 이동, 토스트 등)가 있기 때문에, 사이드 이펙트라는 개념을 만들어 사용합니다

 

30 줄도 안되는 코드로 나만의 MVI 코드를 작성했습니다. 간단하게 구현 가능하니 MVI Framework 를 굳이 사용할 필요는 없을까요 ?

 

유투버의 결론은 Framework 를 써라 입니다

 

현실에서 MVI 를 활용하려면, 좀더 많은 기능 지원이 필요 합니다.

중첩되는 상태에 대한 엄격한 DSL 스코프, 멀티 스레딩 지원, 빠르고 쉬운 테스트를 할 수 있도록 제공(유닛 테스트, UI 테스트 에서의 비동기 지원), 상태 저장(프로세스가 죽고 복원시 사용) 등을 지원하는 Orbit Framework 를 쓰라고 추천 합니다

또한 추후에는 시간 기반의 디버깅, interaction 가능한 테스트, 멀티 플랫폼을 지원할 예정이라고 하네요.

 

(영상을 보고나니 Orbit Framework 메인테이너의 추천 영상이였네요 ㅋㅋㅋ)