provider의 거지같은 공식문서를 보다가 riverpod의 공식문서를 보니 선녀가 따로 없었다.
riverpod으로 짠 counter 코드는 아래와 같다.
import 'package:flutter_riverpod/flutter_riverpod.dart';
final counterStateProvider = StateProvider((ref) {
return 0;
});
class RiverPodController {
void increase(WidgetRef ref) {
ref.read(counterStateProvider.notifier).state++;
}
void decrease(WidgetRef ref) {
ref.read(counterStateProvider.notifier).state--;
}
}
import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:shw_test/components/button.dart';
import 'package:shw_test/riverpod/controller.dart';
class RiverpodScreen extends ConsumerWidget {
const RiverpodScreen({super.key});
@override
Widget build(BuildContext context, WidgetRef ref) {
final controller = RiverPodController();
String counter = ref.watch(counterStateProvider).toString();
return Scaffold(
appBar: AppBar(
title: const Text("Counter"),
),
body: Center(
child: Column(
children: [
Text(
counter,
style: const TextStyle(fontSize: 50),
),
Row(
mainAxisAlignment: MainAxisAlignment.center,
children: [
Button(
text: "+",
fontSize: 30,
onPressed: () {
controller.increase(ref);
print(counter);
},
),
const SizedBox(
width: 20,
),
Button(
text: "-",
fontSize: 30,
onPressed: () {
controller.decrease(ref);
},
),
],
),
],
),
),
);
}
}
provider의 개선버전이라서 그런지 riverpod과 provider는 비슷한 점이 있었다.
그래서 riverpod은 provider의 어떤점을 개선했을까?
1. 의존성
- 짜면서 느낀거지만 provider는 장 상위 위젯에 provider를 선언해줘야 한다. 이로 인해 Flutter에 의존성을 띄게 되고 목적에 맞게 분리하기 어려워질 수 있다. 반면 Riverpod는 전역으로 provider가 선언되고 일반 위젯들 대신 ConsumerWidget이나ConsumerStatefulwidet을 선언하여 ref라는 인자를 통해 provider를 접근하는 방식을 쓴다.
2.안정성
- Provider는 모델클래스가 가변적이다. 하지만 Riverpod는 모델클래스가 불변이며 단반향으로 데이터가 흐른다
3. 동일타입선언 가능여부
이런 여러점을 보았을때 bloc, getx, riverpod중 뭘쓸지 고민할 수는 있어도 riverpod을 쓸지 provider를 쓸지 고민은 할 필요가 없어졌다. 당연히 개선된 riverpod을 써야지:)
'개발 > Flutter' 카테고리의 다른 글
[상태관리#6]그래서...어떤 상태관리를 쓸거야? (0) | 2023.11.22 |
---|---|
[상태관리#5] mobX (0) | 2023.11.22 |
[상태관리#3]Provider (1) | 2023.11.22 |
[상태관리#2]Bloc (2) | 2023.11.22 |
[상태관리#1] GetX (1) | 2023.11.22 |