-JavaScript의 리덕스를 기반으로 한 패턴이다.
-MV? 패턴 들 중에서 유일하게 Intent와 상태라는 개념이 새로 도입되었다. 따라서 단방향으로 하나의 상태를 관리하는 선순환 원칙이 적용되어서 상태 충돌이 발생하지 않는 장점이 있다.
-User가 Intent를 통해서 Model에 상태를 전달한다. -> Model 안에서는 전달받은 상태에 대해 데이터를 처리하고 그 결과를 담은 상태를 View에 전달한다. -> View는 Model로부터 전달된 상태를 받아 그에 맞는 화면을 유저에게 보여준다. 이러한 흐름은 계속해서 반복되면서 선순환 구조를 이룬다.
-Model : 유일하게 상태와 데이터를 가지고 있는 불변객체로서 지난날들에 보았던 Model과는 다른 역할을 한다. Model은 View가 어떤 것을 화면에 렌더링해야 되는지를 말해주는 응답이라고 할 수 도 있다.
-View : 유저에게 보여줄 화면을 표현한다. Model로부터 상태를 받아 화면에 표시하는 로직이 정의된 곳이다.
-Intent : Modle과 마찬가지로 기존의 Intent와는 다른 의미이다. App 내부에서 발생하는 Action을 나타내고 이것을 App 내에서 상태를 바꾸려는 의도이다. 즉, Model에게 앱의 상태를 전달한다. 유저는 모든 UI 변화에 대해서 이 Intent를 통해서 Model에게 event를 전달한다.
-SideEffects : 상태 변경이 필요없는 API 또는 DB 접근과 같은 이벤트를 발생시킨다. 예를들면 ToastPopUp 이벤트같은 것을 실행시키는 것을 말한다.
-장점
-단점
-cf.상태문제 : 여러 상태를 관리하고 있는데 내가 의도하지 않은 방향으로 상태가 흘러가는 것
-cf.
-모바일 앱에서 가장 큰 난제 중의 하나인 복잡한 상태들을 깔끔하고 유지 보수성 높게 구현 할 수 있을까에 대한 문제를 해결하고 싶었다. 그 결과 앱 전체의 이벤트를 State Machine으로 처리한다면 어떨까 라는 의문이 들어서 실행해 보았다.
-MVVM에서 상태문제와 부수효과라는 문제점을 해결하였다. MVI는 완전히 한방향으로만 데이터가 쭈쭈쭉 흘러간다.
-Life Cycle 처리를 신경쓰지 않아도 된다.
-상태에 따라 다르게 동작하는 UI를 보다 직관적으로 관리 가능
-특정화면에서 수정 된 내용이 다른 곳에서 자동으로 적용된다.
-앱 전체의 이벤트를 하나의 스테이트 머신으로 처리하는 것이야. 이게 개꿀인게 라이프사이클 처리같은 복잡한 처리들도 하나의 스테이트 머신 안에서 처리가 되서 일관되게 처리 할 수 있는 아키텍처임과 동시에 , 상태에 따라서 다르게 동작하는 UI들도 보다 직관적으로 구현이 가능하다.
-책임을 나누는 것처럼 각각의 상태를 어떤 식으로 가공하는가에 대한 룰도 분리시켜서 상태처리가 가능하고 , 관심사의 분리라는 측면에서 코드를 수정 할 때 특정 부분만 보면되는 그런 개꿀장점이 있다.
-상태를 저장하는 부분은 보통 enum class 또는 sealed class 또는 data class로 구현한다.
-어떤 조건에서는 B로 또 다른 어떤 조건에서는 C로 변경
-각 상태가 변경 되었을 때 어떤 로직을 트리거시키는 실제 로직
위 세가지 요소의 복잡도에 따라서 다양하게 구현해야 되는데 어떻게 구현했냐에 따라서 큰 범위의 3가지로 나뉜다.
-단방향의 이벤트 처리 파이프라인을 가지는 아키텍처를 부르는 넓은 의미의 용어
-Facebook에서 웹 포론트엔드의 상태 처리를 직관적이고 깔끔하게 하기 위해 고안한 설계 패턴. 단방향의 pipelined loop를 통해 이벤트를 처리한다.
-MVI 패턴의 변형 구현체 중 가장 효율적이라고 알려진 구현체이다.
-Dan Abramo라는 사람이 만들었는데 100줄따리 라이브러리로 모든 MVI 구현체 씹어 먹었었음.