상태 관리(State management)란?
상태 관리는 애플리케이션의 데이터 또는 UI 상태를 적절히 관리하는 것을 의미합니다.
Flutter에서 상태 관리는 특히 중요한데, UI를 동적으로 업데이트하고 사용자와의 상호작용에 따라 데이터를 변경해야 하기 때문입니다.
상태 관리를 통해 개발자는 애플리케이션의 상태 변화를 효율적으로 관리하고, 코드의 가독성을 높이며, 유지 보수를 용이하게 할 수 있습니다.
Flutter에는 여러 상태 관리 방법이 있으며, 그 중에서도 Riverpod은 Flutter의 강력한 상태 관리 패키지 중 하나 입니다.
이번 포스팅에서는 Flutter에서의 상태관리와 Riverpod에 대해 간략히 소개 하고 다음 포스팅에서 Riverpod을 사용하는 방법에 대해 포스팅하겠습니다.
Flutter에서의 상태 관리 방법
개요
Flutter에서는 크게 두 가지 유형의 상태를 관리합니다: 로컬 상태(local state)와 앱 상태(app state).
- 로컬 상태:
- 단일 위젯 내에서 관리되며, 위젯(Widget)의 빌드 method 내에서만 관리되는 상태입니다.
- 예를 들어,
StatefulWidget의 상태는 로컬 상태 관리의 전형적인 예입니다.
- 앱 상태:
- 여러 위젯 간에 공유되는 Global 상태로, 앱 전체에서 필요로 하는 데이터를 포함합니다.
- 예를 들어, 로그인 상태, 사용자 선호도, 쇼핑 카트의 내용 등이 이에 해당합니다.
Flutter에서 상태 관리를 위해 여러 패키지와 패턴이 사용됩니다. 이 중 Riverpod, GetX, BLoC는 가장 인기 있는 상태 관리 패키지입니다.
Riverpod vs GetX vs BLoC
위 3개 패키지가 Flutter에서 가장 많이 사용되는 3개 상태 관리 패키지로 사실 본인도 Riverpod만 사용해봤기에 어느 것이 더 좋다고 말하기는 곤란합니다.
특징 비교
| 기능/패키지 | Riverpod | GetX | BLoC |
|---|---|---|---|
| 의존성 관리 | 위젯 트리와 독립적 | 간단한 API로 의존성 주입 가능 | 중간 – 높은 설정 필요 |
| 상태 관리 | 컴파일 타임 안전성, 유연성 | 간결한 문법, 빠른 개발 | 이벤트 스트림을 통한 상세한 제어 |
| 타입 안전성 | 높음 | 중간 – 높음 | 높음 |
| 학습 곡선 | 비교적 높음 | 낮음 | 높음 |
| 커뮤니티 지원 | 성장 중 | 매우 활성화 | 매우 활성화 |
Google Trend 분석
- Riverpod와 BLoC는 비슷한 비율로 사용되며, 타입 안전성과 상세한 상태 관리 제어를 중시하는 개발자들 사이에서 선호됩니다.
- GetX는 그 사용의 간결함과 빠른 개발 속도 때문에 높은 비율을 차지합니다. 이는 특히 빠른 프로토타이핑이 필요한 프로젝트에서 유용합니다.
Riverpod 소개
개요
Riverpod는 Flutter의 상태 관리를 위해 설계된 라이브러리로, Provider 패키지의 후속작이자 개선 버전입니다.
Provider를 사용하는 개발자들의 경험을 바탕으로, 더 유연하고 안전한 상태 관리를 가능하게 하는 여러 기능이 추가되었습니다.
개발 배경 (Motivation)
Riverpod는 Provider의 제한 사항을 극복하고, 더 나은 개발 경험을 제공하기 위해 만들어졌습니다.
Provider가 Flutter 위젯 트리에 의존하는 반면, Riverpod는 이러한 의존성을 제거하여 더욱 유연한 상태 관리가 가능하게 합니다.
비동기 데이터 관리의 복잡성을 해결하기 위해 등장한 상태 관리 라이브러리로 기존 상태 관리 방식의 한계를 넘어, Flutter 위젯 시스템에서 영감을 받아 비즈니스 로직을 위한 새롭고 유연한 방식을 제공합니다.
이를 통해 개발자는 복잡한 비동기 작업을 쉽게 처리하고, UI 개발에 보다 집중할 수 있게 됩니다.
당겨서 새로 고침, 무한 스크롤, 오프라인 모드 등 사용자 경험을 향상시키는 기능들을 기본적으로 지원합니다.
장점
- 위젯 트리와의 독립성:
- Riverpod는 위젯 트리와 독립적으로 작동하기 때문에, 어플리케이션의 어느 곳에서나 쉽게 상태를 관리하고 접근할 수 있습니다.
- Widget과 Widget Tree에 대해서는 아래 포스팅 참조
: (Flutter-기초 강의) 6.StatelessWidget & StatefulWidget, Scaffold 란 무엇인가?
- 타입 안전성:
- Riverpod는 컴파일 타임에 타입 체크를 강화하여 런타임 에러를 줄여줍니다.
- 테스트 용이성:
- 독립적인 상태 관리 덕분에 단위 테스트가 더욱 용이해집니다.
- 커스텀 가능성:
- 사용자의 필요에 맞게 상태 관리 방식을 자유롭게 커스텀할 수 있습니다.
단점
- 학습 곡선 (Learning Curve):
- Provider에 비해 더 많은 개념과 기능을 제공하기 때문에, 초보자에게는 학습 곡선이 다소 가팔라질 수 있습니다.
- 문서와 자료:
- 비교적 새로운 라이브러리이기 때문에, 아직까지는 Provider보다는 문서화와 커뮤니티 자원이 적을 수 있습니다.
Provider vs Riverpod
Riverpod이 Provder를 계승한 만큼 사용방법에 상당한 유사점이 있지만 Riverpod은 Provider 사용에 대해 많은 점을 개선하였는데 그 차이는 다음과 같습니다.
비교
| 기준 | Provider | Riverpod |
|---|---|---|
| 설계 철학 | 단순함과 접근성에 중점 | 확장성, 안전성, 테스트 용이성에 중점 |
| 컨텍스트 의존성 | context에 의존 | context에 의존하지 않음 |
| 리팩토링 | 위젯 트리 변경 시 리팩토링 필요할 수 있음 | 위젯 트리와 독립적으로 사용 가능 |
| 상태 접근 | Provider.of(context)로 접근 | watch, read 메서드로 접근 |
| 오류 처리 | 컨텍스트를 잘못 사용하면 오류 발생 가능 | 컴파일 타임에 오류를 잡을 수 있음 |
| 선언 위치 | 위젯 트리 내부 | 전역 또는 로컬 |
| 상태 재사용성 | 상태 재사용 어려움 | 상태 재사용 용이 |
| 테스트 용이성 | 테스트하기 어려울 수 있음 | 테스트하기 쉬움 |
Context 의존이란?
Flutter에서 Provider는 위젯 트리 내의 특정 위치에 접근하기 위해 BuildContext를 사용합니다.
이는 상태를 읽거나 변경할 때 현재 위젯의 위치(Context)에 의존한다는 의미입니다.
반면, Riverpod는 Context에 의존하지 않고 독립적인 Provider를 통해 어플리케이션의 어느 곳에서나 상태에 접근할 수 있도록 설계되었습니다.
이로 인해 Riverpod는 더 유연하고 예측 가능한 상태 관리를 가능하게 하며, 위젯 트리의 구조에 구애받지 않고 사용할 수 있습니다.
예를 들어 Provider는 Context를 사용하기에 Widget 방식으로 사용하게 되고 Riverpod은 ProviderScope를 사용해서 Conetxt에 의존적이지 않은 상태관리 범위를 정해줍니다.
설계 철학
- Provider는 가능한 단순하게 상태 관리를 할 수 있도록 설계되었습니다. 이로 인해 쉽게 배우고 사용할 수 있지만, 복잡한 애플리케이션에서는 제한적일 수 있습니다.
- Riverpod는 Provider의 한계를 극복하기 위해 만들어졌으며, 안전성과 테스트 용이성, 그리고 확장성에 더 중점을 두고 설계되었습니다.
컨텍스트 의존성과 리팩토링
- Provider는 컨텍스트(Context)에 의존하여 상태에 접근하는 방식을 사용합니다. 이는 위젯 트리가 변경될 때 리팩토링이 필요할 수 있습니다.
- Riverpod는 컨텍스트에 의존하지 않는 접근 방식을 채택하여, 애플리케이션의 어느 곳에서나 동일하게 상태에 접근할 수 있게 합니다. 이는 리팩토링 시 유연성을 제공합니다.
오류 처리
- Provider에서는 컨텍스트를 잘못 사용하면 런타임 오류가 발생할 수 있습니다.
- Riverpod는 상태 관리 코드가 컴파일 타임에 검증되므로, 오류를 더 일찍 발견하고 수정할 수 있습니다.
