인프런 커뮤니티 질문&답변

Provider를 사용하는 이유는 가장 근본에 가깝기 때문입니다.

라이브러리 없이 Dart의 ChangeNotifier 와 Flutter의 InheritedWidget 조합으로 상태관리를 할 수 있습니다. 하지만 보일러플레이트 코드가 너무나도 많고 InheritedWidget 부분을 미리 만들어 주는 라이브러리가 Provider 입니다.

근본을 알고 있다면 다른 라이브러리를 사용하는데에 문제가 없지만, Riverpod 으로 입문을 했다면 Riverpod 특유의 매직(?) 스러움이 있어서 오히려 근본을 이해하기 어려울 수 있다고 생각합니다.

더구나 code generation 을 사용한다면 더욱더 매직 코드가 많아지는데, 매직이라고 표현한 부분은 Riverpod 에서의 provider 는 top-level 에 작성함에도 실제로는 클래스로 생성된다는 점, BuildContext가 아닌 WidgetRef를 왜 사용하는지 등입니다. 이는 사용하는데에는 문제 없을지 몰라도, 동작 원리를 이해하는데에는 방해가 될 수 있고, 근본적인 상태관리를 이해하는데 장해물이 된다고 생각했습니다.

그래서 제 오프라인 강의에서는 상태관리 라이브러리를 도입하지 않고 상태관리를 충분히 기본 API만으로 사용해 본 후에 최대한 나중에 라이브러리를 도입합니다. 그와중에 그나마 Provider 가 근본에 가까워서 먼저 합니다. 결국 모든 라이브러리의 목적이 동일하며 근본을 알면 어떤 라이브러리를 사용해도 상관이 없습니다. 궁극적으로 나중에 다른 라이브러리로 교체하는 것에 문제가 없어야 한다고 봅니다. 그렇지 않다면 내가 특정 라이브러리에 매몰되어 있는 것은 아닌가 생각해 볼 필요가 있습니다.

혹시 Riverpod 이 Provider 의 어떤 점을 개선하려고 만든 것인지 정확하게 말할 수 있는지 생각해 보시고, 정확히 말할 수 없다면

최근 리뉴얼한 제 강의 중 'Flutter 초급 - http 통신, 상태관리' 에서 상태관리를 근본부터 하나씩 빌드업하여 4대 라이브러리 (Provider, Bloc, GetX, Riverpod)를 살펴보고 왜 학습에 Provider를 선택했는지를 설명하고 있으니 참고하시기 바랍니다.