› 일단 이건 지금 여기서 마무리하자. 그런데 내가 생각했을 때 나중에는 지금처럼 filter vm을 각각 만들어두는 것 보다, filter 전용 component와 vm을 따로 만들어서 관리하는것이 좋을 거 같은데, 어떻게 생각해?
• 그 방향이 맞습니다. 지금 구조는 calendar와 dailyevents가 필터 개념을 거의 공유하는데, 상태 타입, bottom sheet UI, 적용 로직, navigation 전달 로직이 화면별로 복제되어 있어서 앞으로 유지보수 비용이 계속 올라갈 가능성이 큽니다.
다만 완전히 공용 FilterViewModel 하나로 바로 합치는 건 조금 조심해야 합니다. 이유는 두 화면이 공유하는 건 “필터 편집 경험”이지만, 실제 데이터 로딩 타이밍과 결과 적용 방식은 다르기 때문입니다. 그래서 저는 이렇게 보는 편입니다.
- 먼저 공통화할 것
FilterState, FilterTab, exclude keyword 처리, bottom sheet UI, 선택/해제 로직, navigation serialization 같은 건 공용으로 빼는 게 좋습니다.
- 화면별로 남길 것
calendar는 month range 기준 재조회, dailyevents는 single date 기준 재조회처럼 결과 적용 책임은 각 화면 VM이 계속 갖는 편이 안전합니다.
- 추천 구조
FilterComponent + FilterViewModel 또는 FilterStateHolder
각 화면 VM은 이 공통 필터 상태를 포함하거나 주입받고,
실제 apply 시점에만 자기 화면의 fetch 로직을 실행하는 방식이 제일 균형이 좋습니다.
예를 들면 구조는 이런 식이 좋습니다.
- EventFilterState
- EventFilterViewModel 또는 EventFilterController
- EventFilterBottomSheet
- CalendarViewModel / DailyEventsViewModel
여기서는 loadMonth, loadDate 같은 화면별 fetch만 담당
즉, “필터 자체의 상태 관리”와 “필터를 사용해 어떤 데이터를 다시 불러올지”를 분리하는 겁니다.
주의할 점도 있습니다.
- 필터 VM을 싱글톤처럼 전역 공유하면 화면 간 생명주기와 초기화 타이밍이 꼬일 수 있습니다.
- 그래서 전역 VM 하나보다는 공통 필터 모듈 + 화면별 소유권이 더 낫습니다.
- 가장 먼저 할 리팩터링은 VM 통합보다 CalendarFilterState와 DailyEventsFilterState를 하나의 EventFilterState로 합치는 겁니다. 이게 중복 제거 효과가 가장 큽니다.
정리하면, “filter 전용 component와 상태 관리 레이어를 따로 만든다”는 생각은 좋고, 저도 찬성합니다. 다만 “전용 VM 하나로 전부 통합”보다는 “공통 필터 모델/UI + 화면별 데이터 VM 유지”가 더 안정적인 설계입니다.
› 일단 이건 지금 여기서 마무리하자. 그런데 내가 생각했을 때 나중에는 지금처럼 filter vm을 각각 만들어두는 것 보다, filter 전용 component와 vm을 따로 만들어서 관리하는것이 좋을 거 같은데, 어떻게 생각해?
• 그 방향이 맞습니다. 지금 구조는 calendar와 dailyevents가 필터 개념을 거의 공유하는데, 상태 타입, bottom sheet UI, 적용 로직, navigation 전달 로직이 화면별로 복제되어 있어서 앞으로 유지보수 비용이 계속 올라갈 가능성이 큽니다.
다만 완전히 공용 FilterViewModel 하나로 바로 합치는 건 조금 조심해야 합니다. 이유는 두 화면이 공유하는 건 “필터 편집 경험”이지만, 실제 데이터 로딩 타이밍과 결과 적용 방식은 다르기 때문입니다. 그래서 저는 이렇게 보는 편입니다.
FilterState, FilterTab, exclude keyword 처리, bottom sheet UI, 선택/해제 로직, navigation serialization 같은 건 공용으로 빼는 게 좋습니다.
calendar는 month range 기준 재조회, dailyevents는 single date 기준 재조회처럼 결과 적용 책임은 각 화면 VM이 계속 갖는 편이 안전합니다.
FilterComponent + FilterViewModel 또는 FilterStateHolder
각 화면 VM은 이 공통 필터 상태를 포함하거나 주입받고,
실제 apply 시점에만 자기 화면의 fetch 로직을 실행하는 방식이 제일 균형이 좋습니다.
예를 들면 구조는 이런 식이 좋습니다.
여기서는 loadMonth, loadDate 같은 화면별 fetch만 담당
즉, “필터 자체의 상태 관리”와 “필터를 사용해 어떤 데이터를 다시 불러올지”를 분리하는 겁니다.
주의할 점도 있습니다.
정리하면, “filter 전용 component와 상태 관리 레이어를 따로 만든다”는 생각은 좋고, 저도 찬성합니다. 다만 “전용 VM 하나로 전부 통합”보다는 “공통 필터 모델/UI + 화면별 데이터 VM 유지”가 더 안정적인 설계입니다.