useSWR이 좋은 라이브러리라고는 이미 널리 알려져 있음에도 불구하고 useSWR에 관련된 대부분의 글들에서 좀 더 다양하게 응용하여 사용하는 방법에 대해 다루는 경우는 많이 보지못했기에 가볍게 useSWR의 좀 더 섹시한 사용방법중 한가지를 공유하고자 글을 작성하게 되었다.
먼저 공식문서의 useSWR의 간단한 사용 방법은 다음과 같이 되어있다. 또한 많은 사람들이 아마? useSWR 이러한 방법으로 사용하고 있을 것이다. 물론 이러한 방법으로 사용하는것이 나쁜것은 절대 아니다. 하지만 이런 방식으로 사용을 할 때에 간과하는 부분이 있을수도 있을 것 같다.
가장 핵심적인 이유는 바로 저 첫번째 인자가 단순하게 api path를 적는것이 아닌 key라는 것이다 useSWR은 저 key를 기반으로 fetch된 데이터를 캐싱하며 key가 변경되에 따라서 revalidate을 하는 hook임을 항상 기억을 하고 있어야 한다.
그래서 이것을 어떻게 응용할 수 있는데? 라는 생각이 들수도 있다.
아래 코드가 바로 이를 응용한 간단한 예시이다.
먼저 해당 코드는 user가 있을경우 해당 유저의 team list를 fetch하여 받아오는 코드이다. 실제 코드는 주기적으로 fetch할 필요가 없는 api이기에 useSWRImmutable을 사용하였으나 응용 방법에 대한 설명을 위해 간단하게 변경하였다.
가장 눈여겨 봐야하는 부분은 위의 useSWR의 key에는 그 어디에도 api path에 대한 정보가 없는것이다.
즉 첫 번째 인자는 정말로 cache만을 위한 key로 사용하여 user가 변하는것을 tracking하게되며 하며 user가 변할때마다 데이터를 다시 fetch하게 해주는 역할을 하게된다. 두 번째 인자에 단순하게 getTeamListByUserId를 하는 fetch 함수를 넣어줌으로써 user가 변하면 자동으로 해당 함수가 호출되어 현재 user에 맞는 팀을 불러오게 되는 것이다.
물론 이는 /api/get-team?userid=${user.Id} 를 key로 사용하고 단순하게 fetcher를 사용하는 방식과 다른점은 없다고도 말할 수 있다. 하지만 이는 단순한 로직에서나 유용하게 사용할 수 있지 분 혹은 날짜단위로 cache를 하고싶다거나 pagination이 있다거나 정렬 등 각종 기능들이 들어가게되면 첫 번째 key부분에 점점 긴 api의 url string이 들어가게되고 이는 코드의가독성적인 측면에서 여러가지로 불편함을 초래하게된다.
따라서 캐싱을 하고 싶은 핵심적인 값들만 key값에 넣어주어 캐싱데이터들을 관리하며 fetch로직은 fetcher하나만 사용하는 것이 아니라 어떤 로직을 하는 라이브러리 형태의 파일로 분리시키고 해당 파일을 두 번째 인자에 넣어 사용하는것이 좀 더 이쁘고 가독성있는 코드를 만드는 방법이라고 생각한다.
useSWR은 이런 방법 외에도 여러가지의 정말로 좋은 응용방법이 많지만 여기 글에서는 이 내용에 대해서만 작성하도록 하고 나머지는 추후 글을 쓰고싶어질때에 작성하도록 하겠다. 끝!!!
