플러터 상태관리 오버엔지니어링 하지 마세요!
안녕하세요 👋
플러터 개발자 Andrew Lee 입니다.
소프트웨어 개발자이며 새로운 것을 배우는 것을 좋아합니다. 오늘 하루는 자신을 향상시키고 무언가를 할 수있는 기회입니다!
플러터에서는 UI가 상태에 반응하도록 하는 코드를 작성해야 합니다.
위 문장을 수학적으로 표현해 보겠습니다.
UI = f(상태)
개발자 들은 어렵고 멋진 말을 좋아합니다.
좀 더 멋진 개발적인 표현으로는 “선언적 UI 프로그래밍”이라고 합니다.
모두 같은 의미라고 생각하시면 됩니다.
먼저 UI의 기본요소인 위젯에 대해 이해해야 합니다.
플러터의 위젯은 상태를 가지고 있습니다.
StatefullWidget(상태저장위젯) , StatelessWidget(상태비저장위젯)
위젯의 상태에 대해 배웠다면 다음으로 Flutter를 탐색하다 보면 화면 간에, 앱 전체에서 애플리케이션 상태를 공유해야 할 때가 옵니다.
https://docs.flutter.dev/development/data-and-backend/state-mgmt/intro
이때 우리가 취할 수 있는 접근 방식은 다양합니다.
아래의 플러터 공식문서에서 다양한 애플리케이션의 상태를 공유하는 방법들을 안내하고 있습니다.
https://docs.flutter.dev/development/data-and-backend/state-mgmt/options
근데 문제는 플러터 문서에서는 이중에서 Provider 가 좋은 접근방식이라고 하면서도
다른것들도 좋아라고 하죠!
개발자 마다 선호하는 상태관리 방식이 있기 마련입니다.
그런데 말입니다! 우리는 선택지가 많아도 고민이 됩니다.
아래 레딧에서도 이와 관련한 토론이 진행되었어요
https://www.reddit.com/r/FlutterDev/comments/quo1uk/flutter_clean_architecture_modelviewpresenter_an/
https://www.reddit.com/r/FlutterDev/comments/qpby3y/struggling_to_justify_riverpod_getx_bloc_over/
스크린샷은 구글번역기를 돌렸으므로 번역의 상태가 좋지 못합니다 양해부탁드려요 : )
토론내용을 쭈욱 읽어보니 결론은 상태관리에 있어서 오버엔지니어링을 피하라고 합니다.
그렇다면 어떤게 오버엔지니어링 일까요? 사용하려는 상태관리솔루션에 대해 다음의 질문에 답변해보시기 바랍니다.
- 부풀려진 문제? 프레임워크 자체가 복잡하고 불필요한 수준의 복잡성을 도입하나요?
- 사용하기는 편하나 너무 추상화 되진 않았나요?
- 테스트 하기에 용이한가요?
이제 선택지가 좁혀지셨나요?
우리에게 은총알은 없습니다!
실생활의 모든 문제와 마찬가지로 정답은 없습니다.
상태관리 솔루션이 없이 코딩하는 것이 일부 프로젝트에는 최고의 솔루션이 될 수 있고 다른 프로젝트에서는 악몽이 될 수도 있습니다.
모든 도구와 마찬가지로 핵심은 사용 방법뿐만 아니라 언제, 어떤 도구를 사용할 때의 장점과 단점이 무엇인지 배우는 것입니다.
저는 개인적으로 구글에서 제안한 Provider를 사용하고 있고 아직 큰 문제가 없었습니다 : )
