[Flutter] Riverpod 정리..

 

Provider 타입	상태 변경 가능?	사용 예시
Provider (@riverpod 기본 함수)	❌ 읽기만 가능	ref.watch(isLoadingProvider)
StateProvider	✅ 가능	ref.read(isLoadingProvider.notifier).state = true;
@riverpod class (StateNotifier)	✅ 가능	ref.read(isLoadingProvider.notifier).set(true);

 

 

provider를 정의하는 구문은 다음과 같습니다:

(상태를 읽기만 할 수 있는 불변 값)

@riverpod
Result myFunction(Ref ref) {
  <your logic here>
}

 

어노테이션된 함수(annotated function)

어노테이션된 함수의 이름에 따라 provider와 상호작용하는 방식이 결정됩니다.
주어진 함수 myFunction에 대해 생성된 myFunctionProvider 변수가 생성됩니다.

어노테이션된 함수는 첫 번째 매개변수로 "ref"를 지정해야 합니다.
그 외에도 함수는 제네릭을 포함하여 여러 개의 매개변수를 가질 수 있습니다. 이 함수는 원할 경우 Future/Stream을 반환할 수도 있습니다.

이 함수는 provider를 처음 읽을 때 호출됩니다.
이후 읽기는 함수를 다시 호출하지 않고 대신 캐시된 값을 반환합니다.

 

import 'dart:convert';
import 'package:http/http.dart' as http;
import 'package:riverpod_annotation/riverpod_annotation.dart';
import 'activity.dart';

// 코드 생성이 작동하는 데 필요합니다.
part 'provider.g.dart';

/// 그러면 이 함수의 결과를 캐시할
/// `activityProvider`라는 provider가 생성됩니다.
@riverpod
Future<Activity> activity(Ref ref) async {
  // package:http를 사용하여 Bored API에서 임의의 activity를 가져옵니다.
  final response = await http.get(Uri.https('boredapi.com', '/api/activity'));
  // 그런 다음 dart:convert를 사용하여 JSON 페이로드를 맵 데이터 구조로 디코딩합니다.
  final json = jsonDecode(response.body) as Map<String, dynamic>;
  // 마지막으로 맵을 Activity 인스턴스로 변환합니다.
  return Activity.fromJson(json);
}

 

✅ 예제: 일반 Provider vs @riverpod 버전

1. 기존 방식

final nameProvider = Provider<String>((ref) => '홍길동');

2. @riverpod 방식 (codegen)

import 'package:flutter_riverpod/flutter_riverpod.dart';

part 'my_provider.g.dart'; // 중요!

@riverpod
String name(NameRef ref) {
  return '홍길동';
}

이렇게 하면 자동으로 nameProvider가 생성!

✅ 차이점 정리

항목	@riverpod 방식	기존 방식
코드 길이	더 짧고 간결함	좀 더 길고 구조적
코드 생성	필요 (build_runner)	필요 없음
타입 안전성, 자동완성	매우 좋음	괜찮음
유지보수	대규모 프로젝트에 유리	초반은 단순함

 

✅ 한 줄 요약

@riverpod으로 만든 counterProvider는 기존의 StateNotifierProvider와 StateNotifier를 더 깔끔하게 자동으로 만들어주는 방식이에요.

 

 

Notifiers는 providers의 "상태저장 위젯(stateful widget)"입니다. provider를 정의하는 문법을 약간 수정해야 합니다.
이 새로운 문법은 다음과 같습니다:

@riverpod
class MyNotifier extends _$MyNotifier {
  @override
  Result build() {
    <your logic here>
  }
  <your methods here>
}

 

@riverpod
class TodoList extends _$TodoList {
  @override
  Future<List<Todo>> build() async {
    // 이전에 FutureProvider에 있던 로직이 이제 build 메서드에 있습니다.
    return [
      Todo(description: 'Learn Flutter', completed: true),
      Todo(description: 'Learn Riverpod'),
    ];
  }
}

어노테이션(annotation)

모든 providers는 @riverpod 또는 @Riverpod()로 어노테이션해야 합니다. 이 어노테이션은 전역 함수나 클래스에 배치할 수 있습니다.
이 어노테이션을 통해 provider를 설정(config)할 수 있습니다.

예를 들어, @Riverpod(keepAlive: true)를 작성하여 "auto-dispose"(나중에 살펴볼 것임)를 비활성화할 수 있습니다.

 

Notifier

@riverpod 어노테이션이 클래스에 배치되면 해당 클래스를 "Notifier"라고 부릅니다.
클래스는 _$NotifierName을 확장해야 하며, 여기서 NotifierName은 클래스 이름입니다.

Notifiers는 provider의 상태(state)를 수정하는 메서드를 노출할 책임이 있습니다.
이 클래스의 공개 메서드는 ref.read(yourProvider.notifier).yourMethod()를 사용하여 consumer가 액세스할 수 있습니다.

UI에서 상태가 변경되었음을 알 수 있는 수단이 없기 때문에, Notifiers에는 기본 제공 'state' 외에 공개 속성이 없어야 합니다.

 

 

✅ 지금 Riverpod 2.0에서 실제로 "핵심적으로 쓰는 것"

✅ 1. @riverpod + 함수

@riverpod
String name(NameRef ref) => '홍길동';

 

👉 기존의 Provider 기능을 자동 생성

✅ 2. @riverpod + Notifier 클래스

@riverpod
class Counter extends _$Counter {
  @override
  int build() => 0;

  void increment() => state++;
}

 

 👉 기존의 StateNotifierProvider + StateNotifier` 조합을 대체

 

과거 방식	2.0 방식 방식
Provider	@riverpod 함수
StateNotifierProvider	@riverpod class extends _$...
StateProvider	거의 그대로 사용 가능하지만 코드 생성은 없음

 

✅ 실제로 대부분의 경우, Riverpod 2.0에서는 @riverpod 기반의 Provider랑 Notifier 두 가지만으로 충분합니다.

형태 역할 대체되는 전통적 Provid

형태	역할	대체되는 전통적 Provider
@riverpod 함수	읽기 전용 값, 계산된 값	Provider, FutureProvider, StreamProvider
@riverpod class extends _$Notifier<T>	동기 상태, 로직 포함	StateNotifierProvider
@riverpod class extends _$AsyncNotifier<T>	비동기 상태 (API 등)	FutureProvider, AsyncNotifier, StreamProvider

 

✅ 그래서 실제로 필요한 건

1. @riverpod 함수
   → Provider, FutureProvider, StreamProvider 대체 가능
2. @riverpod class extends _$Notifier<T>
   → StateNotifierProvider 대체
3. (옵션) @riverpod class extends _$AsyncNotifier<T>
   → 비동기 작업이 필요한 경우만 사용

❓그럼 StateProvider는?

• 여전히 아주 간단한 상태 (토글, 숫자 등) 에는 편해서 쓸 수 있어요.
• 하지만 구조적으로 더 깔끔하게 관리하려면 Notifier로 전환하는 게 좋아요.

✅ 한 줄 정리

지금 Riverpod 2.0에서는 @riverpod 기반의 Provider와 Notifier (필요 시 AsyncNotifier)만으로 대부분의 상태 관리가 끝나요.

 

지금 Riverpod 2.0에서는 @riverpod 코드 생성 기반 구조가 대부분을 대체하지만,
StateProvider만큼 간단한 기능을 정확히 대체하는 구조는 없습니다.

 

 

✅ 왜 StateProvider는 대체되지 않았을까?

이유	설명
너무 단순함	숫자 하나, bool 하나 상태 관리할 때 딱 좋음
별도 클래스 불필요	Notifier처럼 클래스 안 만들고 한 줄로 끝냄
빠르게 테스트용 상태 만들기 좋음	UI 테스트나 임시 상태에 유리

 

✅ 정리: 현재 구조에서의 역할 분담

목적	추천 방식	비고
단순한 값 (int, bool 등)	✅ StateProvider	여전히 유용함
읽기 전용 값	✅ @riverpod 함수	기존 Provider 대체
로직 포함 동기 상태	✅ @riverpod + Notifier	기존 StateNotifier 대체
비동기 상태	✅ @riverpod + AsyncNotifier	기존 FutureProvider 등 대체

 

✅ 한 줄 요약

StateProvider는 현재도 대체되지 않았고, Riverpod 2.0에서도 여전히 살아 있는 "심플한 상태 관리 도구"예요.

 

필요하다면 아래처럼 Notifier로 StateProvider처럼 흉내내는 것도 가능하지만…
솔직히 너무 오버엔지니어링이에요 😅

@riverpod
class SimpleInt extends _$SimpleInt {
  @override
  int build() => 0;

  void set(int value) => state = value;
  void increment() => state++;
}

 

 

 

StatelessWidget/StatefulWidget이 Consumer를 반환하는 코드를 작성하는 대신 ConsumerWidget/ConsumerStatefulWidget을 정의할 수 있습니다.
ConsumerWidget과 ConsumerStatefulWidget은 사실상 StatelessWidget/StatefulWidget과 Consumer를 결합한 것입니다. 이들은 원래의 짝과 동일하게 동작하지만 "ref"를 제공한다는 추가적인 이점이 있습니다.

 

ConsumerWidget

/// "StatelessWidget" 대신 "ConsumerWidget"을 서브클래스화했습니다.
/// 이는 "StatelessWidget"을 만들고 "Consumer"를 재조정하는 것과 같습니다.
class Home extends ConsumerWidget {
  const Home({super.key});

  @override
  // 이제 "build"가 추가 매개변수 "ref"를 받는 방식에 주목하세요
  Widget build(BuildContext context, WidgetRef ref) {
    // "Consumer"를 사용했을 때와 마찬가지로 위젯 내부에서 "ref.watch"를 사용할 수 있습니다.
    final AsyncValue<Activity> activity = ref.watch(activityProvider);

    // 렌더링 로직은 동일하게 유지됩니다.
    return Center(/* ... */);
  }
}

 

ConsumerStatefulWidget

// ConsumerStatefulWidget을 확장합니다.
// 이것은 "Consumer" + "StatefulWidget"과 동일합니다.
class Home extends ConsumerStatefulWidget {
  const Home({super.key});

  @override
  ConsumerState<ConsumerStatefulWidget> createState() => _HomeState();
}

// "State" 대신 "ConsumerState"를 확장한 것을 볼 수 있습니다.
// 이것은 "ConsumerWidget" 대 "StatelessWidget"과 동일한 원리를 사용합니다.
class _HomeState extends ConsumerState<Home> {
  @override
  void initState() {
    super.initState();

    // 상태 수명 주기에도 "ref"에 액세스할 수 있습니다.
    // 이를 통해 특정 provider에 리스너를 추가하여 대화 상자/스낵바를 표시하는 등의 작업을 수행할 수 있습니다.
    ref.listenManual(activityProvider, (previous, next) {
      // TODO 스낵바/대화 상자 표시
    });
  }

  @override
  Widget build(BuildContext context) {
    // "ref"는 더 이상 매개변수로 전달되지 않고 대신 "ConsumerState"의 프로퍼티가 됩니다.
    // 따라서 "build" 내에서 "ref.watch"를 계속 사용할 수 있습니다.
    final AsyncValue<Activity> activity = ref.watch(activityProvider);

    return Center(/* ... */);
  }
}