[flutter] 1년 반 동안 써보고 느낀 riverpod 의 단점
모던 플러터 개발에서는 riverpod 이 대세다.
riverpod 0점대 버전부터 2.2가 나온 지금까지 riverpod 을 쓰면서 느낀 단점들을 써보려고 한다.
참고로 나의 상태관리 플러그인 호감도 순서는 이렇다.
getx(불호) <<< riverpod <= bloc < provider < get_it (가장 호)
50%의 재미를 위한 약간의 riverpod ‘억까’ 가 있을 수 있다는 점에 주의하자.
riverpod이 나오기 이전으로 돌아가보면,
플러터 개발진, 플러터 GDE 들, 공식 디스코드, 레딧을 포함한 공식 플러터 커뮤니티들에서는 Provider를 많이 지지했었다.
대중적인 점유율에서 get 에게는 밀리고 있었지만, provider 에 의존성을 가지는 bloc 까지 포함해서 provider 진영이라고 합친다면 get에 크게 밀리는 것 까진 아니었다.
Provider 진영에서는 getx 를 많이 싫어한다.
이건 많이 알고 있는 사실이다. 어느 정도까지 싫어하는 지는 잘 모를 수 있는데.
디스코드에서 그냥 getx 만 검색해보면 나오는게 이런 것들이다.
다음 채팅이 채널 분위기를 요약해주는 것 같다. https://discord.com/channels/420324994703163402/421444918276390912/1075828148131864618
뒤에 달린 답변을 보면, 한국식으로 하면 소위 ‘병먹금’ 이다. 근데 최초에 어그로를 끈 Robo 도 애플 리뷰시간 어쩌구 하는 걸 보면 일부러 저러는 건지 알 수 없다.
이젠 getx는 까이고 까이다 못해 거의 웃음벨 급의 밈이 되버린 것 같다.
놀라운 건 이런 것들이 내가 getx 까들을 찾으려고 노력한게 아니라, 그냥 글을 쓰는 지금 이 순간에 get 검색하면 나오는 검색 결과에서 맨 위 3개를 가져온 것이라는 거다. 나머지도 저런 느낌이다. Robo처럼 어그로를 끌지 못하는 단순한 getx 질문들은 가볍게 무시당하고 있다.
?statemgmt 라고 명령어를 치면 추천하는 상태관리 패키지들이 쭉 나온다. 요즘은 그 중에서 riverpod 을 추천해준다. riverpod은 괜찮나?
아이러니: riverpod 은 getx 를 따라가고 있다.
사람들은 getx 를 왜 비판했는가? getx에 대한 비판은 riverpod 에게도 적용해볼 수 있다.
- 플러터를 배우는 게 아니라 getx를 배우게 만든다. 웹에서 wordpress 같은 존재가 플러터에서 getx 이다. (= getx 만의 생태계를 배워야 한다.)
riverpod 또한 마찬가지다. riverpod을 제대로 쓰려면 기존 flutter 프레임워크에 없는 hook을 배워야 하고, StateNotifier 같은 새로운 개념들, 많은 Provider들을 배워야 한다. 그리고 ConsumerWidget 같은 새로운 위젯들까지 익혀야 한다.
2. 좋은 도큐먼트의 부재.
riverpod 또한 2.0 에 관한 문서가 부족하다.
3. BuildContext 같은 플러터의 핵심적인 부분을 배우지 못하게 만든다.
riverpod 또한 ref를 통해서 context 에서 자유로워 진다.
4. 패키지에 의존적으로 만들어서 나중에 대체하기 어렵게 만든다.
riverpod 또한 마찬가지다. 나중에 riverpod 에서 provider 로 바꾼다고 생각해보자. 모든 consumerwidget, ref, providercontainer 등등 거의 대부분의 코드가 빨간 줄이 그어질 것이다.
물론 이런 점들이 getx 와 비교하면 상대적으로 덜하지만 그래도 단점을 공유하고 있다.
어쩌면 getx 보다 안 좋은 점
getx보다 호불호가 더 갈리는 부분은 전역(top-level) 에 provider 를 선언해버리는 다는 점인데, 이는 다트의 전역 변수는 lazy-loading 된다는 점을 이용하기 위한 것이다.(https://github.com/rrousselGit/riverpod/issues/202#issuecomment-719520723)
이유가 어떻든 클래스 안에 들어있지 않은 코드들이 import 만으로 다른 파일에서 사용된다는 것은 관리를 어렵게 만든다. 특히 한 파일에 provider 가 여러 개 들어있는 경우라면, 특정 provider 가 어느 위젯에서 쓰이고 있는지 파악하는 것은 매우 어렵다.
물론 테스팅이나 문서의 퀄리티 등등에서 riverpod이 getx 보다는 좋은 선택이다.
그럼 대체 뭐 어쩌라고요?
그렇다. riverpod 이 가까운 미래에 플러터 프레임워크에 공식적으로 흡수되는게 아니라면, 플러터로 개발하는 우리는 큰일난 것 일수도 있다.
위에서 이런 패키지들을 언급했는데
getx(불호) <<< riverpod <= bloc < provider < get_it (가장 호)
이미 단점을 말한 getx, riverpod 을 빼고도, 상황이 좋지 않다.
provider : 지원 중단. provider 는 Remi가 곧 deprecated 될 수 있다고 선언했음. (참고 : https://pub.dev/packages/riverpod)
bloc: provider에 의존성을 가짐
get_it : 관리 안됨. 7.3 버전이 github에는 나왔지만 pub에는 7.2 로 방치된 채 1년 반이 흐름.
그러니, 최대한 플러그인 의존도를 줄여야 한다.
전역 상태관리가 필요한 부분에서만 사용하고 지역 상태관리에는 setState() 를 적극적으로 활용해야 한다. FutureBuilder, StreamBuilder, ValueNotifier, ValueListenableBuilder, InheritedWidget(!?) 같은 바닐라 방식을 적극 활용해야 한다.
하지만 쉽지 않을 것이다. 우린 이미 riverpod 의 맛을 보았고, riverpod 중독자가 되었다.
다음에 기회가 된다면 개인적으로 제일 의존성이 덜하다고 생각하는 (get_it 또는 provider) + ValueNotifier + ValueListenableBuilder 를 이용한 상태관리에 대해서 글을 써보려고 한다.
결론
riverpod은 getx 보다는 낫다.
최대한 의존성을 줄이고 바닐라 코드를 이용해 보려고 애쓰자.
/// 추가 : riverpod 을 쓰기 전에 아래 글을 읽어보시는 것을 강력히 추천합니다.
