시작

해당 데이터를 프론트에서 관리하는게 맞는지,
백엔드에서 관리하는지 고민하는게 간혹 있었다.

이번 프로젝트에서 유치원을 탈퇴한 강아지가 활성화 된 상태에서
강아지 관련 페이지 접속 시 특정 UI를 표시해야하며 열람만 가능해야 했다.

해당 기획 내용을 봤을 때 두 가지 고민을 하게 되었다.
탈퇴 유무를 판단하는 데이터를 프론트에서 관리하는게 맞을지 백엔드에서 관리하는게 맞을지 고민하게 되었고

2가지 선택지를 생각하게 되었다.

---

1. localStorage에 저장

메인 홈 api는 탈퇴 유무 데이터를 유일하게 가지고 있었다.
해당 강아지 관련 페이지를 접속하기 위해서는 무조건 홈을 거쳐야 했기에
useEffect를 활용해 첫 렌더링 시 해당 데이터를 localStorage에 저장하면 되지 않을까 싶었고 이를 커스텀 훅으로 만들어 활용하면 되겠다는 생각을 했다.

이렇게 생각한 이유는

• 단순 UI 수정을 위한 데이터로 api 수정 요청을 해야하는지 고민이 들었다.
• 메인 홈을 무조건 거쳐야하는 구조였다.
• localStorage에 저장했고 유저가 캐시 제거를 해도 로그인 후 무조건 메인 홈으로 가기 때문에 데이터가 초기화 될 경우는 없다 생각했다.

대신 단점도 존재했었다.

• 메인 홈의 데이터를 가져와 활용하기 때문에 의존성이 강해진다.
• 프론트에서 관리하기에 데이터가 일관되지 않을 수 있다.

2. api에 해당 데이터 추가 요청

api 하나만 수정하는게 아닌 강아지 관련 모든 페이지에 탈퇴 관련 데이터를 추가했어야 했다.

서버에서 데이터를 관리할 경우

• 프론트에서 관리하기 위해 작성된 코드가 간결해진다.
• 데이터를 항상 실시간으로 받아오기에 일관성이 있다.

번외) Tanstack Query의 기능 활용?

Tanstack Query의 캐싱 기능 을 활용하고자 했지만 getQueryData 메서드로 가져온 데이터는 새로고침 할 경우 초기화 되기에 자연스레 후보에서 제외하게 되었다.

최종 결론

Server에서 받아야하는 상태들의 특성

• Client에서 제어하거나 소유되지 않은 원격의 공간에서 관리되고 유지 되어야 한다.
• Fetching이나 Updating에 비동기 API가 필요하다.
• 다른 사람들과 공유되는 것으로 사용자가 모르는 사이에 변경 될 수 있다.
• 신경 쓰지 않는다면 잠재적으로 'out of date'가 될 가능성을 지닌다.

Client에서 받아야하는 상태들의 특성

• Client에서 소유하며 온전히 제어 가능하다.
• 초기 값 설정 조작에 제약사항이 없다.
• 다른 사람들과 공유되지 않으며, Client내 에서 UI/UX 흐름이나 사용자 인터렉션에 따라 변할 수 있다.
• 항상 Client 내에서 최신 상태로 관리된다.
  [LIVE] React Query와 상태관리 :: 2월 우아한테크세미나

이때 생각 났던게 유튜브 React Query 관련 강의내용이 였다.

해당 강사님은 데이터의 Owner Ship이 어디에 있는지 확인할 필요가 있다고 하셨다.

내용을 보자마자 아차 싶었다.

내가 너무 간단한 고민을 하고 있던게 아니 였을까?

무엇 보다 다른 팀원분들께 의견을 구했을 때도 2번을 제안하셨다.

결국엔 2번을 택하게 되었다.

무엇 보다 해당 데이터는 프론트에서 관리하는 데이터가 아니였고
메인 홈에서 데이터를 가져오다 보니 의존성 문제가 크지 않았을까 싶다.

또 다른 변수...

2번으로 진행을 하기로 했다.

문제는 내가 적용하려는 페이지 전부 같은 구조로 api를 호출하고 있지 않았다.

최상단에 UI를 표시하기 위해서는 해당 데이터도 최상위에 호출되어야한다.

다른 분이 작업하신 페이지의 경우 컴포넌트롤 분리하여
해당 컴포넌트에서 api를 다르게 호출하고 있었다.

그렇게 고민하던 와중...
팀원 분께 "2번으로 가되 탈퇴 여부를 확인 할 수 있는 api 추가 요청을 하는게 어떠시냐"고 말씀해 주셨다.

여기서 2차 아차 싶었다...!

필드를 추가했을 때만 생각 하고 있었다.
필드를 추가할 경우의 작업 량이 api 추가하는 것 보다 더 늘어나 있었다.

무엇 보다 api 추가시 공통 컴포넌트로 관리하기 더 수월하다는 점이다.

상황에 따라 적절하게 판단해야 하는게 중요하고
혼자 해결하기 애매한 경우 팀원 분들과 상의 했을 때 더 나은 선택을 할 수 있었던 것 같다.

코드 수정

// 전
export const useDogDisconnected = () => {
  const DOG_DIS_CONNECTIED = "DOG-DIS-CONNECTIED";

  const setStorage = useSetLocalStorage();
  const [isDisconnected] = useLocalStorage(DOG_DIS_CONNECTIED, false);

  // disconnected localStorage에 저장
  const setStorageDisconnected = (dogStatus: boolean) => {
    setStorage(DOG_DIS_CONNECTIED, dogStatus);
  };

  return { setStorageDisconnected, isDisconnected };
};

// 후
export const useDogDisconnected = () => {
  const dogId = useRecoilValue(dogIdState) as number;
  const isDisconnected = useGetDogDisconnect(dogId).data;

  return { isDisconnected };
};
.
.
.
export const useGetDogDisconnect = (dogId: number) => {
  return useSuspenseQuery({
    queryKey: queryKey.member.dog.disconnect.dynamic(dogId),
    queryFn: () => handleGetDogDisconnect(dogId),
    staleTime: 10 * 60 * 1000
  });
};

코드도 간결해 졌고 의존성도 낮아졌다.
isDisconnected는 거의 변하지 않기에 staleTime을 통해 호출을 지연 시켰다.
거의 변하지 않는다면 시간을 더 늘려도 괜찮지 않을까 싶은 생각도 들었다.

---

다음에도 비슷한 상황이 일어난다면

1. 해당 데이터의 Owner Ship이 어디에 있는지 생각해 보고,
2. 혼자 고민하기 애매하다면 팀원들과 공유해 다양한 의견 들어보자.

혼자 고민하다 아까운 시간만 소모했다..