## 지역 필터 설정 기능 ### 비슷하게 해본거 - 데이터 테이블이나 검색필터에서 전체 체크박스 사용하는 부분이 많음 (parent- child 체크박스 구현 때 사용) - 쇼핑몰 카테고리 4depth 까지 해봐서 비슷해보였는데, 데이터따라서 depth가 늘어날 수 있다는 부분은 해봐야 알듯 ### 구현시 고려사항 - 체크/언체크 이벤트시 지역에 칩버튼 관리하는 부분은 컴포넌트 depth가 깊으니까 전역상태 관리(redux) 로 이벤트를 처리 -- 선택사항 - 칩 처리시 하위가 상위로 합쳐지고 나눠지는 부분을 처리를 쉽게 해야함 데이터에 값을 하나 추가하면 편할 것 같음 >> 데이터에 id를 만들 때 depth 마다 코드를 하나씩 추가하면서 id를 만들기 >> 서울 01 부산 02 대구 03, >> 서울_종로구 0101 서울_중구 0102 >> {name: '서울' id: '01'} ## 검색기능 ### 구현시 고려사항 - parent가 검색에 걸리면 child 검색 제외 - 검색된 결과를 보여줄 때 검색된 결과 + 상위 위계를 다 보여줘야하므로 펼침여부와 보여주는 여부 상태값 관리가 필요함 >> {name: '서울' id: '01', fold: true, show: true} - '클릭시 펼쳐지고, 접히는 것' + '필터여부와 상관없음' 위에 상태 값 같이 컨트롤해주면 됨 ## UI 수정 필요한 부분 - parent가 펼침상태일 때 > 아이콘이 v로 변경되어야함
디바운싱과 쓰로틀링은 묘하게 사용성을 떨어뜨려서 쓰지 않았습니다. 기본적으로 트리구조를 사용했는데요, 이슈가 됐던 건 상태변화가 부모 방향과 자식방향으로 양방향으로 순차적으로 전파되어야 한다는 것이었습니다. 순차적으로, 단계를 밟아 상태변화가 전파되지 않으면 의도한 UI상의 변화와 검색 필터 반영이 되지 않아 그 부분이 가장 애를 먹었습니다. 단방향의 상태 변화 전파(부모->자식)는 간단한데 양방향 전파(자식->부모까지 포함)가 알고리즘이나 성능최적화 부분에서 고려할 부분이 많더군요.
Trie 자료구조로 하면 될 거 같은데, 만약 용산동을 '산동'이라고 검색하는 경우도 용산동을 찾아야한다면 안될 지도. xx시 yy동 이런 상황에서 xx나 yy를 제대로 prefix 검색을 하는 상황이라면 될 지도. 해보려고 했는데 코드를 짜도 제대로 짰을까하는 의문이 들어 해보진 않았네요 답 알려주세여
좋은 발상이세요. 다만 지역 데이터를 담은 json이나 텍스트 파일을 다운로드 받는 과정이 성능 병목이 되지는 않을 것 같습니다. 한글자당 3바이트, 한지역명당 평균6글자 정도라고 가정하면 2100*6*3바이트가 나올 텐데요 37800 바이트, 약 36kb가 나옵니다. 이정도면 1Mbps의 속도면 0.03초, 일반 가정인터넷인 100Mbps의 경우 0.0003초가 걸리게 됩니다. 브라우저에 할당된 메모리에도 36kb 보다 조금 더 많은 메모리 공간을 차지하겠죠. 아이콘 하나보다 작은 메모리 공간입니다. 따라서 해당 데이터의 용량이 성능 병목이 될 것 같지는 않아보입니다. 접근 방법은 좋으시고 칭찬드리고 싶습니다!
