refactor 검색 화면 구조 개선

[soochan8]

📌 Issue

• 검색 화면 리팩토링 #47

🔖 요약

1. Screen/ScreenContent, SearchResultScrren/ResultContent 구조 개선
2. SearchContract filter 관련 State, Event 분리

🛠 작업 내용

1. 기존 파라미터 세분화를 통한 전달로 방대한 파라미터 및 유지보수 문제 존재 > state, event 단일 전달로 방대한 파라미터 구조 개선
2. SearchContract filter 관련하여 State와 Event를 분리함으로서 책임 분리 및 유지보수 용이

❗️ 참고 사항

• SearchResultViewModel을 통해 책임 분리 예정
• 검색 결과 및 필터링 로직 별도로 분리

[f-lab-pepe]

1. 너무 큰 Composable 은 나눠서 구성하면 좋겠어요.
2. FilterState 와 같은 State도 다소 큰 느낌이 있어요.
3. getFilterCategories() 같은 함수에 예외처리가 추가되면 좋을 것 같아요.

[soochan8]

@f-lab-pepe

1. composable을 세분화하여 역할 구분을 하겠습니다!
2. FilterState도 조금 더 세분화하여 작업화면 괜찮을까요?
   현재는 검색 전, 검색 중, 검색 후 모두 SearchContract와 SearchViewModel을 사용하고 있어서 역할이 커지는 것 같습니다. 검색 후 결과 Composable에서 이벤트가 발생했을 때 State를 변경해야 해서 단일 Contract와 ViewModel로 구성을 했습니다. 하지만 역할이 너무 커지는 것 같아서 검색 후 (SearchResultContract, SearchResultViewModel) 을 별도 구성을 생각하고 있습니다.

별도 구성을 하였을 때, SearchResultScreen/SearchResultScreenContent에서 발생한 이벤트로 인해, SearchContract에서 정의한 State가 변경되야 합니다.

(SearchResultContract, SearchResultViewModel) 을 별도로 구성하여 책임을 분리하는 게 괜찮을까요?

3. 넵 예외처리 관련해서 신경쓰도록 하겠습니다!

[soochan8]

📌 Issue

• 검색 화면 리팩토링 #47 추가 푸쉬 내용입니다.

🔖 요약

0. 06f03dd 이후 푸쉬 내용
1. SearchResultScreen, SearchResultScreenContent 구조 개선 및 composable 세분화

🛠 작업 내용

1. SearchResultScreen, SearchResultScreenContent 구조 개선

• 상태를 하나씩 넘겨 파라미터 무한 증가 문제 방지 > state와 event를 넘겨서 처리

2. SearchResultScreen, SearchResultScreenContent composable 세분화

✅ TO-DO

• SearchScreen, SearchScreenContent 구조 개선 및 composable 세분화
• SearchFilterScreen 구조 개선 및 composable 세분화
• searchResultContract, searchResultViewModel 세분화 예정 ?? (확정 X)