[Riverpod] 0. Riverpod overview

https://riverpod.dev/ko/docs/essentials/passing_args

요청에 인자 전달하기 | Riverpod

공식문서중 Introduction 과 Essentials 항목의 문서들을 읽어보고 전체적으로 요약해보았다.

네모 블럭으로 감싼 영문은 문서의 내용을 발췌하였거나, Rivderpod 코드의 주석문의 내용을 발췌하였다.

 

Flutter 를 사용하다 보면, 전역변수처럼 여러 스크린 사이에서 데이터를 공유해서 사용해야 할 때가 있다.

이를 구현하는 방법에는 여러가지가 있는데,

 

0. 화면마다 일일이 직접 파라미터 형태로 전달한다. 번거롭고, 유지보수관리가 힘들어진다.

1. Provider 를 사용한다. 0번 방식을 해결하기 위해 flutter 에서 내장된 기능이다.

2. RiverPod 를 사용한다. 외부 패키지이며, 사실상 Provider.version 2 로 여겨진다.

Riverpod 공식문서에서도 provider 를 대체하고자 나왔으며

그런 의미에서 Provider 의 anagram 인 RiverPod 로 작명하였다.

AsyncProvider, NotiferProver 등 ~~Provider 라는 이름은 동일하지만 사용하는 API 가 다르다

 

Provider 는 데이터 혹은 함수를 앱 전역으로 노출하기 위한 수단이다.

 

Riverpod (anagram of [Provider](https://pub.dev/packages/provider)) is a reactive caching framework for Flutter/Dart.

Using declarative and reactive programming, Riverpod takes care of a large part of your application's logic for you. 

It can perform network-requests with built-in 
error handling and caching, while automatically re-fetching data when necessary.

 

RiverPod 는 다음의 문제들을 쉽게 처리하기 위해 등장했다고 소개한다.

- pull to refresh
- infinite lists / fetch as we scroll
- search as we type
- debouncing asynchronous requests
- cancelling asynchronous requests when no-longer used
- optimistic UIs
- offline mode

 

몇 가지 디테일한 사항들은 다음과 같다.

- The network request will not be executed until the UI reads the provid'er at least once.

Providers are "lazy". Defining a provider will not execute the network request. Instead, the network request will be executed when the provider is first read.

- Subsequent reads will not re-execute the network request, but instead return the previously fetched activity.
- If the UI stops using this provider, the cache will be destroyed. Then, if the UI ever uses the provider again, that a new network request will be made.

 

Provider 중에서 NotifierProvider 라는 것이 있는데, 말 그대로 Notifier 를 노출하는 Provider 이다.

Notifier 는 build 메서드를 필수로 오버라이드 해야 하며,

build 메서드는 외부에서 호출하지 않으며 Notifier를 초기화한다.

그리고 Notifier 의 메서드를 작성하면, NotifierProvider 를 통해 노출한 해당 Notifier 의 메서드를 몇 가지 방법들을 통해

전역으로 접근하는 것이 가능해진다.

 

Notifier 를 Stateful widget 과 비교하여 생각해 볼 수 있는데,

Notifier 에서 build 메서드에서는 특정 데이터를 초기화 하고,

사용자 정의 메서드에서는 해당 데이터를 변경, 데이터 변경을 알리는 로직을 추가할 수 있다.

데이터가 변경되었는지 특정 방법들을 통해 listen할 수 있는데, 

이러한 listener 들이 데이터가 변경되었다면 리스너 스스로를 리빌드한다.

 

아래는 Notifier 의 build 메서드에 대한 원문 발췌내용이다.

The build method (of Notifier)

All notifiers must override the build method.
This method is equivalent to the place where you would normally put your logic in a non-notifier provider.

This method should not be called directly.

 

 

Notifier 는 여러 메서드를 주렁주렁 달아서 쓸 때 쓰고, 그정도로 복잡하지 않은 구조라면

Provider 만으로도 로직을 구현하여 쓸 수도 있다.

# The syntax for defining a Provider
final name = SomeProvider.someModifier<Result>((ref) { <your logic here> });

This is where we place the logic of our providers. This function will be called when the provider is first read.
Subsequent reads will not call the function again, but instead return the cached value.

 

참고로

SomeProvider 는 AysncProvider, NotifierProvider 처럼 Provider 의 종류이고.

someModifier 는 .family 나 .autoDispose 같은 옵션이다.

.family는 Provider의 생성자에 파라미터를 전달하는데 사용.

.autoDispose는 위젯트리상에 해당 Provider가 더이상 사용되지 않는 때를 자동으로 감지하여 Provider 를 폐기하는 옵션이다.

 

 

기본적으로 Provider 가 관리하는 데이터는 로컬캐시로 저장된다.

.autoDispose 를 통해 더이상 사용되지 않는 Provider 의 캐시는 자동으로 삭제되게끔 옵션을 추가할 수 있다.

물론 수동으로 지울 수도 있고, 강제로 지우는 것도 가능하다.

더 자세한 내용은 공식문서 Clearing cache and reacting to state disposal 에 설명되어있다.

network-request 라는 단어는 Provider 의 데이터를 network 상에서 data fetch 로 받아오는 상황을 전제로 하기에 사용된 듯 하다.

 

RiverPod 는 데이터를 노출하여 여러 위젯에서 쉽게 엑세스하기 위해 사용되는 외부 라이브러리이지만,

구현하기에 따라 최적화도 가능하다.

 

개요만 정리하자면, 외부 데이터를 받아오는 위젯을 화면을 렌더링하는 위젯과 분리하고

데이터 fetch 위젯에 provider 를 적용하면 데이터가 변경될 시 그 위젯만 다시 rebuild 된다.