Riverpod Study

riverpod 독스를 모두 읽었다.

이전에 riverpod독스를 훑어봤을때랑 다르게 code generation을 이용한 API변경과 custom_lint 패키지를 이용한 린트룰까지 적용해주는 것을 보고 많은 발전이 있었구나 하고 생각했다.

그리고 flutter_hooks에 대하여 예전엔 약간 Flutter에서도 이걸 써야하나 라는 생각이 들었는데, 다시 보니 API가 간단해서 좋아보였다.

React에서 hook에 부정적인 것들을 쓰며 발견해서 Flutter에선 Flutter만의 스타일을 고수하는 것이 좋지 않을까? 라고도 생각했는데, API가 편하긴 편하다.

이것은 riverpod과 함께 쓸 때 더 도움이 될 것 같다.

일단 rebuild에 대하여 short circuit이나 const constructor로직으로 인해 플루터는 React보단 상당히 안정적인 성능을 보장한다고 여겨지기 때문에 hook을 써서 위젯 전체가 rebuild되어도 많은 성능적 단점이 없을것 같다는게 내 결론이다.

그리고 Flutter는 원래 빠르니까…

또한 Consumer나 HookConsumer를 이용해 원한다면 마치 StatefulBuilder의 이점과도 유사하게 한 위젯 내에서도 rebuild될 부분만 따로 분리하여 최적화를 할 수 있다는 점이 마음에 든다.

사실 이를 완전히 방지하는 법은 Widget을 적절히 리팩토링하여 분리하는 것에 있을지도 모르지만, Flutter는 이런 시각적으로 Rebuild 파트를 명시적으로 나누는 테크닉에 대해 상당히 많은 부분이 발전된 프레임워크라는것이 느껴진다.

또한 많은 select문법도 그를 증명한다.

오히려 이런점때문에 hooks를 쓰는게 이것에 반하는것이 아닌가하여 이전엔 좀 꺼려졌지만, 이젠 마음을 좀 다르게 먹어도 될 것 같다.

Riverpod Syntax

문법은 단순하고 강력하다고 느껴진다.

물론 React를 쓰다오면 보일러 플레이트가 좀 있다고 느낄 것이다.

문법은 Documentation에 가서 보는게 좋으므로 대략 어떤것들을 알아야 하는지만 정리해두겠다.

  • Provider
  • Notifier
  • Future, Stream, Primitive가 Provider나 Notifier에서 반환될 때 무엇이 다른지
  • Notifier에서의 값을 업데이트 시키는 세 가지 방법
  • 인자를 전달하는 방법
  • 캐시가 어떤식으로 전달되고 관리되는지, identical
  • Provider들에서 서로 각각 의존성을 갖는법
  • Dispose, Lifecycle에 관련하여
  • Refresh, Invalidate등 캐시를 변경하는 방법
  • 테스트코드를 짜는 법

Comments

You may also enjoy