React Query의 useInfiniteQuery와 Prisma의 Cursor-based pagination을 사용하여 무한 스크롤에 필요한 모든 것을 구현해 보겠습니다! 이번 구현에 사용한 데이터는 아래 첨부한 이미지와 같으며, 전체 코드는 이 곳에서 확인하실 수 있습니다!

효율적인 정보 전달을 위해 React Query와 Prisma의 기본적인 사용법은 모두 숙지 되었다는 가정하에, 무한 스크롤 구현에 필요한 기능들만 간단하게 다루겠습니다.

출발~ 😙😙😙

Pagenation

당연히~ 가장 먼저 서버를 구현해야 합니다. 전체 데이터 중 원하는 개수씩 순차적으로 끊어서 보내줄 수 있도록 prisma query를 작성해 보겠습니다!

Pagenation을 어떻게 구현해야 할까?

처음에는 단순하게 개수를 기준으로 전체 데이터를 끊으려고 했습니다. 예를 들어, 다음과 같이 (유저1, 유저2, 유저3, 유저, 유저10) 총 10개의 데이터가 있다고 가정해 보겠습니다. 한 번에 5개씩 데이터를 보여주고 싶다면, 처음에는 15번 데이터를 불러오고 그 다음에는 6~10번 데이터를 불러오면 될 것입니다. 이 방법은 아래와 같은 코드로 구현할 수 있습니다.

const userList = await prisma.user.findMany({
  skip: 5 * page,
  take: 5,
})

15개의 데이터를 건너뛰고 16번째 데이터부터 20번째 데이터까지 불러오고 싶으면 skip에 15를, take에 5를 넣어주면 됩니다. 간단하죠? Prisma의 공식문서에서는 해당 기능을 아래와 같은 이미지로 설명하고 있습니다.

간단하게 구현할 수 있는 방법이지만, 약간의 문제가 있습니다. 만약, 최근에 가입된 유저 순으로 정렬하여 데이터를 불러오다가 새로운 유저가 회원가입하면 어떻게 될까요? 아래 메모장의 설명처럼 유저5가 두 번 불러와 질 것입니다.

따라서 개수를 기준으로 정하는 것이 아닌, 현재 페이지의 마지막 데이터를 기준으로 다음 페이지의 데이터를 불러와야 합니다. 위의 예시에서는 유저5를 기준으로 다음 페이지의 데이터를 불러와야겠죠? Prisma의 Cursor-based-pagination으로 이러한 방법을 간단하게 구현할 수 있습니다.

const userList = await prisma.user.findMany({
  skip: 1,
  take: 5,
  cursor: {
    id: targetId
  }
})

위 코드의 예시처럼 cursor 객체에 조건을 설정하여 해당 조건에 맞는 데이터를 기준으로 정할 수 있습니다. 도입부에 첨부된 User Table 이미지 기억나시나요? User Table은 id, nickname, password의 필드로 구성되어 있습니다. 이 중 고유한 값인 id 필드가 지정한 값(targetId)인 데이터가 기준이 됩니다. nickname 필드 또한 고유한 값이라면, id 대신 nickname을 사용할 수도 있습니다.

근데 skip은 왜 또 필요할까요? 마찬가지로 Prisma의 공식문서를 확인해 보겠습니다.

바로 cursor를 포함하여 take개를 가져오기 때문입니다. 저희는 현재 페이지의 마지막 데이터를 cursor로 정하기로 했으니, skip: 1이 필요한 것입니다.

이제 정말 구현해볼까요?!

/* /pages/api/userList.ts */

const TAKE_COUNT = 5;

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse<IUserResponse>
) {
  const { id } = req.query;
  const isFirstPage = !id;

  const pageCondition = {
    skip: 1,
    cursor: {
      id: id as string,
    },
  };

  const userList = await client.user.findMany({
    /*
    where: { },
    orderBy: { }
    */
    take: TAKE_COUNT,
    ...(!isFirstPage && pageCondition),
  });

  const length = userList.length;
  res.status(200).json({ userList: 0 < length ? userList : undefined });
}

현재 페이지 마지막 데이터의 id를 query parameter로 받아옵니다. 만약, 첫 페이지의 데이터를 불러오는 경우라면 당연히 id가 존재하지 않겠죠? 따라서 isFirstPage가 true일 경우 skip과 cursor를 설정하지 않습니다.

페이지를 쭉쭉 넘겨 cursor가 전체 데이터의 마지막 데이터가 됐을 경우, 더 이상 불러올 데이터가 없기 때문에 findMany 함수는 빈 배열을 return합니다. 그렇기 때문에 userList의 length를 확인하여 0 < length일 때만 userList를 return하고 그렇지 않을 경우 undefined를 return합니다.

살짝 싱숭생숭 하신가요?

현재 페이지 마지막 데이터의 id를 어떻게 넘겨주는지? 왜 굳이 undefined를 return하는지? 이런 부분들은 다음 차례인 React Query의 useInfiniteQuery 구현 방법을 확인해 보시면 명확해지실 겁니다!

useInfiniteQuery

const {
  data,
  hasNextPage,
  fetchNextPage,
} = useInfiniteQuery({
  queryKey,
  queryFn: ({ pageParam = "" }) => fetchPage(pageParam),
  getNextPageParam: (lastPage, allPages) => lastPage.nextCursor,
})

위의 예시 코드가 구현에 필요한 전부입니다! useInfiniteQuery는 굉장히 많은 기능들을 제공하지만, 무한 스크롤 구현을 위한 최소한의 기능들만 하나씩 살펴보겠습니다.

1. getNextPageParam : pageParam과 hasNextPage의 값을 결정하는 함수이며, 매개변수로 lastPage와 allPages를 넘겨 받을 수 있습니다. lastPage는 공식문서에서 '마지막 페이지'라는 뜻으로 사용되는데요, 저희는 지금까지 '현재 페이지'라는 단어를 사용했기 때문에 편의상 '현재 페이지'라고 부르겠습니다! getNextPageParam은 단일 변수 혹은 undefined를 return 해야 합니다. 이렇게 return된 값은 queryFn의 pageParam과 hasNextPage의 값으로 사용됩니다.

2. data : 서버로부터 응답받은 결과이며, 우리가 원하는 TData[]는 data.pages에 담겨 있습니다.

3. hasNextPage : 다음에 더 불러올 페이지가 있는지 확인할 수 있는 값입니다. 이 값은 getNextPageParam에 의해 결정됩니다. getNextPageParam가 단일 변수를 return할 경우 true, undefined를 return할 경우 false가 됩니다.

4. queryFn: ({ pageParam = "" }) : getNextPageParam이 return한 값이 pageParam의 값으로 사용됩니다. 최초 요청 시 정의한 기본 값이 사용됩니다. (예시에서는 "")

5. fetchNextPage : 다음 페이지를 요청할 때 호출하는 함수입니다.

6. 전체적인 흐름은 다음과 같습니다.

   1. hasNextPage = !!getNextPageParam()
   2. hasNextPage가 true이면 fetchNextPage()
   3. pageParam = getNextPageParam()
   4. fetchPage(pageParam)
   5. render(data.pages)

구현된 코드를 살펴보겠습니다!

/* /queries/user.ts */

export function useFetchUserList() {
  const queryResult = useInfiniteQuery<IUserResponse>(
    ["user"],
    ({ pageParam = "" }) => get(`?id=${pageParam}`),
    {
      getNextPageParam: ({ userList }) =>
        userList ? userList[userList.length - 1].id : undefined,
    }
  );

  return queryResult;
}

const service = axios.create({
  baseURL: "/api/userList",
});
function get(queryString: string) {
  return service.get(queryString).then((response) => response.data);
}

기능 단위로 쪼개고 서버 코드와 함께 살펴보겠습니다.

/* /queries/user.ts */

({ pageParam = "" }) => get(`?id=${pageParam}`)

/* /pages/api/userList.ts */

const { id } = req.query;
const isFirstPage = !id;

pageParam을 query parameter를 통해 서버로 전송합니다. 최초 요청 시 기본 값이 ""이기 때문에 isFirstPage는 true가 됩니다.

/* /queries/user.ts */

getNextPageParam: ({ userList }) =>
  userList ? userList[userList.length - 1].id : undefined;

/* /pages/api/userList.ts */

const pageCondition = {
  skip: 1,
  cursor: {
    id: id as string,
  },
};

getNextPageParam에서 현재 페이지의 userList가 존재한다면? userList의 마지막 데이터의 id를 return하여 queryFn의 pageParam으로 사용합니다. 이렇게 서버로 전달된 id가 cursor로 사용되는 것입니다.

현재 페이지의 userList가 존재하지 않는 경우는 어떤 경우일까요?

/* /pages/api/userList.ts */

const userList = await client.user.findMany({
  /*
    where: { },
    orderBy: { }
    */
  take: TAKE_COUNT,
  ...(!isFirstPage && pageCondition),
});

const length = userList.length;
res.status(200).json({ userList: 0 < length ? userList : undefined });

서버 코드를 설명할 때 더 이상 불러올 데이터가 없을 경우 undefined를 응답한다고 했습니다. 현재 페이지의 userList가 존재하지 않는 경우는 더 이상 불러올 데이터가 없을 때이므로 getNextPageParam는 undefined를 return하여 hasNextPage가 false가 되는 것입니다.

이제 데이터를 불러오기만 하면 됩니다!

/* /pages/index.tsx */

export default function Home() {
  const { data, hasNextPage, fetchNextPage } = useFetchUserList();

  const handleClick = () => {
    if (hasNextPage) {
      fetchNextPage();
    }
  };

  const renderUserList = () => {
    if (data && data.pages) {
      const userList = data.pages.reduce<IUser[]>((prev, { userList }) => {
        if (userList) prev.push(...userList);
        return prev;
      }, []);

      return userList.map(({ id, nickname }) => (
        <User key={id} id={id} nickname={nickname} />
      ));
    }
  };

  return (
    <Wrapper>
      {renderUserList()}
      {hasNextPage && <Button onClick={handleClick}>Next Page</Button>}
    </Wrapper>
  );
}

data.pages는 [[], [], [], []]와 같은 형식으로 되어있습니다. 이를 1차원 배열로 풀기 위해 renderUserList 함수에서 reduce를 사용했습니다. 우선 데이터를 page 단위로 잘 불러오나 확인하기 위해 버튼을 두었고 이를 누를 때마다 다음 페이지 데이터를 불러오도록 하였습니다.

잘 되나 볼까요?

Intersection Observer API

이제 마지막입니다! 버튼을 눌렀을 때가 아닌 스크롤을 바닥까지 내렸을 때 다음 페이지를 불러와야 합니다. 이러한 기능을 구현하기 위해 바닥에 div 태그를 두고 이 태그가 뷰포트 내에 감지됐을 때 fetchNextPage 함수를 호출할 것입니다.

Intersection Observer API를 사용하면 특정 요소와 상위 요소의 뷰포트가 교차하는 것을 감지할 수 있습니다. 바로 구현된 코드를 확인해 보겠습니다.

/* /components/Observer.tsx */

export default function Observer({ handleIntersection }: IProps) {
  const target = useRef(null);

  useEffect(() => {
    const observer = new IntersectionObserver(
      ([entry]: IntersectionObserverEntry[]) => {
        if (entry.isIntersecting) {
          handleIntersection();
        }
      },
      { threshold: 1 }
    );

    if (target.current) {
      observer.observe(target.current);
    }

    return () => observer.disconnect();
  }, []);

  return <Wrapper ref={target}>이게 보이면? 다음 데이터를!</Wrapper>;
}

IntersectionObserver 객체를 생성할 때 매개변수로, 감지됐을 때 호출될 콜백 함수를 넣어줄 수 있습니다. 이 콜백 함수는 observer.observe(target.current)로 처음 감지를 시작했을 때도 호출 됩니다. 따라서 원하는 요소가 감지됐을 때만 fetchNextPage를 호출하기 위해 entry.isIntersecting로 감지 여부를 확인하는 과정이 필요합니다.

마지막으로, 이전에 추가해놓은 버튼을 제거하고 Observer 컴포넌트를 적용해 보겠습니다.

/* /pages/index.tsx */

export default function Home() {
  const { data, hasNextPage, fetchNextPage } = useFetchUserList();

  const handleIntersection = () => {
    if (hasNextPage) {
      fetchNextPage();
    }
  };

  const renderUserList = () => {
    if (data && data.pages) {
      const userList = data.pages.reduce<IUser[]>((prev, { userList }) => {
        if (userList) prev.push(...userList);
        return prev;
      }, []);

      return userList.map(({ id, nickname }) => (
        <User key={id} id={id} nickname={nickname} />
      ));
    }
  };

  return (
    <Wrapper>
      {renderUserList()}
      {hasNextPage && <Observer handleIntersection={handleIntersection} />}
    </Wrapper>
  );
}

완성 ~!

Observer 컴포넌트의 높이를 작게 하고 배경색과 동일하게 하면 아주 자연스러운 동작이 가능합니다!

마무리

최대한 간략하게 정리해보고 싶었는데 이상하게 글이 길어졌네요. 잘못된 내용은 지적해주시면 정말 감사하겠습니다.

안녕~ 😙

개요 😎

개인 프로젝트로 대학 시간표 관련 서비스를 만들고 있다. 에브리타임(https://everytime.kr/)을 참고하여 시간표 추가 화면을 구현하던 중에 Next.js의 Large Page Data Warning이 발생하여 해결했는데, 해결 과정에서 배운 것이 많아 정리해 보았다.

문제 😇

학교 홈페이지에 공개된 강의 시간표(.excel)를 필요한 정보만 추출하고 .json 파일로 만들어서 시간표 추가 화면에서 사용하였다.

강의 시간표는 학기가 시작되면 거의 바뀌지 않기 때문에, getStaticProps에서 .json 파일을 읽어와 pageProps를 통해 넘겨주는 방식으로 구현하였다. 이번 프로젝트를 통해 Next.js를 처음 사용해보았는데, getStaticProps를 사용하여 외부 데이터를 불러오니 컴포넌트에서 isLoading과 같은 비동기 서버 상태를 관리할 수고를 덜 수 있고 컴포넌트 내부 코드도 간결해져 굉장히 만족스러웠다.

술술 풀리나 했는데...

빌드 중에 Warning: data for page "/add" is 1.17 MB which exceeds the threshold of 128 kB, this amount of data can reduce performance. 경고 문구가 콘솔에 출력되는 것을 보았다. getStaticProps에서 2개 학기의 강의 시간표를 모두 불러왔더니 add.html 파일의 사이즈가 1 MB가 넘어버렸다. 128 KB를 초과하는 양의 데이터는 성능을 저하시킬 수 있다고 하여 LightHouse로 측정해보았다.

성능에는 큰 문제 없어 보이지만...

당장은 문제가 안되더라도 추후 서비스를 지속적으로 운영한다고 가정 했을 때 제공하는 모든 학기의 데이터를 하나의 HTML 파일에 모두 담는 것은 좋은 구현 방법이 아니라고 생각했다. (1년치 데이터가 1.17 MB, 10년치 데이터는 11 MB...?!)

우선 문제 해결에 앞서 정확히 어떤 문제인지 파악해야 하기 때문에 공식 문서를 찾아봤다. https://nextjs.org/docs/messages/large-page-data

SSR(Server-Side Rendering)의 구동 방식은 브라우저가 server-side에서 만들어진 정적 HTML을 먼저 받아 rendering 한 뒤, page 구동에 필요한 JS를 받는다. 이후 정적 HTML에 JS를 연결하는 과정을 거치는데, 이러한 과정을 수화(Hydration)라고 한다. 공식 문서를 확인해보면 client는 수화하기 전에 page data를 구문 분석한다고 명시되어 있다. page data가 커지면 커질수록 구문 분석에 많은 시간이 소요되고 그만큼 수화 과정이 지연될 수 있으므로 page data의 임계를 128 KB로 정한 것 같다.

강의 시간표 불러오는 방법을 개선하여 이 문제를 해결한다면 HTML이 가벼워져, FCP와 LCP 등의 성능 지표가 개선될 것이고 구문 분석에 소요되는 시간이 줄어 TTI 또한 개선되지 않을까? 하는 설레는 마음으로 개선 방법을 고민하였다.

해결 🤔

page data의 양이 임계를 초과하여 발생한 문제이므로, getStaticProps에서 불러올 데이터의 양을 줄여야 했다. 기존의 .json 파일에서 학기에 따른 카테고리(전공 or 교양) 목록을 분리하고 해당 파일만 불러와 HTML을 미리 만들어두고 카테고리에 해당하는 강의 목록은 프론트 단에서 react query를 사용하여 page가 rendering될 때 불러오는 방식으로 수정하였다.

export async function getStaticProps() {
  const folderPath = path.join(process.cwd(), "/public/static/timetables/json");

  const categoryFilePath = `${folderPath}/categoryMap.json`;
  const categoryFileData = fs.readFileSync(categoryFilePath, "utf-8");
  const categoryMap = JSON.parse(categoryFileData) as ICategoryMap;
  const semesters = Object.keys(categoryMap);

  return {
    props: {
      semesters,
      categoryMap,
    },
  };
}

// semesters와 categoryMap은 pageProps로 받아온다.
function useFilterTimetables(semesters: string[], categoryMap: ICategoryMap) {
  const [semester, setSemester] = useState(semesters[0]);
  const categories = categoryMap[semester];
  const [category, setCategory] = useState(categories[0]);
  const [keyword, setKeyword] = useState("");

  const { data: filteredTimetables } = useTimetables(semester, category, keyword);

  return {
    semesters,
    semester,
    setSemester,
    categories,
    category,
    setCategory,
    keyword,
    setKeyword,
    filteredTimetables: filteredTimetables,
  };
}

성능을 측정 해볼까?!

getStaticProps에 모든 데이터를 몰아 넣어 Large Page Data Warning이 발생했을 때보다 성능이 낮게 측정되었다. 가장 크게 문제가 되는 LCP는, HTML rendering --> JS Download --> Hydration 의 모든 과정을 거치고 나서야 react query를 통해 강의 목록 data를 불러오는 것이기 때문에, 강의 목록이 기존보다 늦게 rendering 되어서 발생한 것이다.

풀 다운 메뉴로 선택하는 학기와 카테고리(전공 or 교양)는 고정된 값이기 때문에 첫 번째 학기(2022-02)와 첫 번째 카테고리(국어국문학과)의 강의 목록 또한 고정된 값이다. 따라서 가장 먼저 표시되는 2022-02 학기의 국어국문학과 강의 목록 또한 getStaticProps에서 불러온 뒤 pageProps로 넘겨주는 것이 성능 개선에 도움 될 것이라고 생각되어 수정하였다.

export async function getStaticProps() {
  const folderPath = path.join(process.cwd(), "/public/static/timetables/json");

  const categoryFilePath = `${folderPath}/categoryMap.json`;
  const categoryFileData = fs.readFileSync(categoryFilePath, "utf-8");
  const categoryMap = JSON.parse(categoryFileData) as ICategoryMap;
  const semesters = Object.keys(categoryMap);

  const semester = semesters[0];
  const categories = categoryMap[semester];
  const category = categories[0];

  const timetablesFilePath = `${folderPath}/${semester}.json`;
  const timetablesFileData = fs.readFileSync(timetablesFilePath, "utf-8");
  const timetables = JSON.parse(timetablesFileData) as ITimetable[];
  const firstIndexTimetables = timetables.filter(
    (timetable) => timetable.category === category
  );

  return {
    props: {
      semesters,
      categoryMap,
      firstIndexTimetables,
    },
  };
}

현재 react query는 아래와 같이 사용하고 있는데, query key ['2022-02', '국어국문학과', '']의 데이터는 pageProps를 통해 받아오는 것으로 수정했기 때문에 초기 query key에서는 fetch를 할 필요가 없다.

  const queryString = `?semester=${semester}&category=${category}&keyword=${keyword}`;

  const filteredTimetables = useQuery<ITimetable[]>(
    [semester, category, keyword],
    () => get(timetablesService, queryString),
    { staleTime: 60 * 1000 * 60 }
  );

불필요한 네트워크 요청을 막기 위해 아래와 같은 방법으로 initialData를 추가하였다.

export function useTimetables(
  semester: string,
  category: string,
  keyword: string,
  useInitialData: boolean,
  initialData: ITimetable[]
) {
  const queryString = `?semester=${semester}&category=${category}&keyword=${keyword}`;

  const filteredTimetables = useQuery<ITimetable[]>(
    [semester, category, keyword],
    () => get(timetablesService, queryString),
    { initialData: useInitialData ? initialData : undefined, staleTime: 60 * 1000 * 60 }
  );

  return filteredTimetables;
}

결과는?!

의도했던 대로 LCP가 개선되었다!

이렇게 강의 목록을 불러오는 방식을 변경하여 Large Page Data Warning을 해결하고 1 MB가 넘던 HTML 파일의 크기를 140 KB로 줄일 수 있었다. 😀

이번 과제는~ 광고 플랫폼 대시보드를 만드는 것이다!

🥰 열심히 노력한 8팀의 결과물 🥰 (혹시 모를 보안상의 이유로 생략!)

😎 난 뭘 했나?!

• react query를 사용한 데이터 통신 구현
  • 통합 광고 현황 불러오기
  • 매체 현황 불러오기
  • 광고 목록 불러오기
  • 광고 추가, 수정 및 삭제

😵 고민... 그리고 또 고민...

과제를 진행하면서 했던 고민들과 상세한 작업 내용을 기록해보자!

caching을 사용하자!

이번 과제에서는 대시보드에서 데이터를 주차별로 불러오거나, 광고의 진행 상태를 구분하여 불러오는 등 데이터를 선택하여 불러오는 경우가 많았다. 풀다운 메뉴를 통해 유저가 선택한 주의 데이터만 불러오는데, 유저가 5주차까지 데이터를 확인한 후 다시 1주차 데이터를 보고 싶어 1주차를 선택했을 경우, 1주차 데이터를 새로 불러올 필요가 있을까? 에 대한 고민을 하게 되었다.

불필요한 request를 막아, 속 시원한 사용자 경험을 제공하기 위해 caching을 사용하고 싶었고 caching을 가장 간단한 방법으로 구현할 수 있는 react query를 사용하기로 하였다.

react query 말고 다른 대안은 없었나?

수많은 서버 상태 관리 라이브러리 중에서 react query를 선택한 이유는, 가장 많이 사용되는 라이브러리였기 때문이다.

가장 많이 사용되기 때문에, 참고할 수 있는 자료가 많을 것이고 참고할 수 있는 자료가 많기 때문에, 다른 라이브러리에 비해 상대적으로 배우기 쉬울 것이라고 판단했다.

1주일 동안 과제를 진행하면서, 본인 작업 외의 다른 팀원들의 코드를 보는 것은 쉬운 일이 아니다. 더욱이 서버 상태 관리 라이브러리를 사용해 본 적이 없는 팀원들이 더 많았기 때문에, 라이브러리 선정은 러닝커브를 최우선으로 고려하였다.

네~ 드셔도 됩니다~

react query는 key를 기준으로 cache된 데이터를 관리하기 때문에, 아래 코드와 같이 데이터를 구분하는 string과 시작 날짜(startDate)를 key로 지정하여 관리하였다.

export function useGetDashboard(startDate: string, endDate: string) {
  const query = `?date_gte=${startDate}&date_lte=${endDate}`;

  const overall = useQuery([OVERALL, startDate], () => get(overallService, query));
  const platform = useQuery([PLATFORM, startDate], () => get(platformService, query));

  return [overall, platform];
}

key를 기준으로 데이터가 cache되어 있다고 해서 react query가 데이터를 새로 요청하지 않는 것이 아니다. react query는 해당 데이터가 신선하지 않다고 판단되면, 서버에 새로운 데이터를 요청한다. 따라서 staleTime을 설정하여, 내가 불러온 데이터는 이 동안은 신선하다! 그러므로 새로운 데이터를 요청할 필요가 없다! 라는 것을 react-query에게 알려주어야 한다.

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 1000 * 60,
    },
  },
});

완성!

첫 선택은 데이터를 요청하지만, 이후부터는 데이터를 새로 요청하지 않는 것을 확인할 수 있다!

변경된 데이터를 불러옵시다!

광고 데이터를 추가, 수정, 삭제하면 변경된 데이터를 새로 불러와야 한다. 위의 첨부한 영상은 데이터 삭제를 위한 mutate 이후 아무런 동작도 하지 않아, 광고 목록이 변경되지 않는 것이다. 특별한 작업 없이, 기존에 관리되던 쿼리(key)를 무효화하는 것으로 해결할 수 있다.

export function useDeleteCampaign(id: number) {
  const query = `/${id}`;
  const { mutateAsync } = useMutation(() => _delete(campaignService, query));

  const queryClient = useQueryClient();

  return async function () {
    await mutateAsync();
    await invalidateQueriesByName(queryClient, CAMPAIGN_CONSTANTS.CAMPAIGN);
  };
}

type typeDataName = typeof OVERALL | typeof PLATFORM | typeof CAMPAIGN;
export function invalidateQueriesByName(queryClient: QueryClient, name: typeDataName) {
  return queryClient.invalidateQueries({
    predicate: (query) => {
      return query.queryKey[0] === name;
    },
  });
}

공식 문서의 invalidateQueries 부분을 읽어보면, staleTime이 만료되지 않은 상태이더라도 무효화한 쿼리를 stale 상태로 변경하고 useQuery hook을 통해 데이터를 새로 불러온다는 것을 알 수 있다. invalidateQueries를 사용함으로써 복잡한 로직 추가 없이 변경된 데이터를 새로 불러올 수 있었다.

우아한 비동기처리 흉내내기!

이번 과제의 대시보드 탭에서는 통합 광고 현황(overall)과 매체 현황(platform) 2개의 데이터를 불러와야 했다. 통합 광고 현황의 경우 지난 주차의 데이터와 비교하여 증감을 표시해야 했기 때문에 총 3개의 비동기 데이터의 상태를 관리해야 했다. 만약 비동기 데이터의 상태를 컴포넌트 내부에서 관리했다면, 코드는 아래와 같았을 것이다.

function DashboardContainer() {
  const [prevOverall] = useGetDashboard(prevStartDate, prevEndDate);
  const [currOverall, currPlatform] = useGetDashboard(currStartDate, currEndDate);

  if (prevOverall.isLoading) {
    return <Loader />;
  }
  if (currOverall.isLoading) {
    return <Loader />;
  }
  if (currPlatform.isLoading) {
    return <Loader />;
  }

  return <></>;
}

이러한 문제를 해결할 방법을 찾던 도중에 아래의 영상을 보게 되었다.

https://www.youtube.com/watch?v=FvRtoViujGg (토스ㅣSLASH 21 - 프론트엔드 웹 서비스에서 우아하게 비동기 처리하기)

함수 본래의 역할 외의 코드들이 많아지면, 함수의 크기가 커지고 복잡도가 높아지기 때문에 함수의 역할이 흐려지고 어떤 함수인지 파악하기 힘들어진다. 따라서 성공하는 경우에만 집중하여 함수의 복잡도를 낮춰 함수가 하는 일을 명확하게 드러낼 수 있도록 해야 한다.

컴포넌트에서 성공한 상태에만 집중할 수 있도록 로딩 상태를 외부에 위임함으로써 동기적인 코드와 큰 차이 없는 코드를 만들어 컴포넌트의 역할을 명확하게 하는 것을 목표로 한다. 이러한 목표 달성을 위해 해당 영상에서는 suspense를 이용하는 방법을 가이드 해 주고 있다.

도전!

// pages/dashboard/index.tsx

<Suspense fallback={<Loader />}>
  <DashboardContainer
    currStartDate={currStartDate}
    currEndDate={currEndDate}
    prevStartDate={prevStartDate}
    prevEndDate={prevEndDate}
  />
</Suspense>

// pages/dashboard/DashboardContainer.tsx

function DashboardContainer() {
  const [{ data: prevOverall }] = getDashboard(prevStartDate, prevEndDate);
  const [{ data: currOverall }, { data: currPlatform }] = getDashboard(currStartDate, currEndDate);

  return <></>;
}

컴포넌트 내부 비동기 데이터의 로딩 상태를 컴포넌트를 쓰는 곳, suspense에 위임하여 우아한 비동기 처리를 흉내 내보았다!

이번 과제는~ https://snplab.io 에스앤피랩의 기업 과제로 지원 화면과 관리자 페이지를 만드는 것이다!

🥰 열심히 노력한 8팀의 결과물 🥰 (혹시 모를 보안상의 이유로 생략!)

😎 난 뭘 했나?!

• 지원 화면 폼 구현
  • 지원자의 정보를 입력할 수 있는 6개의 input 구현
  • input에 validation 적용
  • scroll 가능한 picker 구현

😵 고민... 그리고 또 고민...

과제를 진행하면서 했던 고민들과 상세한 작업 내용을 기록해보자!

반복되는 코드를 어떻게 깔끔하게 줄일까?

지원자의 정보를 입력받는 text input은 placeholder와 validation 등 약간의 설정 차이만 있을 뿐 모두 동일한 기능을 가지고 있다. 따라서 5개의 text input을 일괄적으로 관리하고 그려낼 방법을 고민하였다.

관심사를 분리하자!

input의 설정들과 validation에 필요한 정규식을 별도의 파일로 관리하고 설정들을 모아 배열로 만들어, 5개의 input을 반복문을 통해 일괄적으로 그려주었다.

radio button은 2번째에 위치해야 하는데요?

에스앤피랩의 과제 명세에는, 이름 다음에는 성별을 선택할 수 있는 radio button이 위치해야 한다고 명시되어 있다. 하지만, 위의 코드와 같이 반복문을 통해 input을 일괄적으로 그릴 경우 radio button은 6번째에 위치하게 된다. 이러한 문제를 해결하기 위해 CSS의 order 속성을 이용하였다.

적절한 도구를 사용해볼까?

input을 제어하고 validation 하려면 value와 error, 최소 2개의 state가 필요하고 추가로 onChange event까지 handling 해주어야 한다. 5개의 input에 이를 모두 구현하는 것은 비생산적인 업무라고 판단했다. 따라서 이러한 문제를 효율적으로 해결할 수 있는 react-hook-form을 사용하기로 하였다.

option: {
  required: true,
  pattern: {
    value: EMAIL_VALIDATION,
    message: '"@", ".com"을 필수로 입력해주세요.',
  },
}

react-hook-form은 위와 같은 방식으로 input에 validation을 설정할 수 있다. form이 submit 되면, 설정한 정규식과 input의 value를 비교하여, 일치하지 않을 시 설정한 message를 errors 객체에 담아준다. 이렇게 validation의 실행과 error state의 관리를 위임할 수 있다.

picker를 만들자!

https://www.youtube.com/watch?v=qHzSQrLjxlQ

어떻게 만들어야 할까...? 를 고민하던 중에 코딩애플님의 이미지 슬라이더를 만드는 유튜브를 보게 되었다. 영상 내용을 간단하게 요약해 보자면, 선택 가능한 모든 item 그려놓고 부모 컴포넌트의 overflow 속성을 hidden으로 설정하여 당장 보일 필요가 없는 item들은 숨긴다. 그리고 유저의 입력에 따라 item들의 위치를 변경하면, 완성!

스크롤을 동작하거나 item을 click하면 index를 변경한다. 예를 들어, scroll을 아래로 내리거나, 현재 선택된 item보다 밑에 있는 item을 선택하면 index를 증가시킨다. 이렇게 변화하는 index에 따라 item 목록의 Y 값을 조절하면 완성!

로직을 한 눈에 파악하기 쉽게 overflow: hidden을 제거해보면?

overflow: hidden이 얼마나 중요한 역할을 하는지 확인할 수 있다!

데이터를 또 불러와야 할까요?

관리자는 우리 팀이 만든, 위와 같이 생긴 페이지에서 다양한 기준으로 지원자들을 정렬하여 확인할 수 있다. 이번 과제의 작업에 들어가기 전, 팀원 모두가 모여 과제를 분석하고 설계할 때 서버로부터 데이터를 불러오는 것은 admin page가 mount 됐을 때, 딱 한 번만 하는 것으로 결정하였다. 관리자가 페이지를 이동하거나 정렬 기준을 변경할 때마다 새로운 데이터를 불러온다면, 지나친 로딩 시간으로 좋은 사용자 경험을 제공하지 못할 것이라고 판단했기 때문이다.

그럼, 데이터의 신뢰성은 어떻게 보장하죠?

중간 발표 때 위의 내용을 발표하였더니, 멘토님께서 데이터의 신뢰성을 어떻게 보장할 것인지 여쭤보셨다. 데이터를 한 번만 불러오기 때문에, 관리자가 admin page에 진입한 이후에 추가된 지원자는 목록으로 보여줄 수 없는 문제가 있었기 때문이다.

나는 이번 과제는 데이터의 신뢰성을 보장할 필요가 없다고 생각했다. 보통 지원을 받을 때는 마감 기한이라는 것이 존재하고, 관리자가 admin page를 본격적으로 사용하는 때는 마감 이후일 것이며, 마감을 못 맞춘 지원자는 포함할 필요가 없을 것이라고 생각했기 때문이다.

하지만, 또 곰곰이 생각해 보니, 이렇게 극단적이고 엄격(😢)한 사용자 경험 또한 좋지 못할 것이라고 판단하여 안전장치를 추가로 마련하기로 하였다.

admin page 우측 상단에 새로운 데이터를 갱신할 수 있는 버튼을 구현하였다. 해당 버튼을 click하면, 서버로부터 새로운 데이터를 갱신해오고, 가장 최근 갱신된 시각을 표시하였다. 이렇게 함으로써 속도와 신뢰성 두 마리(🐰)를 다 잡을 수 있었다!

다른 서비스들은 어떻게 하고 있을까?

모든 구현을 마치고 완성된 과제를 돌아보던 중, 실제 운영 중인 서비스들은 어떻게 하고 있는지 궁금하였다. 그러던 중 팀원이 보내준 링크를 확인하였는데...

https://www.ontactlearning.com/c91af4b4-1ad0-4ffa-bfd5-bad51deef563

우리 팀의 의도와 동일한 방식으로 서비스 중인 업체가 있다는 것을 확인하고, 해당 서비스를 레퍼런스 삼아 자신있게 발표할 수 있었다!

이번 과제는~ https://www.tripbtoz.com 트립비토즈의 기업 과제로 간단한 호텔 예약 서비스를 만드는 것이다!

🥰 열심히 노력한 8팀의 결과물 🥰 (혹시 모를 보안상의 이유로 생략!)

😎 난 뭘 했나?!

• 상단 서치 바 구현
  • 데스크탑, 태블릿, 모바일 사이즈 적응형 + 반응형으로 대응
  • 설정된 검색 조건 전역 상태로 관리
  • 검색 입력창에 debounce 적용
  • 스크롤 방향에 따라 표시 여부 결정
  • 팝업
    • 데스크탑 - 포커스를 잃으면 자동으로 닫힘
    • 모바일 - 전체 화면을 모두 덮고 내부 컴포넌트 스크롤 가능

😵 고민... 그리고 또 고민...

과제를 진행하면서 했던 고민들과 상세한 작업 내용을 기록해보자!

기기별 사이즈 대응, 어떻게 할까?

나는 여태껏 제대로 된 반응형 디자인을 구현해 본 경험이 없었다. 기껏해야 flex 혹은 grid를 사용하여 전체적인 너비를 조정하는 것 정도? 하지만, 이번 과제의 서치 바는 꽤 많은 것들이 변해야 했다.

가장 큰 변화는, 검색 조건 변화 이후의 동작이다. 데스크탑 사이즈에서는 검색 버튼을 눌렀을 때 설정된 검색 조건을 반영하여 새로운 데이터를 불러오지만, 모바일 사이즈에서는 검색 조건이 변하는 즉시 반영하여 새로운 데이터를 불러와야 했다. 이 외에도 팝업 변경과 검색 input에 debounce 적용 등, 디자인뿐만 아니라 다르게 처리해야 할 JS 로직이 많았다.

반응형으로, 한 컴포넌트 내에서 모두 처리하면 너무 복잡해질 것 같은데?

컴포넌트를 분리하지 않을 경우, 사이즈에 따른 로직 처리로 코드가 필요 이상으로 복잡해질 것 이고 이에 따라 구현과 버그 수정 모두 힘들어 질 것이라고 판단했다. 따라서 데스크탑 사이즈와 모바일 사이즈를 각각 다루는 컴포넌트를 따로 구현하고 태블릿 사이즈는 모바일 컴포넌트에서 반응형으로 대응하는 것으로 결정했다.

search 폴더 내에 desktop과 mobile 폴더를 만들어 각 사이즈를 대응할 컴포넌트들을 만들었고 search/index.tsx에서 불러와 현재 사이즈에 맞는 컴포넌트를 렌더링 해주었다. 최종적으로 서치 바를 사용하는 main page에서 search/index.tsx를 불러와 사용하였다.

반복되는 코드를 줄이자!

기본적으로 같은 기능을 하기 때문에 반복되는 코드가 발생할 수밖에 없다. 따라서 반복되는 로직은 모두 커스텀 훅으로 관리하였고 팝업과 팝업 내부에서 사용하는 컴포넌트는 모두 외부에서 불러오게끔 구현하였다.

설정된 검색 조건을 어떻게 전달할까?

검색 조건을 사용하여 데이터를 불러오는 곳은 main/index.tsx이다. 서치 바는 main/search/에 존재하는데, 사이즈에 따라 컴포넌트가 별도로 존재하므로 한 깊이 (/desktop or mobile) 더 들어가야 한다. 또한 서치 바는 3개의 하위 컴포넌트로 구성되어 있으며, 데이터를 설정하는 곳은 하위 컴포넌트에서 띄운 팝업 내부의 컴포넌트이다.

정리를 하자면, 사용자가 설정한 데이터를 총 4단계 위로 퍼 올려야 하는 상황이 발생한 것이다.

props drilling의 담당 일진은...

검색 조건을 전역 상태로 관리하면 간단히 해결할 수 있는 문제지만, 당시 우리 팀은 전역 상태를 도입할 필요가 없는 상황이었다. 때문에, 이 문제 하나만, 이 문제 하나를 해결하기 위해 전역 상태를 도입하는게 맞을까? 라는 생각에 쉽게 결정을 내리지 못했다.

결국(😂) 팀원들에게 현재 상황을 공유하고 의견을 물었는데... 자신있게(?) 하라는 조언을 얻고 recoil을 사용하여 해당 문제를 해결하게 되었다.

유저가 설정할 수 있는 3개의 검색 조건을 커스텀 훅으로 구현하여 desktop/mobile 컴포넌트에서 재사용 하였으며, 실제 데이터 검색에 사용하는 검색 조건 두 개의 변경을 감지하는 커스텀 훅을 추가로 구현하였다.

데스크탑 사이즈에서는 검색 버튼을 눌렀을 때 검색 조건을 반영하여 새로운 데이터를 불러오고 모바일 사이즈 일 때에는 변경된 검색 조건을 즉시 반영하여 새로운 데이터를 불러온다.

검색 조건을 사용하여 데이터를 불러오는 main page에서 검색 조건(payload)를 state로 관리하고 있으며, 해당 state를 react query의 key로 사용하고 있다. 즉, main page로부터 내려받은 setPayload를 호출하여 payload를 변경하기만 하면, 별도의 추가 로직 없이 새로운 데이터를 불러올 수 있다.

제어 컴포넌트에는 어떻게 debounce를 걸죠...?

모바일 사이즈일 경우 변경된 검색 조건을 즉시 반영하여 새로운 데이터를 불러온다. 따라서 text input에 별도의 처리를 하지 않을 경우, '문'을 검색하려고 할 때 'ㅁ', '무', '문' 이와 같이 총 3번의 request가 발생하게 된다. 이러한 불필요한 request를 막기 위해 debounce를 사용하려고 했는데...

값이... 안 변해요... 😇

const onChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  debouncedSet(e.target.value);
};

return { keyword, onChange };

const { keyword, onChange } = useKeywordState();

return <Input value={keyword} onChange={onChange} />;

처음에는 단순하게 접근하여, onChange 내부에서 debounce를 사용하였더니 입력한 대로 값이 변하지 않는 문제가 발생하였다. (onChange에서 set한 value로 input을 제어했기 때문 😢)

제어 방법을 바꿔볼까?

onChange가 아닌 onKeyUp에서 debounce를 사용하고 input의 상위 컴포넌트에서 useEffect로 input value의 변화를 감지하여 input element에 직접 값을 써주었다.

onKeyUp을 사용한 이유는, inputRef.current.value = x;와 같은 방식으로 input element에 직접 값을 쓸 때 onChange 이벤트가 호출 될 것이라고 생각했기 때문이다. 블로그를 작성하는 지금, 혹시나? 해서 테스트 해봤는데, 직접 값을 쓸 때에는 onChange 이벤트가 호출되지 않는 것을 확인하였다... 😭

이벤트가 어찌 됐든, 이론상으론 문제가 없는 제어 방법인 것 같은데...

input에 값을 빠르게 썼다, 지웠다를 반복하면 지우는 과정에서 이전에 입력됐던 값이 다시 input에 써지는 원인 모를 문제가 간헐적으로 발생하였다. (onChange로 해도 똑같음 😂) 정확한 원인은 파악하지 못했지만, 아마도 useEffect에서 실시간으로 값을 제어하는 것이 아니기 때문에 키 입력과 업데이트 사이의 알 수 없는 간극(?)이 생긴 것이라고 추측된다.

이러한 문제를 꼭 해결하고 싶었지만... 과제의 제출기한은 정해져있고, input을 꼭 제어해야 하는 상황이 아니었기 때문에, input을 제어하지 않는 방법으로 debounce를 사용했다.

강해져서 돌아와... 꼭 복수하겠습니다...

304...? 서버에 문제가 있는데...?

우리 팀은 데이터를 불러올 때 더 좋은 사용자 경험을 위해 스켈레톤 UI를 적용하였다. 하지만, 예약 내역 페이지로 이동했다가 다시 돌아올 때는 스켈레톤 UI가 나타나지 않고, 꽤 긴 로딩 시간 후에 데이터가 그려지는 문제를 확인하였다.

새로고침 했을 때와 페이지를 이동했을 때 모두 react query를 통해 request를 보내는 것을 확인하였다. 그래서 처음에는 요청을 보내고 응답을 받는 과정에서 문제가 발생한 것이라고 추측했다.

나름대로 이런저런 확인을 해보던 도중 json-server의 로그를 확인할 수 있었고, 페이지를 이동한 뒤 돌아올 때에는 응답(상태) 코드로 304를 받는다는 것을 알게 되었다.

여태껏 서버의 응답에서 데이터만 꺼내 썼지, 응답 코드는 확인해본 경험이 없었기 때문에, 처음에는 304가 에러 코드 중 하나인 줄 🤭 알았다.

그래서 304가 뭔데?

이전에 클라이언트가 받아 갔던 리소스가 수정되지 않아서, 새로운 데이터를 보내줄 필요 없이 클라이언트가 본인의 로컬 캐시를 재사용하면 될 때 서버는 304 응답 코드를 보내준다. 이때 응답 메시지의 body에는 아무런 내용이 없기 때문에 불필요한 네트워크 부하를 줄일 수 있다.

즉, 예약 내역 페이지에서 메인 페이지로 되돌아 올 때는, 이전에 불러왔던 데이터와 동일한 데이터를 요청한 것이기 때문에, 서버로부터 데이터를 새로 받는 것이 아니라 로컬 캐시로 리다이렉트하여 캐시된 데이터를 받아와 그렸던 것이다.

return (
  <>
    {hotels?.map((hotel) => (
      <Card key={hotel.id} {...hotel} />
    ))}
    {isLoading && <Skeleton />}
  </>
);

이 문제를 확인했을 당시에는 무한 스크롤을 구현하기 전, 위의 코드와 같은 상태였다. 페이지를 되돌아올 때는 캐시를 사용하기 때문에, isLoading이 false라서 스켈레톤 UI 없이 바로 호텔 목록이 표시되었던 것이고 1,000개 이상의 호텔 목록을 한 번에 그려야 했기 때문에 긴 로딩 시간이 발생했던 것이었다.

캐시 사용을 중지해 보면 어떻게 될까?

처음 예상한 시나리오는, 구글 개발자 도구에서 캐시 사용을 중지하면 페이지를 되돌아올 때도 사용할 캐시가 없기 때문에 새로운 데이터를 서버로부터 받아오는 것이었다.

캐시 사용 중지 이후 같은 동작으로 확인해보니, json-server의 로그에서 304 응답 코드가 사라지고 개발자 도구 네트워크 탭에서 확인할 수 있는 전송 크기 또한 10kb 이상으로 늘어난 것을 확인할 수 있었다. 하지만, 여전히 스켈레톤 UI는 나타나지 않았다.

스켈레톤 UI가 나타나지 않았다는 것은 react query의 isLoading이 true가 되지 않았다는 것이다. 즉, 새로운 데이터를 서버로부터 받아오지 않은 것이다. 또한 스켈레톤 UI 없이 1,000개 이상의 호텔 목록을 한 번에 그리기 때문에, 페이지를 되돌아 올 때 긴 로딩 시간이 여전히 발생하였다.

react query의 cache 넌 누구세요...? 😇

내가 작업을 맡은 기능도 아니였고 이후에 무한 스크롤을 적용할 경우, 한 페이지에 불러올 데이터가 제한되기 때문에 자연스레 사라질 문제였다. 하지만, 도대체 왜 이러나 싶어 이런저런 시도를 해보던 중 아래와 같은 코드를 추가하여 react query의 cache기능을 제한하는 설정을 추가해 보았는데...

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      cacheTime: 0,
    },
  },
});

의도한 대로 동작은 하는데...

react query의 cache기능을 제한하고 테스트해보니 처음에 의도했던 대로 동작하였다. 내가 고쳐보고 싶었던 것은, 페이지가 이동되기 전에 발생했던 로딩 시간을 페이지 이동에 막힘이 없도록 페이지 이동이 완료된 뒤로 옮기는 것이었다.

정리하면서 곰곰히 생각해 보니, 사실 이 문제는 304 응답 코드보다 react query의 cache 기능은 어떻게 동작하는가 그리고 isLoading은 언제 true가 되는가 이 두 의문이 더 중요한 문제였던 것 같다.

공부를 더 한 다음에 꼭 다시 정리해보자...

😇 마무리

과제의 품 자체가 큰 편은 아니었지만, 나 같은 어린이 개발자들은 꼭 한 번씩은 다뤄 바야 할 문제들로 구성되어 있어 굉장히 알찬 시간을 보냈던 것 같다.

지금 개인적으로 급한 일들 얼른~얼른 처리하고 처음부터, 혼자 다시 구현해볼 예정이다. 특히 달력 컴포넌트와 무한 스크롤 쪽은 구현 과정에서 정말 많이 배울 것 같아 굉장히 큰 기대가 된다. 😎

프리온보딩 코스에는 참가 기업에 지원해야 하는 제도가 있습니다. 왜 이런 제도가 있을까요?

가장 큰 이유는 참가자들의 동기부여를 위해서라고 생각합니다. 막연하게 커리큘럼을 따라가는 것보다 지원하려는 기업을 목표로 학습하는 것이 몰입에 더욱 도움 되기 때문입니다. 또한 참가자는 참가 기업에서 공개한 사용 중인 기술 스택을 확인하여, 자체적인 학습 방향을 설계할 수 있습니다.

다음으로는 프리온보딩 코스를 지속적으로 운영하기 위해서입니다. 프리온보딩 코스를 운영하기 위해 주관사와 참가 기업들은 많은 비용을 지불합니다. 따라서 기업들의 참가를 유도하기 위해서는 좋은 개발자를 채용할 수 있는 환경을 제공해야 합니다. 이러한 이유로 참가자들에게 참가 기업에 지원해야 하는 제도를 만들었다고 생각합니다.

지원하고 싶은 참가 기업은 어디인지 작성해주세요.

신입 개발자들에게 있어 좋은 기업은, 빠르게 성장할 수 있는 환경이 갖춰진 기업이라고 생각합니다. 따라서 코드 리뷰를 중요하게 생각하는 기업이나 사내 스터디를 장려하는 기업에 입사하고 싶습니다. 이러한 환경이 갖춰지기 위해서는 우선 기업 내에 개발자가 많아야 하기 때문에, 기업의 직원 수와 규모를 가장 우선되는 조건으로 선택했습니다.

또한 기업에서 운영 중인 서비스의 관심도와 원티드 측에서 공개한 정보가 상세한 기업들을 우선되는 조건으로 선택했습니다.

이러한 이유로 제가 지원하고 싶은 기업은 아래와 같습니다.

• 놀이의발견
• 지엔에이컴퍼니
• 트립비토즈
• 누비랩

사전 과제 https://github.com/corgi-world/wanted-pre-onboarding-fe