0712 Mon. 리코일과 캐쉬에 관하여..
일단 글을 쓰면서 이게 맞나 계속 의문이 들어 글이 굉장히 길어지고
불확실성 가득해진 고민글이 되었다.
HTTP GET과 POST 비교하는 공부를 하면서 캐싱여부를 알게되었고
리코일이 떠올랐다. 리코일이 요청값을 캐슁해서 새로운 데이터를 요청해도 바로 갱신해버리지 않아 새로고침을 해야 화면이 바뀌어야 했던 상황들이다.
신기했던 것은 상태값과 상태주소 둘다 캐싱해버린다는 것.
selector와 selectorFamily 모두 캐시를 사용한다. 즉, 입력값이 동일한 경우에는 get 메서드를 다시 실행하지 않고 캐시에 있는 값을 반환한다. 캐시키는 selector/selectorFamily를 작성할 때 전달한 key 프로퍼티와 get 메서드 내부에 있는 의존성(위 postList 셀렉터 예제의 경우 pageNumber 아톰)의 종류와 값, 그리고 실행시 전달된 파라미터로 결정된다. 다만 selector는 파라미터를 전달하지 않으므로 key와 의존성 값으로만 캐시키의 동일성을 확인할 것이다.
이슈를 수정해야하는 상황이었고 get의존성을 갖게하기 위해 trigger atom을 만들어 DELETE요청을 보내는 상황이었다.
처음엔 trgger가 setTrigger(trigger=>!trigger)와 같이 boolean 2가지 값으로 변경되면서 상태를 바꾸게 했었고, 삭제해야할 아이디는 요청 바디에 담아 보냈었다. 처음 한두번은 잘되는 듯한데 그 다음부터 삭제한 데이터가 삭제버튼을 한번 더 누르면 뿅하고 다시 나타났었다.;;
(글을 다 쓰고나서 의문: http에서 delete 요청은 캐쉬하지 않는다는데 그렇다면 내가 다시 마주했던 삭제한 데이터는 뭐지??-> 삭제요청시 캐쉬여부 직접 이슈트래커에서 확인하기)
위 리코일 레시피 글에서 말하는 것 처럼 key, get값으로만 캐시키의 동일성을 확인하기 때문에 삭제하고자 하는 아이디가 변경되었어도 trigger가 true/false라는 2가지 상태를 기억하고 2번 이후부터의 요청은 true 또는 false로 상태를 동일하게 보고 캐슁된 데이터를 반환한 것이었다.
이를 해결하기 위해 trigger=> trigger+1로 계속 새로운 트리거 값을 만들어주어 캐쉬되지않도록 했다.
다른 해결책으로는 selectorFamily를 비교해봐야겠다. selectorFamily는 파라미터로 받아온 값은 캐싱반환여부를 판단하는 유효성검사를 한다고 한다. 즉 삭제할 아이디를 fetch selectorFamily에 삭제할 이슈 넘버를 넘겨서 요청하면 recoil에서 파라미터값을 체크하고 새로운 요청을 보내게 될것이라고 예상된다.
그런데 생각해보니 GET요청외의 POST PATCH 등 정보수정 요청은 리코일을 사용하지 않고 trigger로 상태변경만 시켰었다. 또 단점발견!! 왜 리코일을 사용하지 않았나면 handleClick내부 함수에 리코일을 선언할 수 없었기 때문이다. 더불어 useEffect와 같은 reactHooks내부에서 사용할수가없다. 근데 설마... 방법이 있겠지 싶으면서 아직 발견을 못했는데 해결점을 찾아봐야겠다.
이 문제는 다음 주에 이슈트래커를 다시 리코일로 작업하면서 관련 영상, 사진도 따고(꼭 네트워크에서 캐쉬여부 확인할 것), 새로 블로그로 남기도록 하자!!
즉 어쨋든 리코일은 캐쉬를 한다~ 캐쉬된 정보를 사용하지 않아야할 땐 셀렉터패밀리를 사용하자~
(아래 도움이 된 게시물에서는 셀렉터 패밀리로 캐쉬문제를 해결하긴 했지만, 캐쉬때문에 전역으로 사용할 수 있는 값을 굳이 파라미터로 받아서 사용해야한 상황에 문제를 제기한 글이긴 하다.
내가 사용하고자 하는 상황에 따라 캐쉬가 이점이되기도, 골칫거리가 되기도 한다.
도움이 된 게시물
- https://github.com/saseungmin/Recoil_ToDo/issues/54
- 늘 그렇듯 리코일 레시피
07/13 Tue.
- 이슈트래커 폴더 정리 (배포용 주소변경, 폴더명 변경 , 불필요한 폴더 삭제)
폴더명 하나 바꾼거 인식시키는데 너무 어려웠다.
아직도 깃 무서우 ㅓ😭
정확히 뭘 하려는지 파악하고 진행하기
항상 최신화시킨 후 깃 작업하는 걸 생각하기
-
쓰로틀링과 디바운스
-
프로젝트 회의진행 (프로젝트 예명: Hi-Fi🙋♀️)
: 생각보다 구체적인 내용으로 페이지를 구성했고, 어떤 기술스택으로 할지도 정했다.다만, 상태관리를 recoil로 할지 swr로 할지를 고민중인데, recoil이 useState처럼 사용할 수 있는 점이 너무 편해 swr에도 이러한 기능이 있는지가 궁금하다. 지금까지의 검색으로는 없는 것 같다.
새로운 학습비용이 즐거운 기술을 배우고 싶다. -
오늘은 공부를 많이 하지 못했다. ㅠ_ㅠ
TODO
- todo: 읽고이해해보기 ->
: https://soopdop.github.io/2020/12/01/index-signatures-in-typescript/ - Suspense에 대한 정리.
:https://ko.reactjs.org/docs/concurrent-mode-suspense.html#what-if-i-dont-use-relay - 이거머야, 깃헙페이지로 배포링크게시하기!!!! https://pages.github.com/
