Why is getX such a bad state management? (왜 getX는 상태관리 패키지로 안좋은 평을 듣고 있을까?
최근 레딧에서 getX에 대해 올라온 글을 하나 봤다.
많은 사람들이 getX를 싫어하는 것을 봤고 그 이유에 대해 나 또한 의문이 들었다. GetX는 굉장히 편한 패키지 중에 하나이고 심지어 현재까지도 Flutter pub.dev에서 1위를 차지하고 있는 패키지다. 이 질문은 많은 답글을 받았고, 개인적인 의견들도 포함하고 있지만 왜 그런지에 대한 내용을 정리할겸 같이 번역하면서 함께 의견을 공유하고자 한다.
첫번째로 배운 상태관리 패키지로 GetX를 배웠는데 사람들이 별로 추천하지 않는 것 같아요. 왜 일까요? 다른 상태관리 패키지를 배워야할까요 ?
개인적으로 저는 getX가 앱을 꼭 필요한 것보다 훨씬 복잡하게 만든다고 생각합니다. 저는 Provider가 구현하기 훨씬 깔끔하다고 생각하며, 더 고급 기능이 필요한 경우는 매우 드뭅니다.
GetX는 그저 상태 관리 도구가 아니라, Flutter를 위한 프레임워크와 같습니다. 만약 단지 상태 관리자만 원한다면, 필요하지 않은 여러 추가 기능과 유틸리티를 얻게 됩니다. 그리고 GetX가 제공하는 모든 것을 사용하게 되면, 전체 라우팅, MaterialApp, 로컬라이제이션, API 등이 하나의 패키지에 의존하게 됩니다. 애플리케이션을 Flutter와 GetX 모두에 의존하게 만들어 유지 관리가 필요한 상황은 불필요한 도박이라고 생각합니다. 특히 프로덕션 앱인 경우에는 더욱 그렇습니다.
다른 사람들은 버그가 문제가 될 것이라고 말했지만, 실제로 그것은 큰 문제가 아닙니다. 필요한 경우 버그 수정을 모든 버전에 패치할 수 있습니다.
더 큰 문제는 패키지의 주요 버전 뒤에 모든 다른 기능이 있다는 것입니다. 이것은 주요 버전을 올리지 않기 위해 느린 변화를 초래합니다. Flutter에 대해 생각해보면, 기능을 제거하는 대신 사용 중단해야 합니다. 오래된 코드를 제거하고 더 나은 관행으로 업데이트하면 버전 3이나 4가 될 수 있습니다.
패키지를 작게 유지하면 주요 변경 사항도 작아지고 더 잘 문서화됩니다. 패키지는 보통모든 주요 변경 사항을 한 번에 큰 업데이트로 밀어버리면 깨뜨리고 한 번에 모든 변경을 수행할 수도 있습니다. 대신 차례로 주요 버전을 업데이트합니다.
GetX는 간단한 애플리케이션에 사용하기 쉽습니다. 그래서 많은 좋아요를 받았죠. 하지만 앱이 성장하고 복잡해지며 캐싱 등이 필요할 때, GetX는 성능과 구현이 좋지 않습니다. GetX는 상태 관리가 아니라 모든 것을 위한 완전한 라이브러리입니다. 왜 그럴까요?
아키텍처 결정에서 몇 가지 결점이 있으며, “컨텍스트 없이 사용하기” 가 뜨게되면 또 난감하죠.
GetX를 사용하고 싶다면 사용하세요. 그냥 앱이 느려질 때 나중에 울지 마세요. 구현할 방법을 모르고 이 레딧의 절반처럼 미래에 대한 질문을 하게 됩니다.