프로젝트

16. Flutter의 State관리

코딩 악귀 2024. 2. 26. 02:16

 

과정

Flutter의 stateless와 stateful

Flutter의 개발을 하면, Widget을 만들고 이들을 조합하는 형태로 개발을 하게 된다.

여기서 build를 다시 해야 하는(다시 그려져야 하는) Widget이 존재하고,

그럴 필요가 없는 widget이 존재하는데 이를 stateless, stateful widget으로 구분한다.

 

내가 헷갈렸던 점은 Stateless Widget안에,

Stateful Widget이 있으면, StatefulWidget이 변할테니 부모는 Stateful 해야 하는가? 라는 고민을 잠깐 했다.

 

고민을 해보니 그럴 필요도 없고, 그럼 Stateless widget을 만들지 않았을 것이다.

StatefulWidget을 "한" 번만 빌드 해 놓으면, 내부의 상태가 build()를 통해서 반복이 될테니,

부모인 Stateless-widget에서는 re-build할 필요가 없는 것이다!

 

이렇게 생각을 하니, stateless와 stateful을 언제 써야할지 감이 오기 시작했으나, 다음과 같은 문제가 생긴다.

 

state와 무한 build 문제

stateful widget은 코드 구조를 보면 stateless와 다름을 알 수 있다.
Stateless-widget은 widget에서 바로 build를 한다.
 
Stateful-widget은 widget에서 State를 반환하고,
State안에 build가 존재한다. 이는 상태와 widget을 분리하고,
build를 독립적으로 실행할 수 있음을 암시한다.
import 'package:flutter/material.dart';

// StatelessWidget
class MyStatelessWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Container(
      child: Text('I am a stateless widget'),
    );
  }
}

// StatefulWidget
class MyStatefulWidget extends StatefulWidget {
  @override
  _MyStatefulWidgetState createState() => _MyStatefulWidgetState();
}

class _MyStatefulWidgetState extends State<MyStatefulWidget> {
  @override
  Widget build(BuildContext context) {
    return Container(
      child: Text('I am a stateful widget'),
    );
  }
}
 

그리고 setState를 사용하게 되면, 그에 영향을 받는 widget을 redraw하는 형태로 동작을 한다.

여기서 setState를 이용하면 build가 다시 동작한다.

이기 때문에, Stateful-widget 끼리 부모-자식 관계에서 무한 루프에 빠질 수 있다.

 

부모의 변경감지 -> 자식을 변경 -> 자식의 변경 감지 -> 부모의 변경 -> 부모의 변경 감지....

이런 형태의 무한루프가 빠질 수 있고, 나도 올바르게 설계하지 않고 만들다가 이런 문제를 몇 번 겪었다..

 

State의 전파가 무거워 지는 문제

일반적인 형태를 부모에서 자신을 변경할 수 있는 함수를 만든다.
그리고 자식 widget에게 함수 포인터를 인자로 주어서, 자식에서 부모에게 정보를 보낼 수 있게 된다.

 

widget의 구조가 복잡해지다 보면, 너무 많은 함수의 포인터를 전달하는 문제가 발생한다.

그래서 무작정 함수 포인터와, 값을 전달하는 것이 아닌 체계적인 고민이 필요하다.

 

로그인 상태 확인, 또는 전역적으로 상태 관리를 할 때는 다음과 같은 상태 관리 라이브러리의 도움을 받을 수 있다.

  • Provider
  • Bloc
  • getX

크게 3가지가 존재한다.

 

Flutter 인기 아키텍처 라이브러리 3종 비교 분석 - GetX vs BLoC vs Provider

안녕하세요. LINE+ ABC Studio에서 앱을 개발하고 있는 윤기영입니다. 최근 Flutter로 진행하는 새로운 앱 개발 업무를 맡아서 어떤 아키텍처 라이브러리를 사용할지 선정하는 작업을 진행했습니다.

engineering.linecorp.com

 

provider | Flutter package

A wrapper around InheritedWidget to make them easier to use and more reusable.

pub.dev

 
Flutter에 공부하지 않고 만들니까 어찌어찌 만들어지긴 했지만,
스케일이 커지다보면 복잡성이 폭발하는 경우가 올 것이 벌써 예상이 된다.
 
일단 숨 좀 돌리고, 상태 관리 라이브러리를 통해 얽혀 있는 상태를 풀어야 한다.
 
피드백
  • 상태관리 라이브러리 별 장단점 비교하기
  • 현재 youtube-controller의 provider부분을 수정하기