앱에서의 데이터 사용과 구현

클라이언트에서 데이터를 어떻게 분류하고 관리할지에 대한 고민이다.

데이터 분류

클라이언트에서 데이터는 크게 2가지로 분류할 수 있다:

1. 상태관리(구독이 필요한) 데이터
2. 구독이 필요없는 데이터

사용 범위에 따른 구현

전역 상태관리, 언제 써야할까?

전역 상태관리를 써야 할 때:

• 여러 페이지에서 반복되게 사용하는 데이터
• UI가 이 데이터의 변경을 알아채야 하는 경우

골때리는 점: 전역 상태관리 툴을 사용하면 구간과 dispose를 신경써야 한다. 커스텀할 때 각각의 상태관리 툴을 깊게 이해해야 해서 시간이 많이 든다.

내 생각

나는 최대한 전역 상태관리를 안 쓰려고 했다.

이유

• 나중에 확인할 때 전역으로 관리해야 할 데이터를 한눈에 확인할 수 있다
• 불필요한 복잡도를 피할 수 있다

Riverpod의 autoDispose를 쓰면 해당 데이터가 쓰이지 않을 때 자동으로 dispose된다. 약간 GC 같은 느낌이다.

결론: 프론트엔드나 앱에서 완전히 데이터와 UI가 분리될 수 없다. 매우 복잡한 경우가 아니라면 각 위젯에서 처리하는 게 직관적이고 덜 복잡하다.

전역 변수 관리

나는 전역 변수는 다 클래스로 묶어서 사용했다.

// 나쁜 예
String apiUrl = 'https://api.example.com';
int timeout = 30;

// 좋은 예
class AppConfig {
  static const String apiUrl = 'https://api.example.com';
  static const int timeout = 30;
}

// 사용
print(AppConfig.apiUrl);

장점

• 카테고리별로 분류할 수 있다
• IDE에서 .하면 변수들을 보여줘서 실수할 확률이 줄어든다
• 자동완성이 된다

상태관리 선택 기준

데이터가 여러 페이지에서 쓰이나?
    ├── Yes → 상태가 바뀌면 UI도 바뀌어야 하나?
    │           ├── Yes → 전역 상태관리 (Riverpod, Provider)
    │           └── No → 전역 클래스/변수
    └── No → 해당 위젯에서 관리
              ├── 복잡한 상태 → StatefulWidget, hooks
              └── 단순한 상태 → setState

관련 문서

• flutter mvvm - MVVM 아키텍처
• riverpod read listen - Riverpod 사용법
• user에 로딩 state가 있어야하는가! - 상태 설계 고민