Flutter 튜토리얼 11편: 임시 상태와 앱 상태

요약#

핵심 요지#

문제 정의: 앱의 모든 상태를 같은 방식으로 관리하면 코드가 복잡해지고 유지보수가 어려워진다.
핵심 주장: 상태를 임시 상태¹와 앱 상태²로 구분하면 적절한 관리 도구를 선택할 수 있다.
주요 근거: 임시 상태는 단일 위젯 내에서 setState로, 앱 상태는 Provider³ 같은 상태 관리 도구로 관리한다.
실무 기준: “이 상태가 다른 위젯에서 필요한가?”를 기준으로 상태 유형을 결정한다.
한계: 상태 구분에 절대적인 규칙은 없으며, 앱의 요구사항에 따라 유연하게 판단해야 한다.

문서가 설명하는 범위#

임시 상태와 앱 상태의 정의와 예시
상태 유형을 결정하는 기준
Provider 패키지를 사용한 간단한 앱 상태 관리
ChangeNotifier, Consumer, Provider.of 사용법

읽는 시간: 16분 | 난이도: 초급

참고 자료#

Differentiate between ephemeral state and app state - 상태 유형 구분
Simple app state management - Provider를 사용한 상태 관리

문제 상황#

앱을 개발하다 보면 다양한 종류의 상태를 관리해야 합니다.
현재 선택된 탭, 사용자 로그인 정보, 장바구니 내용 등 모든 것이 “상태”입니다.

모든 상태를 같은 방식으로 관리하면 생기는 문제#

1
// 작은 상태도 복잡한 도구로 관리?
2
// 탭 인덱스 하나를 위해 Redux를 쓰는 건 과하다
3
class MyApp extends StatelessWidget {
4
  @override
5
  Widget build(BuildContext context) {
6
    return StoreProvider<AppState>(  // Redux Store
7
      store: store,
8
      child: MaterialApp(...),
9
    );
10
  }
11
}
12

13
// 또는 모든 상태를 setState로만 관리?
14
// 여러 위젯이 공유하는 상태를 위해 prop drilling이 발생
15
class Parent extends StatefulWidget { ... }
16
class Child extends StatelessWidget {
17
  final int cartCount;  // 부모에서 전달받음
18
  final VoidCallback onAdd;  // 부모에서 전달받음
19
}

문제는 다음과 같습니다.

작은 상태에 복잡한 도구를 사용하면 불필요한 코드가 늘어난다.
모든 상태를 setState로 관리하면 prop drilling이 발생한다.
상태의 범위와 특성을 고려하지 않으면 유지보수가 어려워진다.

해결 방법#

상태를 임시 상태와 앱 상태로 구분하면 각각에 맞는 관리 방식을 선택할 수 있습니다.

챕터 1: 임시 상태(Ephemeral State) 이해하기#

Why#

NOTE
단일 위젯 내에서만 사용되는 상태는 복잡한 상태 관리 도구가 필요 없습니다.
setState만으로 충분히 관리할 수 있습니다.
1
// 탭 인덱스는 이 위젯에서만 사용됨
2
int _currentIndex = 0;

What#

NOTE
임시 상태(UI 상태, 로컬 상태라고도 함)는 단일 위젯 내에 깔끔하게 포함될 수 있는 상태입니다.

특징 설명
범위 단일 위젯 내부
접근 다른 위젯이 접근할 필요 없음
지속성 앱 재시작 시 초기화되어도 됨
복잡도 단순한 변경 패턴

특징	설명
범위	단일 위젯 내부
접근	다른 위젯이 접근할 필요 없음
지속성	앱 재시작 시 초기화되어도 됨
복잡도	단순한 변경 패턴

How#

TIP

임시 상태 예시

1
class MyHomepage extends StatefulWidget {
2
  const MyHomepage({super.key});
3

4
  @override
5
  State<MyHomepage> createState() => _MyHomepageState();
6
}
7

8
class _MyHomepageState extends State<MyHomepage> {
9
  int _selectedIndex = 0;  // 임시 상태
10

11
  @override
12
  Widget build(BuildContext context) {
13
    return Scaffold(
14
      body: _pages[_selectedIndex],
15
      bottomNavigationBar: BottomNavigationBar(
16
        currentIndex: _selectedIndex,
17
        onTap: (index) {
18
          setState(() {
19
            _selectedIndex = index;  // 상태 변경
20
          });
21
        },
22
        items: const [
23
          BottomNavigationBarItem(icon: Icon(Icons.home), label: '홈'),
24
          BottomNavigationBarItem(icon: Icon(Icons.person), label: '프로필'),
25
        ],
26
      ),
27
    );
28
  }
29

30
  final List<Widget> _pages = [
31
    const Center(child: Text('홈 화면')),
32
    const Center(child: Text('프로필 화면')),
33
  ];
34
}

임시 상태의 대표적인 예

상태	설명
PageView의 현재 페이지	스와이프로 변경되는 페이지 인덱스
애니메이션 진행률	현재 애니메이션의 진행 상태
BottomNavigationBar 선택 탭	현재 선택된 탭 인덱스
폼 필드 입력값	제출 전까지의 텍스트 필드 값

Watch out#

WARNING
임시 상태는 앱 재시작 시 초기화됩니다.
사용자가 기대하는 지속성이 있다면 앱 상태로 관리해야 합니다.
1
// 문제: 앱을 재시작하면 탭 선택이 초기화됨
2
// 사용자가 마지막 탭 위치를 기억하길 원한다면?
3
int _selectedIndex = 0;  // 앱 상태로 승격 필요

결론: 단일 위젯 내에서만 사용되는 상태는 setState로 관리합니다.

챕터 2: 앱 상태(App State) 이해하기#

Why#

NOTE
여러 위젯이 공유하거나 세션 간에 유지해야 하는 상태는 더 체계적인 관리가 필요합니다.
setState만으로는 여러 위젯에 상태를 전파하기 어렵습니다.
1
// 장바구니는 여러 화면에서 접근해야 함
2
// 카탈로그 화면, 장바구니 화면, 결제 화면...

What#

NOTE
앱 상태는 앱의 여러 부분에서 공유하고 세션 간에 유지하고 싶은 상태입니다.

특징 설명
범위 여러 위젯에서 공유
접근 앱의 다양한 부분에서 필요
지속성 세션 간 유지 필요
복잡도 복잡한 변경 패턴 가능

특징	설명
범위	여러 위젯에서 공유
접근	앱의 다양한 부분에서 필요
지속성	세션 간 유지 필요
복잡도	복잡한 변경 패턴 가능

How#

TIP
앱 상태 예시

상태 이유
사용자 로그인 정보 모든 화면에서 접근, 세션 유지
장바구니 내용 여러 화면에서 수정, 결제까지 유지
알림 목록 여러 곳에서 표시, 서버와 동기화
사용자 설정 앱 전체에 영향, 영구 저장
읽음/안읽음 상태 여러 화면에서 표시, 서버와 동기화
상태 유형 결정 흐름
flowchart TD A[상태가 필요함] --> B{다른 위젯에서 필요한가?} B -->|아니오| C[임시 상태 setState 사용] B -->|예| D{세션 간 유지 필요?} D -->|아니오| E[앱 상태 Provider 등 사용] D -->|예| F[앱 상태 + 영구 저장]

상태	이유
사용자 로그인 정보	모든 화면에서 접근, 세션 유지
장바구니 내용	여러 화면에서 수정, 결제까지 유지
알림 목록	여러 곳에서 표시, 서버와 동기화
사용자 설정	앱 전체에 영향, 영구 저장
읽음/안읽음 상태	여러 화면에서 표시, 서버와 동기화

Watch out#

WARNING
모든 상태를 앱 상태로 만들면 불필요한 복잡도가 생깁니다.
상태의 범위를 가능한 작게 유지하세요.
1
// 나쁜 예: 모든 상태를 전역으로 관리
2
class GlobalState extends ChangeNotifier {
3
  int tabIndex = 0;  // 임시 상태인데 전역으로?
4
  bool isPlaying = false;  // 임시 상태인데 전역으로?
5
  User? user;  // 이건 앱 상태가 맞음
6
}

결론: 여러 위젯이 공유하거나 지속성이 필요한 상태만 앱 상태로 관리합니다.

챕터 3: 상태 유형 결정하기#

Why#

NOTE
상태 유형에 절대적인 규칙은 없습니다.
앱의 요구사항에 따라 같은 상태도 다르게 분류될 수 있습니다.
1
// 탭 인덱스가 임시 상태인 경우
2
int _tabIndex = 0;  // 앱 재시작 시 초기화 OK
3

4
// 탭 인덱스가 앱 상태인 경우
5
// 사용자가 마지막 탭 위치를 기억하길 원할 때

What#

NOTE
Redux 창시자 Dan Abramov의 조언:

“The rule of thumb is: Do whatever is less awkward.” (경험 법칙: 덜 어색한 방법을 선택하라.)

상태 관리 방법은 앱의 요구사항에 따라 유연하게 결정합니다.

How#

TIP
결정 기준 질문

질문 예 → 앱 상태 아니오 → 임시 상태
여러 위젯이 이 상태에 접근하나? Provider 등 사용 setState 사용
세션 간에 유지해야 하나? 영구 저장 추가 메모리만 사용
외부 위젯에서 변경해야 하나? 상태 끌어올리기 로컬 관리
직렬화해서 저장/전송해야 하나? 모델 클래스 정의 단순 변수
상태 구분 요약

측면 임시 상태 앱 상태
관리 도구 State + setState() Provider, Riverpod 등
범위 단일 위젯 여러 위젯
지속성 불필요 필요한 경우 많음
직렬화 불필요 종종 필요
예시 현재 탭, 애니메이션 로그인, 장바구니

질문	예 → 앱 상태	아니오 → 임시 상태
여러 위젯이 이 상태에 접근하나?	Provider 등 사용	setState 사용
세션 간에 유지해야 하나?	영구 저장 추가	메모리만 사용
외부 위젯에서 변경해야 하나?	상태 끌어올리기	로컬 관리
직렬화해서 저장/전송해야 하나?	모델 클래스 정의	단순 변수

측면	임시 상태	앱 상태
관리 도구	`State` + `setState()`	Provider, Riverpod 등
범위	단일 위젯	여러 위젯
지속성	불필요	필요한 경우 많음
직렬화	불필요	종종 필요
예시	현재 탭, 애니메이션	로그인, 장바구니

Watch out#

WARNING
처음에는 임시 상태로 시작하고, 필요할 때 앱 상태로 승격하는 것이 좋습니다.
미리 모든 상태를 앱 상태로 설계하면 오버엔지니어링이 됩니다.
1
// 좋은 접근법
2
// 1. 처음에는 로컬 상태로 시작
3
class ProductPage extends StatefulWidget {
4
  // isFavorite을 로컬로 관리
5
}
6

7
// 2. 나중에 다른 화면에서도 필요해지면 승격
8
class FavoritesProvider extends ChangeNotifier {
9
  // isFavorite을 앱 상태로 관리
10
}

결론: 임시 상태로 시작하고, 공유 필요성이 생기면 앱 상태로 승격합니다.

챕터 4: ChangeNotifier로 앱 상태 정의하기#

Why#

NOTE
앱 상태를 관리하려면 상태 변경을 위젯에 알릴 수 있어야 합니다.
ChangeNotifier⁴는 Flutter SDK에 내장된 간단한 옵저버 패턴 구현체입니다.
1
// 상태가 변경되면 → 위젯에 알림 → 위젯 재빌드

What#

NOTE
ChangeNotifier는 상태를 캡슐화하고 notifyListeners()로 변경을 알립니다.
flutter:foundation에 포함되어 있어 외부 의존성이 없습니다.

How#

TIP

장바구니 모델 예시

1
import 'dart:collection';
2
import 'package:flutter/foundation.dart';
3

4
class CartModel extends ChangeNotifier {
5
  // 내부 상태 (private)
6
  final List<Item> _items = [];
7

8
  // 외부 접근용 getter (수정 불가능한 뷰)
9
  UnmodifiableListView<Item> get items => UnmodifiableListView(_items);
10

11
  // 계산된 속성
12
  int get totalPrice => _items.length * 42;
13

14
  // 상태 변경 메서드
15
  void add(Item item) {
16
    _items.add(item);
17
    notifyListeners();  // 리스너에게 변경 알림
18
  }
19

20
  void removeAll() {
21
    _items.clear();
22
    notifyListeners();  // 리스너에게 변경 알림
23
  }
24
}

ChangeNotifier 테스트

1
test('아이템 추가 시 총 가격 증가', () {
2
  final cart = CartModel();
3
  final startingPrice = cart.totalPrice;
4

5
  var notifyCount = 0;
6
  cart.addListener(() {
7
    expect(cart.totalPrice, greaterThan(startingPrice));
8
    notifyCount++;
9
  });
10

11
  cart.add(Item('Dash'));
12
  expect(notifyCount, 1);  // 알림이 1번 발생했는지 확인
13
});

핵심 패턴

요소	설명
Private 필드	`_items`처럼 외부에서 직접 수정 불가
Public getter	`items`처럼 읽기 전용 접근 제공
변경 메서드	`add()`, `removeAll()`처럼 상태 변경
`notifyListeners()`	상태 변경 후 반드시 호출

Watch out#

WARNING
notifyListeners()를 빠뜨리면 UI가 업데이트되지 않습니다.
상태를 변경하는 모든 메서드에서 호출해야 합니다.
1
void add(Item item) {
2
 _items.add(item);
3
 // notifyListeners(); // 빠뜨리면 UI 업데이트 안 됨!
4
}
또한 불필요한 notifyListeners() 호출은 성능에 영향을 줍니다.
1
void updateMultiple(List<Item> newItems) {
2
 // 나쁜 예: 매번 알림
3
 for (var item in newItems) {
4
 _items.add(item);
5
 notifyListeners(); // N번 알림 → N번 재빌드
6
 }
7

8
 // 좋은 예: 한 번만 알림
9
 _items.addAll(newItems);
10
 notifyListeners(); // 1번 알림 → 1번 재빌드
11
}

결론: ChangeNotifier로 상태를 캡슐화하고 notifyListeners()로 변경을 알립니다.

챕터 5: Provider로 상태 제공하기#

Why#

NOTE
ChangeNotifier를 만들었으면 위젯 트리에서 접근할 수 있게 해야 합니다.
ChangeNotifierProvider⁵가 이 역할을 합니다.
1
// Provider가 상태를 "제공"하면
2
// 하위 위젯들이 "소비"할 수 있음

What#

NOTE
ChangeNotifierProvider는 ChangeNotifier 인스턴스를 하위 위젯 트리에 제공하는 위젯입니다.
provider 패키지를 설치해야 사용할 수 있습니다.

How#

TIP
패키지 설치
Terminal window
1
flutter pub add provider
단일 Provider 설정
1
import 'package:provider/provider.dart';
2

3
void main() {
4
  runApp(
5
    ChangeNotifierProvider(
6
      create: (context) => CartModel(),
7
      child: const MyApp(),
8
    ),
9
  );
10
}
여러 Provider 설정
1
void main() {
2
  runApp(
3
    MultiProvider(
4
      providers: [
5
        ChangeNotifierProvider(create: (context) => CartModel()),
6
        ChangeNotifierProvider(create: (context) => UserModel()),
7
        Provider(create: (context) => AnalyticsService()),
8
      ],
9
      child: const MyApp(),
10
    ),
11
  );
12
}
Provider 위치
graph TD A[ChangeNotifierProvider] --> B[MaterialApp] B --> C[HomePage] B --> D[CartPage] B --> E[CheckoutPage] style A fill:#e1f5fe
Provider는 상태에 접근해야 하는 모든 위젯의 상위에 위치해야 합니다.

Watch out#

WARNING

Provider를 너무 높은 위치에 두면 불필요한 리소스를 사용합니다.
상태가 필요한 서브트리의 바로 위에 두는 것이 좋습니다.

1
// 나쁜 예: 항상 최상위에 모든 Provider
2
runApp(
3
  MultiProvider(
4
    providers: [
5
      // 모든 Provider를 최상위에...
6
      ChangeNotifierProvider(create: (_) => FeatureAModel()),
7
      ChangeNotifierProvider(create: (_) => FeatureBModel()),
8
    ],
9
    child: MyApp(),
10
  ),
11
);
12

13
// 좋은 예: 필요한 범위에만
14
Navigator.push(
15
  context,
16
  MaterialPageRoute(
17
    builder: (context) => ChangeNotifierProvider(
18
      create: (_) => FeatureAModel(),  // FeatureA 화면에서만 필요
19
      child: FeatureAScreen(),
20
    ),
21
  ),
22
);

결론: ChangeNotifierProvider로 상태를 필요한 범위의 위젯 트리에 제공합니다.

챕터 6: Consumer로 상태 사용하기#

Why#

NOTE
Provider로 상태를 제공했으면, 하위 위젯에서 상태를 읽고 변경에 반응해야 합니다.
Consumer⁶ 위젯이 이 역할을 합니다.
1
// 상태가 변경되면 Consumer의 builder만 재빌드됨

What#

NOTE
Consumer<T>는 T 타입의 상태에 접근하고, 상태 변경 시 builder를 다시 호출합니다.
상태가 변경될 때 필요한 부분만 재빌드합니다.

How#

TIP

기본 사용법

1
class CartTotal extends StatelessWidget {
2
  @override
3
  Widget build(BuildContext context) {
4
    return Consumer<CartModel>(
5
      builder: (context, cart, child) {
6
        return Text('총 가격: ${cart.totalPrice}원');
7
      },
8
    );
9
  }
10
}

builder 매개변수

매개변수	설명
`context`	빌드 컨텍스트
`cart`	`CartModel` 인스턴스 (상태)
`child`	재빌드되지 않는 정적 위젯

child를 활용한 최적화

1
Consumer<CartModel>(
2
  builder: (context, cart, child) {
3
    return Column(
4
      children: [
5
        child!,  // 재빌드되지 않음
6
        Text('총 가격: ${cart.totalPrice}원'),  // 재빌드됨
7
      ],
8
    );
9
  },
10
  child: const ExpensiveWidget(),  // 한 번만 빌드
11
)

Consumer 위치 최적화

1
// 나쁜 예: Consumer가 너무 높음
2
Consumer<CartModel>(
3
  builder: (context, cart, child) {
4
    return Column(
5
      children: [
6
        const Header(),  // 재빌드 불필요
7
        const ProductList(),  // 재빌드 불필요
8
        Text('${cart.totalPrice}'),  // 이것만 필요
9
      ],
10
    );
11
  },
12
)
13

14
// 좋은 예: Consumer가 필요한 곳에만
15
Column(
16
  children: [
17
    const Header(),
18
    const ProductList(),
19
    Consumer<CartModel>(
20
      builder: (context, cart, child) {
21
        return Text('${cart.totalPrice}');
22
      },
23
    ),
24
  ],
25
)

Watch out#

WARNING

Consumer를 위젯 트리 높은 곳에 두면 불필요한 재빌드가 발생합니다.
가능한 깊은 곳에 배치하세요.

1
// 문제: 전체 화면이 재빌드됨
2
@override
3
Widget build(BuildContext context) {
4
  return Consumer<CartModel>(
5
    builder: (context, cart, child) {
6
      return Scaffold(
7
        appBar: AppBar(...),  // 재빌드 불필요
8
        body: ListView(...),   // 재빌드 불필요
9
        bottomSheet: Text('${cart.totalPrice}'),  // 이것만 필요
10
      );
11
    },
12
  );
13
}

결론: Consumer를 가능한 깊은 곳에 배치해서 필요한 부분만 재빌드합니다.

챕터 7: Provider.of로 상태 변경하기#

Why#

NOTE
버튼 클릭 시 상태를 변경해야 할 때, UI 업데이트 없이 메서드만 호출하고 싶을 수 있습니다.
Provider.of⁷에 listen: false를 사용하면 됩니다.
1
// "장바구니 비우기" 버튼 → 상태 변경만 필요
2
// 버튼 자체는 재빌드될 필요 없음

What#

NOTE
Provider.of<T>(context)는 T 타입의 상태에 접근합니다.
listen: false를 설정하면 상태 변경 시 재빌드하지 않습니다.

How#

TIP

상태 변경만 필요한 경우

1
class ClearCartButton extends StatelessWidget {
2
  @override
3
  Widget build(BuildContext context) {
4
    return ElevatedButton(
5
      onPressed: () {
6
        // listen: false → 이 위젯은 재빌드되지 않음
7
        Provider.of<CartModel>(context, listen: false).removeAll();
8
      },
9
      child: const Text('장바구니 비우기'),
10
    );
11
  }
12
}

context.read vs context.watch

1
// 상태 변경만 (재빌드 안 함) - 이벤트 핸들러에서 사용
2
context.read<CartModel>().add(item);
3

4
// 상태 읽기 + 구독 (재빌드 함) - build 메서드에서 사용
5
final totalPrice = context.watch<CartModel>().totalPrice;

패턴 비교

방법	재빌드	사용 위치
`Consumer`	O	build 메서드 내
`context.watch()`	O	build 메서드 내
`Provider.of(listen: true)`	O	build 메서드 내
`context.read()`	X	이벤트 핸들러
`Provider.of(listen: false)`	X	이벤트 핸들러

전체 예시

1
class ProductItem extends StatelessWidget {
2
  final Item item;
3

4
  const ProductItem({required this.item});
5

6
  @override
7
  Widget build(BuildContext context) {
8
    return ListTile(
9
      title: Text(item.name),
10
      trailing: IconButton(
11
        icon: const Icon(Icons.add_shopping_cart),
12
        onPressed: () {
13
          // 상태 변경: listen: false 사용
14
          context.read<CartModel>().add(item);
15

16
          ScaffoldMessenger.of(context).showSnackBar(
17
            SnackBar(content: Text('${item.name} 추가됨')),
18
          );
19
        },
20
      ),
21
    );
22
  }
23
}

Watch out#

WARNING

context.read()나 Provider.of(listen: false)를 build 메서드에서 사용하면 상태 변경 시 UI가 업데이트되지 않습니다.

1
// 잘못된 사용: build에서 read 사용
2
@override
3
Widget build(BuildContext context) {
4
  // 상태가 변경되어도 이 위젯은 재빌드되지 않음!
5
  final cart = context.read<CartModel>();
6
  return Text('${cart.totalPrice}');  // 오래된 값 표시
7
}
8

9
// 올바른 사용: build에서는 watch 사용
10
@override
11
Widget build(BuildContext context) {
12
  final cart = context.watch<CartModel>();
13
  return Text('${cart.totalPrice}');  // 항상 최신 값 표시
14
}

결론: 이벤트 핸들러에서는 context.read()로, UI 표시에는 Consumer나 context.watch()를 사용합니다.

한계#

이 문서에서 다룬 Provider는 간단한 앱 상태 관리에 적합합니다.

복잡한 비동기 로직: API 호출, 캐싱 등은 추가 패턴이 필요합니다.
대규모 앱: 상태가 많아지면 더 체계적인 아키텍처(BLoC, Riverpod 등)가 필요합니다.
테스트: Provider 테스트는 추가 설정이 필요합니다.

다음 튜토리얼에서 다양한 상태 관리 라이브러리를 비교합니다.

Ephemeral State(임시 상태): 단일 위젯 내에서만 사용되고 다른 곳에서 접근할 필요가 없는 상태다. UI 상태, 로컬 상태라고도 한다. ↩
App State(앱 상태): 앱의 여러 부분에서 공유하고 세션 간에 유지하고 싶은 상태다. 공유 상태라고도 한다. ↩
Provider: Flutter 팀이 권장하는 상태 관리 패키지로, ChangeNotifier와 함께 사용하여 상태를 위젯 트리에 제공한다. ↩
ChangeNotifier: Flutter SDK에 포함된 클래스로, 리스너 패턴을 구현하여 상태 변경을 알린다. ↩
ChangeNotifierProvider: ChangeNotifier 인스턴스를 위젯 트리에 제공하는 위젯이다. ↩
Consumer: Provider가 제공한 상태를 읽고 상태 변경 시 자동으로 재빌드되는 위젯이다. ↩
Provider.of: Provider가 제공한 상태에 접근하는 메서드로, listen 매개변수로 재빌드 여부를 제어한다. ↩

Flutter 튜토리얼 11편: 임시 상태와 앱 상태

요약#

핵심 요지#

문서가 설명하는 범위#

참고 자료#

문제 상황#

모든 상태를 같은 방식으로 관리하면 생기는 문제#

해결 방법#

챕터 1: 임시 상태(Ephemeral State) 이해하기#

Why#

What#

How#

Watch out#

챕터 2: 앱 상태(App State) 이해하기#

Why#

What#

How#

Watch out#

챕터 3: 상태 유형 결정하기#

Why#

What#

How#

Watch out#

챕터 4: ChangeNotifier로 앱 상태 정의하기#

Why#

What#

How#

Watch out#

챕터 5: Provider로 상태 제공하기#

Why#

What#

How#

Watch out#

챕터 6: Consumer로 상태 사용하기#

Why#

What#

How#

Watch out#

챕터 7: Provider.of로 상태 변경하기#

Why#

What#

How#

Watch out#

한계#

Footnotes#

공유

목차