[스크랩] 플러터 getX, provider, riverpod

아무래도 안심이 되는 솔루션은 riverpod 인 듯 하다.

회사의 기존 코드는 provider, 회사의 새로운 코드는 getX, 그리고 나만 작성하게 될 소규모 앱이 있는데, buildcontext를 안정적이고 가시적으로 추적가능한 provider로 하려고 마음 굳혔었는데, 그러다가 ui와 무관한 service코드를 작성하려고 보니 거기에도 context가 필요할 경우가 있어서 코드가 번잡해지는 것 같았다.

그래서 찾아보니 예전에 개인프로젝트할때 멋모르고 썼던 riverpod가 확실히 그런 면에서 provider보다 뛰어났다.

내가 중요시하는 코드 아키텍쳐 특징은 '의존성 최소화', 'UI와 로직의 디커플링'이다.

그래서 아무래도.. riverpod 가 좋은 것 같다.

https://velog.io/@dyddn2015/%EB%84%A4%EC%9D%B4%ED%8B%B0%EB%B8%8C-%EC%95%B1-%ED%94%8C%EB%9F%AC%ED%84%B0%EB%A1%9C-%EB%B0%94%EA%BE%B8%EA%B8%B08-%EA%B8%B0%EC%88%A0%EC%A0%81-%EA%B2%B0%EC%A0%95%EC%82%AC%ED%95%AD2

플러터 기술 결정 (getx vs riverpod) 결국 비용을 최소화하기로! 저번 포스팅에서 선택의 기준을 경영자의 관점인 '비용의 최소화'에 두기로 마음먹었다. 하지만 비용을 줄이겠다는 미명하에 모든 것을 포기하겠다는 말은 아니다. 전 포스팅에서도 언급했듯, 어디까지나 내가 원하는 최소한의 결과물은 낼 수 있어 결국 비용을 최소화하기로! 저번 포스팅에서 선택의 기준을 경영자의 관점인 '비용의 최소화'에 두기로 마음먹었다. 하지만 비용을 줄이겠다는 미명하에 모든 것을 포기하겠다는 말은 아니다. 전 포스팅에서도 언급했듯, 어디까지나 내가 원하는 최소한의 결과물은 낼 수 있어

답정남으로 질문해서 얻은 만족스러운 답변.. ㅎㅎ