[플러터] 상태관리 라이브러리들의 동작원리

플러터의 상태관리 방법은 대표적으로 세가지가 있다.

 

1. bloc

2. provider

3. getX

 

흔히 이렇게 세가지로 분류하지만, 이 세가지를 구분하는건 의미가 없다.

왜냐하면 provider 나 getX나 결국은 bloc 패턴과 provider패턴을 구현하고 있기 때문이다.

bloc은 그저 비지니스 로직을 담은 컴포넌트이므로 무엇이든 될 수 있다.

예를들어 Provider에서는 Notifier가 bloc이고, GetX에서는 GetXController가 bloc이라고 할 수 있다.

 

# BLoC 패턴

BLoC stands for Business Logic Component.

블록패턴은 비지니스 로직 컴포넌트의 줄인말이다.

Bloc 패턴의 목적은 비지니스 로직과 UI를 분리해서 유지보수하기 쉬운 앱을 만드는데에 있다.

 

백문이 불여일견이라고, 코드부터보자.

 

 

* 코드에 대한 자세한 설명은 https://www.didierboelens.com/2018/08/reactive-programming-streams-bloc/ 여기를 참고하면 된다.

 

bloc는 UI의 상태를 담고있는 컴포넌트이다.

위젯은 그 bloc을 참고해서 데이터를 화면에 보여줄 뿐이다.

또한 StreamBuilder를 활용해서 상태가 변할때 위젯을 부분적으로 업데이트하는 부분도 중요하다.

 

이 포스트에서는 상태관리 라이브러리의 원리에 대해서 다룰 것이기 때문에 여기선 StreamBuilder의 동작에 대해서 살펴보자.

 

 

# Provider

프로바이더 라이브러리는 Notifier와 Provider로 bloc, provider패턴을 구현한다.

Notifier는 bloc역할, Provider는 의존성 주입의 역할을 한다.

기본적으로 위에서 본 bloc를 구현할때 본 코드와 원리는 동일하다.

 

출처 : https://github.com/rrousselGit/provider/blob/master/example/lib/main.dart

 

이제 원리를 살펴보자.

이번 경우는 조금 복잡하다.

 

Count위젯에서 context.watch<Counter> 를 하면 내부적으로

_inheritedElementOf 을 통해 Count 위젯의 조상을 돌면서
_InheritedProviderScopeElement<T> 즉, ChangeNotifierProvider가 만든 Counter 타입의 엘레멘트를 찾아서
context.dependOnInheritedElement(inheritedElement); 를 통해
context 즉, Count 위젯과 연관된 컨텍스트와
inheritedElement 즉, Counter 와 연관된 엘레멘트를 연결한다.
이런 식으로 Count위젯과 Counter가 연결되어 Counter의 notifyListeners() 가 불리면 Count 위젯의 build 메서드가 불리는 것이다.

 

# getX