
riverpod을 공부하기 위해 간단한 코드 작성을 하고 있었다.
우측 하단 floatButton을 누를때마다 랜덤 숫자가 만들어지고 이 숫자를 갖고 jsonplaceholder.typicode.com 에 api 요청을 하는 코드이다.
랜덤 숫자와 todo내용 모두 프로바이더로 작성이 되어있고, 랜덤 숫자를 이용해 todo의 인덱스에 접근하여 데이터를 뿌려준다.
// 재요청 메서드
Future<void> rebuild(int random) async {
state = const AsyncValue.loading(); // 상태를 로딩 중으로 설정
state = await AsyncValue.guard(() async {
return _fetchActivity(this.random);
});
}
매개변수를 random으로 받아 재요청을 하는곳에서 이미 완료된코드 (중복호출)이라는것에서 우선 요청하는곳을 주석처리를 해도 코드가 작동하고 있던 것이었다.
조금 더 깊게 생각을 해보니 랜덤 숫자가 재 생성이되면 참조하고 있는 rebuild쪽에서도 영향이 갈것 같다 생각이 들었다.
https://riverpod.dev/ko/docs/essentials/combining_requests
공식문서에도 적혀있는 문제였다.
나는 랜덤 숫자를 매개변수로 넘겨서 진행하였고 요청 결합이라는 내용에서 랜덤 숫자는 요청이 아니라 생각하여 읽지 않았던 문제다.
이를 위해 provider의 결과를 다른 provider에게 매개변수(parameter)로 전달하여 요청에 인자 전달하기 메커니즘을 사용할 수 있습니다.
하지만 이 접근 방식에는 몇 가지 단점이 있습니다:
. . .
(생략)
. . .
이를 개선하기 위해 Riverpod은 요청을 결합하는 다른 접근 방식을 제공합니다.
매개변수로 받던 코드를 제거후에 ref.watch 코드를 넣어주었다.
// 재요청 메서드
Future<void> rebuild() async {
final random = ref.watch(randomNumberProvider);
state = const AsyncValue.loading(); // 상태를 로딩 중으로 설정
state = await AsyncValue.guard(() async {
return _fetchActivity(random);
});
}