이번 챕터에서는 state management에 대해서 포스팅 할 것 입니다. 만약 네이티브로 앱을 만든 경험이 있는 분들은 state management에 친숙하실 것 입니다. flutter로 개발을 하다보면, state를 어떻게 관리할 것인가는 매우 중요한 문제입니다. flutter에서 state를 관리할 방법은 setState, InheritedWidget & InheritedModel, Provider & Scoped Model, Redux, Bloc, MobX 가 있습니다. state 관리 방법에 대해 알아보기 전에 state는 무엇인가와 왜 state를 관리해 주어야 하는지에 대해 먼저 설명하도록 하겠습니다.
state란?
state는 간단하게 data라고 생각하면 됩니다. 사용자에게 보여주는 data, 사용자를 행동에 따라 변하는 data 등을 state라고 합니다.
왜 state management를 해야할까?
state를 관리하는 것은 어플리케이션에서 가장 중요하고 필수적입니다. 만약 아주 간단한 count app이라던가 사칙연산만 가능한 계산기 app이라면 특별한 state 관리는 필요없을 것입니다. 하지만 복잡한 계층구조를 가지고 있는 어플리케이션을 만든다면, 위젯 구조상 멀리 떨어진 위젯끼리 통신이 필요하다면 코드는 점점 복잡해집니다. setState만으로 복잡한 어플리케이션을 구현하는 것은 매우 힘들것입니다. 그러므로 우리는 State를 관리하는 패키지들이 필요합니다.
State management 방법
state를 관리하는 방법에는 InheritedWidget, Scoped Model, Provider, BLoc 등이 있습니다.
InheritedWidget
InheritedWidget은 state관리를 위해 Flutter 패키지에 포함된 기본적인 위젯입니다. Flutter를 이용하여 개발해본 경험이 있는 사람들은 모두 한번쯤은 사용해본 경험이 있을 것입니다. InheritedWidget은 .of()형태를 이용하여 상태에 대하여 참조합니다. MediaQuery.of(context).size.width를 보면 현재 위치의 가로 사이즈를 참조하는 것을 알 수 있습니다. 해당 위젯은 가지고 있는 상태의 변경에 따라서, 상태의 변경에 대한 알림을 하위 위젯들에게 할지 말지 결정하는 위젯입니다.
상태관리는 InheritedWidget을 감싼 하위 위젯만 가능합니다. .of 메소드를 이용하여 상태를 다룰 수 있게 접근할 수 있습니다. 하지만, .of 메소드가 호출되는 경우 .of 메소드가 있는 위젯들의 build context에 대해서 다시 빌드하여 성능저하가 발생 할 수 있습니다.
Scoped Model
Scoped Model 패키지는 Inherited Widget을 사용하여 만든 패키지입니다. 이 방법을 이용하면 Statefull 위젯과 state를 사용할 필요가 사라지고 독립된 모델로 구성할 수 있습니다. Scoped Model을 사용하면 상위 위젯에서 하위 모델로 데이터 모델을 쉽게 전달할 수 있습니다. 이 라이브러리는 세가지의 중요한 클래스를 제공합니다. 세가지의 중요한 클래스는 Model class, ScopedModel위젯, ScopedModelDescendant위젯 입니다.
Model 클래스 : 이 클래스를 확장하여 고유한 모델을 만들 수 있습니다.
ScopedModel 위젯 : 위에서 만든 고유한 모델을 위젯 계층에서 멀리 떨어진 아래 계층으로 보내고 싶을 때, ScopedModel 로 해당 모델을 감싸면 모든 하위 위젯에 모델을 보낼 수 있습니다.
ScopedModelDescendant위젯 : 위젯 트리에서 적절한 Scoped Model을 찾으려면 이 위젯을 사용합니다. 이것은 모델이 변화가 일어났다는 것을 알릴 때마다 자동으로 rebuild 할것입니다.
Provider
provider는 올해 Google IO에서 추천되어 가장 큰 주목을 받고있는 디자인 패턴입니다. 이것은 원래 구글에서 만든 것은 아닙니다. 커뮤니티에서 만든 플러그인인데 구글에서 공식적으로 추천한 것입니다. 이전 Google IO에서는 BLoc 패턴 사용을 권장하였습니다. 하지만, 단순한 로직을 구현하기 위해서도 4개 정도는 클래스를 만들어야 하기 때문에 어려워하는 사람들이 많았습니다. 반면 Provider 패턴은 데이터 공유나 로직의 분리를 좀 더 간단히 할 수 있습니다. 해당 구글 IO의 발표 내용이 궁금하신 분들의 https://www.youtube.com/watch?time_continue=11&v=d_m5csmrf7I&feature=emb_title 주소에서 확인하실 수 있습니다.
Provider 패턴은 한 클래스가 하나의 역할만 하도록 나눕니다. 또한 데이터의 공유를 쉽게 할 수 있습니다. 여기까지는 BLoc 패턴과 유사합니다. 하지만 큰 차이점은 BLoc 패턴의 경우 클래스들을 역할 별로 나누는 데는 좋지만 코드 자체가 복잡해지는 경우가 있지만, Provider 패턴의 경우 좀 더 적은 코드로 깔끔하게 클래스들을 구분해서 사용할 수 있다는 장점이 있습니다. 구글에서도 중소규모 프로젝트는 Provider 패턴을, 대규모 프로젝트에는 BLoc 패턴을 추천합니다.
Provider는 크게 두가지 부분으로 나눌 수 있습니다. 바로 생산과 소비 입니다. 데이터를 만드는 곳과 쓰는 곳이 분리되어 있습니다. Provider의 값을 이용하고 싶으면, 값을 이용하고 싶은 위젯을 Provider로 감싸주면 됩니다. 그러면 그 밑의 위젯에서는 Provider의 값을 사용할 수 있습니다.
BLoc
BLoC Pattern은 Business Logic Component의 줄임말로 Business logic과 UI의 분리가 특징인 Flutter의 state를 관리하는 디자인 패턴 중 하나입니다. BLoc에 대한 자세한 설명은 다음 챕터에서 하도록 하겠습니다.
