- State Management는 최초 개발을 빠르게 하고 앱 스펙이 수정되었을 때 필요한 부분을 빠르게 찾고 수정할 수 있게함.
- MVC -> MVP -> MVVM으로 진화해왔는데, 이젠 선언형 UI, declarative UI로 전국통일함.
- Statement Management는 scoped model과 static model로 나뉘는데,
- scoped model은 화면/위젯에 국한하여 영향을 미치도록 범위를 조정하는 방식.
- static model은 전역으로, 앱 전체에서 누구나 해당 스테이트로 접근할 수 있는 형태.
- 가령 유튜브 화면을 예시로 들었을 때, 둘 다 가능함:
- 또 다른 예를 들어, 새로운 문서의 doc를 작성한다 하면 각 문서별로 스코프 모델을 활용해야 할 것임.
- 정리하자면, 스코프는 1) 해당 스코프 화면이 사라지면 자동으로 메모리 해제가 됨. 2) child에서 데이터 참조를 할 때 id(구별자) 없이도 상위 데이터 참조 가능함.
- 스태틱은 1) 메모리 관리를 개발자가 직접 관리해야함 (들고있는 걸 언제 날릴 지 결정해야 함) 2) child에서 데이터를 참조할 때 id(구별자)가 항상 필요함. 3) 스코프 대비 구현이 쉽고, 4) 모든 코드에서 원하는 스테이트에 접근하고 수정이 가능함. --- 노드 할 땐 스태틱으로 한 것으로 추정됨.
- 기존에 보통 emptyExpanded 썼는데, spacer로 하니 좋음. 스페이서 쓰자.
- 3.5.2에선 inherited widget을 썼는데, getx (+RxList) & obs/Obx 위젯으로 상태관리 수정함. 더 간단해짐.
- Cubit vs Bloc 가장 큰 차이는, 큐빗은 UI에서 바로 큐빗에 함수를 이용해 명령을 내리고, 블럭은 직접적인 명령이 아닌, 중간에 이벤트를 통해 명령을 내림.
- Riverpod은 여러 패키지들이 서로 유기적으로 연동이 될 수 있게 도와줌.
- 리버팟은 전역적인 변수 선언을 해서 설계함. 데이터가 전역으로 들어있는 것은 아니래.
- hook 전망 좋음. Custom한 use함수 사용하기 좋음.
- 좋은 앱은 1) 구조파악 쉬워야 하고, 2) 작성하는 코드 양 및 좋은 가독성이 필요. 3) 안정성이 높아야 하는데, 이 말은 테스트코드 작성이 가능해야 한다는 뜻. 4) 확장성도 신경써야함.
- 상태관리 비교:
- GetxController 안에 직접 필드로 들고있어 GetX는 별도의 스테이트 형태가 아닌, 변수처럼 사용 가능.
- Cubit, Bloc은 한 종류의 스테이트 객체만 관리하고, 기능/화면 별 wrapping state data 필요함. copyWith 함수도 항상 필요함.
- Riverpod도 비슷한데, StateNotifier 안에 State 객체를 한 종류만 넣을 수 있고, 가이드에서는 새 state객체 사용을 권함.
- 내 소감은 리버팟이 가장 직관적이고 합리적인 것 같음.
아키텍처 & 상태관리
3.5.1) Scope vs Static Model 개념
3.5.2) 상태 관리 없는 ToDo 앱 처음부터 만듦
3.5.3) Getx로 상태관리, 기존에 참고했던 data holder를 mixin class 이용해서 수정
3.5.4) Bloc을 이용해서 상태관리 (GetX -> Cubit/Bloc)
3.5.5) Riverpod으로 변환
3.5.6) Flutter Hooks - stateful widget 대체, hooks riverpod 활용
출처: 패스트캠퍼스
[Flutter] 간단 당근 UI (0) | 2024.05.01 |
---|---|
[Flutter] Todo 앱 (로컬저장, 웹소켓) (0) | 2024.04.30 |
[Flutter] 고급 문법 (stream, iterable, lamda, SOLID, singleton - 디자인패턴) (0) | 2024.04.30 |
[Flutter] 개념정리, 기초*** (1) | 2024.04.28 |
[Flutter] 간단 또스2 (애니메이션) (0) | 2024.04.24 |