현재는 사실 GetX에 더 익숙한 편이지만, 개발을 위한 개발을 하는 자에게는 GetX는 정말 해로운 상태관리 툴이라는 걸 많이 깨닫고 있다. GetX에게 돌을 던지는 자가 그리 많다면 왜 가장 인기가 많은 패키지로 pub.dev에 자리잡고 있는걸까? 현재 기준 1위, 11900개가 넘는 Likes를 받았다.. (이 부분에 대해서는 따로 글을 써보려고 한다.)
Riverpod을 공부하면서 실제 상용 앱에 아직 써본 적은 없지만, 적용해보기 위해 노력하는 중이다. Riverpod은 Provider 개발팀에서 Provider의 이슈를 해결하기 위해 별도로 개발한 상태관리 패키지다. 따라서, Provider 패턴을 기반으로 구현되어 있는데, Provider 패턴의 단점을 보완하며, 상태 관리를 보다 쉽고 간편하게 할 수 있게 해준다.
장점:
1. 코드 양 감소: Riverpod은 Provider 패턴과 비교해서도 코드 양을 줄일 수 있다. Provider 패턴에서 사용되는 ChangeNotifierProvider나 StreamProvider에 비해, Riverpod은 매우 간단한 문법을 가지고 있다.
2. 가독성 향상: Riverpod은 코드 양이 감소하면서도 가독성을 유지할 수 있다. 코드의 가독성이 향상된다면, 유지 보수성도 높아지는 장점이 있다.
3. 테스트 용이성: Riverpod은 테스트 용이성을 고려하여 설계되어서, 테스트 코드를 작성할 때도 쉽게 활용할 수 있으며, 테스트 코드 작성이 훨씬 간단해진다.
단점:
1. 러닝커브가 높다: Riverpod은 초보자에게는 러닝커브가 높을 수 있다. Provider 패턴에 익숙한 경우, Riverpod의 문법과 사용방법을 익히는 데 시간이 걸릴 수 있다.
어제 해외 개발자 커뮤니티를 보다가 Riverpod이 다들 어렵다는 글을 찾았다.
Am I super dumb or is Riverpod SO complicated?
2. 상태 관리 규모에 따른 적합성: Riverpod 특유의 복잡성 때문에 상태 관리 규모가 커질수록 더욱 효과적일 것 같다는 생각이 든다. 작은 규모의 앱에서는 다른 상태 관리 패키지를 사용하는 것이 더 효율적일까?
3. 코드 유지보수: Riverpod은 상태 관리를 위해 전역으로 상태를 관리하기 때문에, 코드 유지보수에 대한 고민이 필요합니다. 전역으로 상태를 관리하기 때문에, Select 등 효율 최적화에 대한 고민도 함께 필요해 보인다.