활동 후기 탭 이동 & 무한 스크롤 조작 Issue

[joohaem]

활동후기 페이지에서는탭 이동(selected), 무한스크롤링(count) 기능이 동작합니다. 이 때 Issue가 있습니다.

(네트워크를 느리게 하여 디버깅하면 이슈 확인이 수월합니다)

• 데이터 패칭이 되기 전에 탭 이동을 빠르게 할 시에, 탭 정보와 데이터 정보가 일치하지 않음
• 이 상태에서 아래로 내려 무한 스크롤을 동작시킴
• 이 상태에서 다른 탭으로 이동시, 넘어가지 않는 것처럼 보임. (이는 사실 아래에 쌓이게 된 것)

stacked가 되어 있는 상태에서 (= isInitialFetching이 false인 상태에서) 다른 탭 선택 시에, 선택된 탭의 데이터가 빈 배열에 저장되지 않고, 기존 데이터에 stack 되어 저장됩니다.

이는 탭 이동 시에 state의 dispatch가 일어나는데 이 동작 이후에 count 값이 초기화되어 (useEffect return 동작) count 값이 초기화 되지 않은 상태에서 데이터가 패칭되고 stack 되어 쌓이게 됩니다.

willFetch함수와 count 값이 이후 동작으로 업데이트 됨으로써 (업데이트는 잘 동작함을 확인하였습니다) 데이터 패칭 또한 올바른 값으로 될 것을 기대하지만 ~useStackedFetchBase 커스텀 훅 안의 useEffect에서의 Batching 때문인지,~ 최신의 데이터 패칭이 동작하지 않는 것으로 보입니다.

---

const useFetch = (selected: ExtraPart) => {
  const { ref, count, setCount } = useInfiniteScroll();
  const [canGetMoreReviews, setCanGetMoreReviews, setCanNotGetMoreReviews] = useBooleanState(true);

  useEffect(() => {
    function initializeStates() {
      setCount(1);
      setCanGetMoreReviews();
    }
    return () => {
      initializeStates();
    };
  }, [selected, setCanGetMoreReviews, setCount]);

  const willFetch = useCallback(async () => {
    setCanNotGetMoreReviews();
    const response = await api.reviewAPI.getReviews(selected, count);
    response.hasNextPage ? setCanGetMoreReviews() : setCanNotGetMoreReviews();
    return response.reviews;
  }, [selected, count, setCanGetMoreReviews, setCanNotGetMoreReviews]);
  const state = useStackedFetchBase(willFetch, count === 1);

  return { state, ref, canGetMoreReviews };
};

[SeojinSeojin]

근본적인 원인은, "동시에 fetch 여러개가 돌아간다" 였습니다.

reducer.ts 에는 fetch는 한 번에 하나씩 돌아간다는 전제 하에 switch case 문이 쓰여졌어요

그러나 현실에서는 요청이 두 가지 이상 갈 수 있습니다.

그래서 어떤 일이 생기느냐?!?

OK인 경우에 Success를 받아주는 부분이 없어서, 저 fetch는 갈 길을 잃고 맙니다 ........

[SeojinSeojin]

해결방법 세가지가 있을 것 같습니다!!

1. reducer에서 prevState가 OK일 때도 Success action을 받는 부분을 추가한다.

2. 새로운 fetch 요청이 가면 기존 fetch 요청을 중지하도록 한다.

3. 미련 없이 React Query를 사용한다

[joohaem]

https://github.com/sopt-makers/sopt.org-frontend/pull/133

1. reducer에서 저희가 제어하지 않는 경우의 수를 나누고 올바르게 관리하지 못한 것 같습니다. 유효한 상태를 설계하지 못하여, reducer에서 action을 통해 나누어 관리하도록 리팩토링합니다.
2. Debounce 코드를 이용하여 해결하였습니다.
3. 라이브러리의 도움 없이 구현해보았으니, 다음부터는 .. 사용해보고자 합니다 :))