
과정
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 문제
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의 구조가 복잡해지다 보면, 너무 많은 함수의 포인터를 전달하는 문제가 발생한다.
그래서 무작정 함수 포인터와, 값을 전달하는 것이 아닌 체계적인 고민이 필요하다.
로그인 상태 확인, 또는 전역적으로 상태 관리를 할 때는 다음과 같은 상태 관리 라이브러리의 도움을 받을 수 있다.
- 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
- 상태관리 라이브러리 별 장단점 비교하기
- 현재 youtube-controller의 provider부분을 수정하기

과정
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 문제
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의 구조가 복잡해지다 보면, 너무 많은 함수의 포인터를 전달하는 문제가 발생한다.
그래서 무작정 함수 포인터와, 값을 전달하는 것이 아닌 체계적인 고민이 필요하다.
로그인 상태 확인, 또는 전역적으로 상태 관리를 할 때는 다음과 같은 상태 관리 라이브러리의 도움을 받을 수 있다.
- 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
- 상태관리 라이브러리 별 장단점 비교하기
- 현재 youtube-controller의 provider부분을 수정하기