[Koin Project][Refactor] 분실물 목록 리팩토링

[kongwoojin]

PR 개요

• 이슈 번호: [Koin Project] 분실물 목록 로직 개선 #1276

PR 체크리스트

• Code convention을 잘 지켰나요?
• Lint check를 수행하였나요?
• Assignees를 추가했나요?

작업사항

• 버그 수정
• 신규 기능
• 코드 스타일 수정 (포맷팅 등)
• 리팩토링 (기능 수정 X, API 수정 X)
• 기타

작업사항의 상세한 설명

• Data fetch 및 로그인 다이얼로그를 postSideEffect로 처리하도록 수정했습니다.
• 검색 디바운싱 로직을 viewmodel에서 처리하도록 수정했습니다.

논의 사항

스크린샷

추가내용

• develop, sprint 브랜치를 향하고 있습니다
• production 브랜치를 향하고 있습니다

[JaeYoung290]

수고 많으셨습니다!

[KYM-P]

음 dialog 같은 경우 sideEffect 로 분리는 되었지만
결국 내부 에서 viewModel.setShowFilterLoginDialog 하나를 호출하는 형태라
코드만 더 길어진게 아닌가 하는 생각도 드네요.

[KYM-P]

이렇게 코딩되면 첫 setSearchQuery() 호출 이후 SEARCH_DEBOUNCE_MS 이내의 모든 fetch 가 무시되지 않나요?
예를 들면 ㅇ -> 아 의 입력을 SEARCH_DEBOUNCE_MS 안에 입력하게 되면
ㅇ 에 대한 search 가 이루어지고 아 는 fetch가 무시되는거 아닌가요

[kongwoojin]

원래도 그런 로직 아닌가요?

[KYM-P]

ㅇ -> 아 의 입력이면 ㅇ 이 무시되고 아 에 대한 결과로 fetch 해야 하지 않나요
지금은 반대같은데

[kongwoojin]

snapshotFlow { uiState.searchQuery }
    .debounce(SEARCH_DEBOUNCE_MS)
    .distinctUntilChanged()
    .collect {
        if (cancelRefresh) {
            cancelRefresh = false
        } else {
            viewModel.fetchLostAndFoundItem()
        }
    }

기존 로직도 초성-중성-종성에 따른 처리 로직은 없는 것 같습니다

[KYM-P]

기존 로직은 .debounce(SEARCH_DEBOUNCE_MS) 에 의해서
SEARCH_DEBOUNCE_MS 초 안에 여러번의 Flow 가 발생하면 collectLastest 처럼 가장 마지막 flow 에 대해서
collect 를 실행하는 것으로 알고있습니다.
근데 신규 로직은 SEARCH_DEBOUNCE_MS 초 안에 여러번의 Flow 가 발생하면(flow 처럼 비유하자면) flow.first() 처럼 첫 emit 이후 모든 변경을 무시하는 것 같습니다.

다음은 SEARCH_DEBOUNCE_MS = 250L 즉 0.25 초 안에 "se" 를 입력한 경우입니다.
se 에 대한 입력이 아닌 s 에 대한 fetch 만 이루어져 실제 결과와 다른 검색 결과를 얻게 됩니다.

잘못된 결과 (0.25 초 안에 동시 입력)

정상적인 결과

또한 0.25 초 내에 모든 query 를 지워도 반응하지 못하여 공백에 대한 fetch가 동작하지 않습니다.

[kongwoojin]

음 생각해보니 그렇네요
이건 되돌리겠습니다.

[kongwoojin]

음 dialog 같은 경우 sideEffect 로 분리는 되었지만 결국 내부 에서 viewModel.setShowFilterLoginDialog 하나를 호출하는 형태라 코드만 더 길어진게 아닌가 하는 생각도 드네요.

기존의 코드에서는 로그인 여부 판단이라는 비즈니스 로직은 UI에서 처리하고 있었습니다. 이 로직을 ViewModel로 분리함에 따라, 로그인 다이얼로그 실행 부분을 ViewModel로 같이 분리하게 되었습니다.
다만, 다이얼로그 표시는 UI 로직이기에, postSideEffect를 통해 호출하게 수정했습니다.

그 아래 로그인 시 호출하는 setSearchFilter와 fetchLostAndFoundItem의 경우, setSearchFilter는 blockingIntent가 아닌 intent로 실행되기 때문에, setSearchFilter를 통한 상태 변경 후 fetchLostAndFoundItem가 무조건적으로 보장되지는 않습니다.
따라서 이것 또한 postSideEffect로 분리를 했고요.