Stateless Widget과 Stateful Widget

Stateless Widget과 Stateful Widget

Stateless Widget은 불변 객체이다. 위젯이 한번 만들어지면 state나 프로퍼티를 바꿀 수 없다. 프로퍼티가 바뀔 필요 없을 때, stateless widget으로 만드는 것이 좋다.
stateless widget의 lifecycle은 프로퍼티를 넘길 수 있는 constructor와, override하는 build 메소드로 시작한다. 위젯의 시각적 묘사는 build 메소드가 결정한다.

다음 이벤트는 stateless widget의 update를 일으킨다.
- 위젯이 위젯트리에 삽입된다.
- 의존성의 상태나 상속 받은 위젯(조상 노드)가 변한다.

 

Stateful Widget은 상태를 보존한다. UI의 일부가 동적으로 변해야 할 때 유용하다.
stateful widget은 별도의 State 클래스에 가변 상태를 저장한다.
이것은 모든 stateful widget이 createState 함수를 override하고 수행해야 하는 이유이다.

 

stateful widget의 라이프사이클

 

 

BuildContext
모든 위젯의 build 메소드는 BuildContext를 인자로 갖는다. BuildContext는 위젯 트리에서 지금 어디에 있는지를 알려준다. BuildContext를 통해서 어떤 위젯이든 그 엘리먼트에 접근할 수 있다. 부모 위젯의 상태에 접근할 때 특히 BuildContext는 중요하다.

위젯에 build context를 할당하면, 내부 플래그 mounted가 true로 셋팅된다. 이것은 프레임워크로 하여금 이 위젯이 현재 위젯 트리에 있음을 알게 한다.
initState는 위젯이 생성되고 처음으로 호출되는 메소드이다. 이것은 안드로이드의 onCreate나 iOS의 viewDidLoad와 비슷하다.

 

didChangeDependencies
프레임워크가 처음 위젯을 빌드하면, initState 이후에 didChangeDependencies가 호출된다. 만약에 state object가 상속 받은 위젯이 있고, 그 위젯이 변한다면 didChangeDependencies는 다시 호출된다.
마지막으로, 프레임워크는 didChangeDependencies 호출 이후에 build를 호출한다. 이 함수는 위젯이 렌더링이 필요할 때마다 호출되므로 개발자에게 가장 중요하다. 트리의 모든 위젯은 build 메소드를 재귀적으로 트리거하기 때문에, 이 메소드는 매우 빨라야 한다.

 

didUpdateWidget
didUpdateWidget은 부모 위젯이 변하여 UI를 다시 그릴 때 호출된다.
이 때, oldWidget 인스턴스를 파라미터로 받아서 현재 위젯과 비교하여 추가적인 로직을 수행한다.

 

setState
위젯의 상태를 바꾸고 싶을 때에는 setState를 호출한다. 그러면 프레임워크는 위젯을 dirty로 마크해두고, 이는 build를 다시 트리거한다.

 

deactivate
오브젝트를 트리로부터 제거할 때에는 deactivate를 호출한다.
그러면 어떨 때 프레임워크는 트리의 다른 부분에 state object를 재삽입하기도 한다.

 

dispose
dispose는 트리로부터 객체와 상태를 영구적으로 제거할 때 호출한다.
스트림을 제거하거나 애니메이션이나 컨트롤러를 처분할 때와 같은, 메모리 클린업을 할 때 이 메소드는 중요하다.
dispose의 엄지의 법칙은 상태에서 정의한 프로퍼티를 검사하여 적절히 처분했는지를 확인하는 것이다.