리액트 쿼리 로직을 커스텀 훅으로 만들 때, 어디까지 추상화를 하시나요?

Question

안녕하세요. 현재 프로젝트에서 기존 데이터 페칭 로직들을 전부 리액트 쿼리로 옮기면서, 고민이 생겨 질문을 드립니다.

클라이언트 상태와 서버 상태로 폴더를 나누고, 쿼리 로직들을 커스텀 훅으로 만들고 있습니다. 그런데 이 커스텀 훅의 추상화를 어디까지 해야할지 고민이 됩니다.

3개의 서비스 페이지가 있고, 사용하는 쿼리 내부의 로직이 비슷할 경우, 아래의 두 가지 방법을 생각해 봤습니다:
1. 재사용을 위해 매개변수로 URL, URL parameter, Query key를 추가
2. 유지보수를 위해 URL parameter만 매개변수로 추가하고, 개별 커스텀 훅 생성

예시 코드로, 1번의 코드는 `useDashboard(/data, startDate, endDate, service01/dashboard);` 이런식으로 사용을 하고, 2번의 코드는 `useService01Dashboard(startDate, endDate);, useService02Dashboard(startDate, endDate);...` 이렇게 사용을 합니다.

현재는 2번의 방식으로 구현을 하고 있습니다. 그 이유로는 불러오는 서버 데이터가 대부분 동일하지만 다른 경우도 있어서 타입을 다르게 줘야했고, URL을 쉽게 구분하기가 어려워서 한 곳에서 관리하고 싶었습니다(URL이 REST API 설계와 다소 거리가 있습니다.).

결론은, 함수 호출자의 입장(데이터를 불러오는 함수)에서 어디까지 알아야하나?가 고민입니다. 리액트 쿼리 깃허브에서 예시도 보고, 이렇게 글을 쓰다보니 현재로썬 2번이 더 맞다고 생각이 들긴 합니다. 여러분은 보통 어떤식으로 구현을 하시는지 궁금해서 이렇게 질문을 드리게 되었습니다.

어떤 의견이라도 좋으니 답변을 주시면 정말 감사할 것 같습니다!

포크코딩 · Answer

정확히 내부 구현은 모르겠으나, 질문하신 부분에서 재사용성과 유지보수 두 가지 판단 기준이 있다면 언제나 유지보수쪽을 고르는 것이 좋습니다.

본론, 커스텀 훅은 어디까지 추상화 하느냐? (1) 함수 호출자 입장에서 어디까지 알아야 하느냐?(2)

(1) 답: 
설계 수준에서 추상화 벽을 의미하는거 같지 않습니다. 따라서 함수형 컴포넌트 상단에 훅관련 코드가 5줄 이상되면 그냥 커스텀훅으로 빼세요.

(2) 답:
호출자 입장에서 ‘질의’를 하는 경우입니다. 
어떤 데이터 포맷으로 결과를 얻을 수 있는지?
위 포맷을 얻기위해 어떤 설정값이 존재하는지?

어떤 방식으로 구현하는가?(3)

(3)답:
함수 시그니처: useDashboardData(config: DashboardConfig) : Result

- 함수 이름에 얻고자 하는 데이터가 무엇인지 명시합니다. 훅들은 관례상 use…이기 때문에 표현상 직관적이기 때문입니다.
- 데이터 포맷과 범위에 대한 설정 관련 객체를 파라미터로 줍니다.
- 성공적으로 얻은 데이터 혹은 에러가 담긴 모나드를 받습니다.