성장을 위한 기록

WIL 0704 ~ 0710 9주차 회고 본문

개발 일기 및 회고/회고

WIL 0704 ~ 0710 9주차 회고

B_Tae 2022. 7. 10. 10:27

가장 헤맷던 부분 특정 조건에서 query 사용하기

이번 주차를 진행하면서 가장 오래 걸렸고 가장 헤멧던 부분은 특정 조건에서 query를 작성하는 부분이 있었다.

나는 검색기능에서 검색을 실행했을 때 query를 요청하는 방법에 대해 아직도 고민을 하고 있다. mutate를 사용하는 방법도 있지만, 캐시 데이터를 관리하기 위해 query가 적절하다 생각했고 이 방법을 탐구하고 있다

생각한 방법 자세한 트러블 슈팅은 깃 이슈에서 정리하고 있다.
이번 이슈 정리 깃

  1. enabled를 false로 두고 refetch를 사용하는 방법
  2. mutate를 사용하고 redux로 전역상태관리 하는 방법
  3. 이 밖에 테스트 해보지 않은 생각하는 방법

1. enabled를 false로 두고 refetch를 사용하는 방법

  1. useState로 검색어를 저장하고 useQuery를 날리는 방법을 시도하는데 안되는 건 아니지만 몇 문제점을 발견했다. query가 날라가기 때문에 검색을 보내지 않아도 입력하는 것으로도 검색에 대한 결과을 받는다. 따라서 원하는 결과만 받기가 어렵다.
    그리고 글자가 변경될 때마다 query를 요청하여 키값이 많이 쌓인다.

  2. useRef를 사용해서 특정값을 얻고 Ref를 사용하기. 이 방법에서는 항상 변수를 변경할 수 있는 state관리법이 아니기 때문에 계속 초기값으로만 요청하는 문제가 있다. 결국 원하는 요청은 할 수 없는 방법이다.

2. mutate를 사용하고 redux로 전역상태관리 하는 방법

지금은 이게 현실적이라고 생각하는 방법이다. 검색 실행과 더불어 mutate를 실행하고 그 결과를 store에 저장해 이후부터는 store에서 데이터를 꺼내온다. 딱히 안될 건 없지만, 데이터를 store에 저장할 경우 최신화 타이밍을 잡기가 어렵다. query에 경우 캐시 타임을 설정해 일정 시간 이후에는 최신 데이터를 받아올 수 있지만, store는 불가능하다. 그리고 데이터가 쌓일 수록 찾아오는 속도도 느려진다.
캐시 데이터처럼 받아온 데이터를 비교해서 저장할 수는 있지만, 이 방법도 가능은 하지만 좋은 방법은 아닌 것 같아 다른 방법을 고민해봤다.

3. 이 밖에 테스트 해보지 않은 생각하는 방법

우선 지금 상황을 정리를 해봤다. useState를 이용해서 state관리를 하는 방법은 매 순간 요청이 가기 때문에 동작하지 않는다. useRef는 원하는 값을 가져올 수 없기 때문에 적절하지 않다.

전역 상태관리는 캐시 데이터에 비해 지금 상황에서 큰 장점이 없다.

결론 . query를 쓰는게 맞는 것 같다. useState로 직접 input을 관리하지 않고, sumbit 이벤트에서 Ref 값을 useState 변경에 사용하면 어떨까 ? 이 방법을 테스트 해볼 예정이고,
그 전에 refetch와 enabled의 옵션에 대해 더 공부를 해봐야 할 것 같다.

그전에 공부하자

enabled는 false인데 요청이 가는 이유와(refetch 실행 전) enabled의 정확한 사용 방법에 대해 알아봐야 할 것 같다.

시간이 중요한 프로젝트이기 때문에 많은 고민을 할 생각은 없다. 어쩔 수 없다면 mutate를 사용하겠지만 query를 위해 1번 방법이다 오늘안에 생각나는 방법으로 해결할 것 같다.

자세한 과정은 상단에 작성한 깃 이슈 부분에 순차적으로 정리해볼 예정이다.

이번 주를 돌아보며

이제 API테스트도 끝나가고 디자인도 얼추 나오는 것 같다. 최대한 시간을 절약하기 위해 모든 코드를 미리 작성을 하다보니 이 방법이 맞는지 방향 잡는게 어려운 것 같다.
기달렸다 작성을 해도 크게 오래걸리진 않겠지만, 그 동안 아무것도 안한다는 건 용납할 수 없었고, 그래도 미리 작성한게 빨리 끝나기는 했다. 하지만 미리 작성하는 과정과 추후에 수정하는 모든 과정에 총 시간과 노력은 기달렸다 작성하는게 효율적이라고 생각된다.

물론 이런 고민을 한다고 미리 작성하지 않을 건 아니지만, 약간의 답답함과 미리 작성할 때 미래를 알고 있으니 좋은 방법에 대해 고민이 된다.

다음 주 목표 !

이제 중간 발표다. 아직 기본 부분에서 구현되지 않은 부분이 존재한다. 이 부분을 빠르게 끝내보려고 한다. 또 차트 등 내가 맡은 파트에 대해 알아볼 필요가 있기 때문에 그에 따라 이것저것 테스트를 해봐야겠다.

'개발 일기 및 회고 > 회고' 카테고리의 다른 글

WIL 0718 ~ 0724 11주차 회고  (0) 2022.07.24
WIL 0711 ~ 0717 10주차 회고  (0) 2022.07.17
WIL 0627 ~ 0703 8주차 회고  (0) 2022.07.03
WIL 0620 ~ 0626 7주차 회고  (0) 2022.06.26
WIL 0613 ~ 0619 6주차 회고  (0) 2022.06.19
Comments