철스커의 멀티 저장소

리액트로 구현한 실시간 데이터를 웹 워커로 최적화 할 수 있을까 ?

철스커 — Wed, 3 Jun 2026 14:10:25 +0900

개요

주식 시세처럼 실시간 데이터는 어떻게 최적화 되고 있는 것일까요?
다양한 예시들을 찾아보면서, 웹 워커로 최적화할 수 있다는 사례가 있어서 한번 테스트해보고 싶었습니다.

웹 애플리케이션은 브라우저에서 실행이 되는데요.
브라우저의 메인 스레드를 렌더링 엔진과 JS 엔진이 같이 사용하고 있기에 렌더링 작업이나 연산 작업이 오래 걸리면 애플리케이션이 멈추거나 버벅거리는 현상이 발생하는 것입니다.

실시간 데이터를 API 방식이든, 네이티브 앱에서 받든 웹 애플리케이션 입장에서는 외부에서 받을 텐데요. 웹 애플리케이션은 데이터를 가공하는 연산 작업을 거쳐 브라우저의 렌더링 작업을 통해 화면에 데이터를 UI 형태로 보여줄 것입니다.

실시간으로 데이터를 최적화하는 테스트 UI

Mock 데이터 만들기

실시간 데이터이 오는 주기는 0.01초, 0.1초, 1초 등.. 다양할 텐데요.

여기서는 0.1초, 100ms에 데이터를 보내는 것으로 테스트 하였습니다.
아래와 같이 Mock 데이터를 생성하는 함수를 만들고, 이 함수는 콜백으로 데이터를 처리할 함수를 받습니다.

const startMockQuoteStream = (
  onData: (payload: WorkerInput["payload"]) => void,
) => {
  const intervalId = setInterval(() => {
    const basePrice = 75000;
    const payload = Array.from({ length: MOCK_QUOTE_COUNT }, (_, index) => ({
      price: basePrice + (index - 5) * 100,
      volume: Math.floor(Math.random() * 10000),
      changeRate: (Math.random() - 0.5) * 4,
    }));
    onData(payload);
  }, 100);

  return () => clearInterval(intervalId);
};

하나의 페이지에서 최적화전 컴포넌트와 최적화한 컴포넌트를 토글버튼으로 변경할 수 있도록 구현해봤고요.
데이터 갯수는 100ms당 500개, 1000개, 5000개, 10000개, 50000개로 실시간 목데이터를 생성하도록 하였습니다.
렌더링 횟수도 기록하였는데 10초, 30초, 1분 동안 렌더링이 원활하게 잘 이뤄지는지 횟수로 판단해보기로 하였습니다.

최적화전 컴포넌트 로직

최적화전 컴포넌트 로직은 아래와 같이 작동하는데요.
실시간 데이터가 오면 useState를 이용해서 가공된 데이터로 지역상태를 업데이트시킵니다.
렌더링될 때마다 렌더링 횟수를 Ref에 저장해서, 10초, 30초, 1분이 경과되면 각 렌더링 횟수를 Ref에 저장해서 화면에 보여줍니다.

// 최적화전 컴포넌트 (OriginalQuoteList)

const [quoteOutput, setQuoteOutput] = useState<WorkerOutput | null>(null);
const [clickCount, setClickCount] = useState(0);
const renderCount = useRef(0);
const startTimeRef = useRef(Date.now());
const resultRef = useRef<Record<number, number>>({
  10000: 0,
  30000: 0,
  60000: 0,
});
renderCount.current++;

useEffect(() => {
  const stop = startMockQuoteStream((payload) => {
    setQuoteOutput(formatQuotes(payload)); // 메인 스레드에서 포맷 + setState
  });

  return stop;
}, []);

const elapsed = Date.now() - startTimeRef.current;
const closedElapsed = Math.floor(elapsed / 10000) * 10000;

if (elapsed >= 10000 || elapsed >= 30000 || elapsed >= 60000) {
  if (!resultRef.current[closedElapsed]) {
    resultRef.current[closedElapsed] = renderCount.current;
  }
}

최적화된 컴포넌트

최적화된 컴포넌트에는 웹 워커와 rAF(requestAnimaitionFrame)을 적용해봤습니다.
앞의 로직과의 차이점은 "웹 워커를 사용해서 데이터 가공 로직을 별도의 스레드에서 처리한 점"과 "rAF를 사용해서 브라우저 페인팅 주기에 맞춰서 리액트 렌더링 과정이 처리" 하는 부분입니다.

// 최적화한 컴포넌트 (OptimizedQuoteList)
const workerRef = useRef<Worker | null>(null);
const pendingRef = useRef<WorkerOutput | null>(null); // 최신 워커 결과 버퍼
const rafRef = useRef<number>(0);
const [quoteOutput, setQuoteOutput] = useState<WorkerOutput | null>(null);
const [clickCount, setClickCount] = useState(0);
const renderCount = useRef(0);
const startTimeRef = useRef(Date.now());
const resultRef = useRef<Record<number, number>>({
  10000: 0,
  30000: 0,
  60000: 0,
});

renderCount.current++;

useEffect(() => {
  const worker = new Worker(
    new URL("./worker.ts", import.meta.url),
  );
  workerRef.current = worker;

  // setState 대신 ref에만 저장 → 렌더 미발생
  worker.onmessage = (event: MessageEvent<WorkerOutput>) => {
    pendingRef.current = event.data;
  };

  // rAF 루프: 새 데이터가 있을 때만 setState
  const tick = () => {
    if (pendingRef.current !== null) {
      setQuoteOutput(pendingRef.current);
      pendingRef.current = null;
    }

    rafRef.current = requestAnimationFrame(tick);
  };
  rafRef.current = requestAnimationFrame(tick);

  const stop = startMockQuoteStream((payload) => {
    worker.postMessage({ type: "PROCESS", payload } satisfies WorkerInput);
  });

  return () => {
    worker.terminate();
    cancelAnimationFrame(rafRef.current);
    stop();
  };
}, []);

테스트 결과를 아래의 표로 정리해봤습니다.
100ms 시간당 들어오는 데이터 갯수를 바꿔주면서, 렌더링횟수를 테스트하였습니다.

측정 시간	구분	500개 렌더링횟수	1000개 렌더링횟수	5000개 렌더링횟수	10000개 렌더링횟수	50000개 렌더링횟수
10초 경과	최적화 전	101	101	61	25	7
	최적화 후	101	101	88	45	10
30초 경과	최적화 전	301	301	179	70	16
	최적화 후	301	301	268	134	28
1분 경과	최적화 전	601	601	350	136	30
	최적화 후	601	601	536	265	54

1000개/100ms 까지는 렌더링 횟수가 시간에 비례해서 최적화 여부에 상관없이 선형적으로 증가하는 것을 확인할 수 있습니다.

5000개/100ms 에서는
최적화전: 30초, 60초 경과시 렌더링 횟수는 10초 경과에 비해 2.93배, 5.73배
최적화후: 30초, 60초 경과시 렌더링 횟수는 10초 경과에 비해 3.04배, 6.09배 증가하였습니다.

10000개/100ms 에서는
최적화전: 30초, 60초 경과시 렌더링 횟수는 10초 경과에 비해 2.8배, 5.44배
최적화후: 30초, 60초 경과시 렌더링 횟수는 10초 경과이 비해 2.97배, 5.88배 가 됩니다.

50000개/100ms 에서는
최적화전: 30초, 60초 경과시 렌더링 횟수는 10초 경과에 비해 2.28배, 4.28배
최적화후: 30초, 60초 경과시 렌더링 횟수는 10초 경과이 비해 2.8배, 5.4배 가 됩니다.

-> 실시간 데이터갯수가 많아질수록 브라우저에서 렌더링하는 데는 한계가 있으며, 최적화를 하면 성능개선 효과가 더 좋아짐을 알 수 있습니다.

5000개/100ms 렌더링 시간을 체크

1000개를 넘어가면 렌더링이 원활하게 되지 않으면서 버벅거림 현상이 발생한다고 볼 수도 있는데, 리액트에서 렌더링 프로세스 시간이 100ms를 오버한다는 의미가 됩니다.
실시간 데이터갯수가 5000개일 때, 리액트 Profiler 도구로 렌더링 시간을 확인해보면 100ms을 초과하는 걸 확인할 수 있습니다.

결론

몇 백개 ~ 1,000개 정도까지는 실시간으로 렌더링하는 것은 괜찮지만 그 이상의 갯수를 실시간 렌더링하기에는 어려움이 존재합니다.
웹 워커를 사용해서 별도의 스레드에서 일부 연산 작업을 위임시켜도 수천, 수만 개의 데이터를 실시간으로 처리하기에는 한계가 있다는 것을 알 수 있습니다.

웹 워커로 최적화하는 작업은 실패했습니다. ㅎㅎㅎ

웹 워커는 수천, 수만 개의 렌더링 최적화에 쓰이기보다는, 무거운 연산작업을 위임시키는 작업에 쓰이는 것이 적절해 보입니다.

뷰포트의 UI만 렌더링이 될 수 있도록 가상화 처리를 해주고, 실시간으로 받는 데이터의 갯수를 제한하는 것이 실시간 데이터 성능최적화에 더 좋은 방법이 될 것으로 보입니다.

Tanstack-Query로 무한스크롤링 이미지 구현하기

철스커 — Wed, 24 Dec 2025 23:09:50 +0900

오랜만에 무한스크롤링을 구현해보려고 합니다.

실무에서 무한스크롤링로 이미지를 계속해서 로딩하다보니, 성능적인 이슈가 발생했는데요.

비슷하게 기능을 구현하여 성능 이슈를 해결해보고 싶었습니다..!

그전에... 무한스크롤링을 구현해보기로 했습니다.

이미지를 가져오는 API가 필요했는데요.

Unsplash API를 사용해보기로 했습니다.

Unsplash API 사용하기

https://unsplash.com/documentation#pagination

Unspash는 개발자를 위한 문서를 제공해주고 있는데요.

Pagination도 구현되어 있어서 페이징으로 Unspash 이미지를 가져올 수 있습니다.

API 요청 횟수는 제한되어 있습니다.

demo 모드에서는 한 시간에 50회 요청으로 제한됩니다.

더 많은 요청을 원한다면, 유료로 플랜을 바꾸거나 Unsplash에 문의가 필요할 듯합니다.

API 응답 헤더를 보면 X-Ratelimit-Remaining 헤더가 보이는데요.

이 헤더값을 통해 잔여 API 요청 횟수를 알 수 있습니다.

Tanstack-Query의 useInfiniteQuery 로직

const { data, fetchNextPage, hasNextPage } = useInfiniteQuery<
    UnsplashPhoto[]
  >({
    queryKey: ["unsplash-photos"],
    initialPageParam: 1,
    queryFn: ({ pageParam = 1 }) =>
      fetch(`https://api.unsplash.com/photos?page=${pageParam}&per_page=5`, {
        headers: {
          Authorization: `Client-ID ${process.env.NEXT_PUBLIC_UNSPLASH_ACCESS_KEY}`,
        },
      }).then((res) => res.json()),
    getNextPageParam: (lastPage, allPages) => {
      if (lastPage.length === 0) return undefined;
      return allPages.length + 1;
    },
    staleTime: 1000 * 60 * 24,
    refetchOnWindowFocus: false,
  });

useInfiniteQuery를 이용해서 위와 같이 무한스크롤링 로직을 구현해볼 수 있습니다.

queryFn에 fetch를 이용해서 API 호출 함수를 구현할 수 있습니다.

Unsplash API는 한 시간에 API 요청횟수 제한이 있어서, staleTime을 한 시간으로 잡았습니다.

Unspash API는 Access 키를 넣어야 동작하기 때문에

계정을 생성하신 후에, Access 키를 확인하시고 API 요청 헤더에 Authorization에 올바른 값을 넣어주시면 됩니다.

다음 페이지를 언제 호출하면 좋을까요?

스크롤 이벤트를 이용해서 스크롤이 하단에 위치했을 때를 계산해서 구현하는 방법도 있을 거에요.

그것보다 더 쉬운 방법은 Intersection Observer API를 사용하면 됩니다.

관찰하는 대상이 화면에 노출되었을 때, 특정로직을 수행할 수 있습니다.

위의 그림을 직접 그려봤는데요.

저는 이미지들을 담을 컨테이너의 맨 밑에 요소를 하나 추가해서

이 요소가 노출될 때 다음 페이지의 데이터를 가져오도록 처리했습니다.

/**
 * 페이지 컴포넌트 내부
*/

// 이미지 컨테이너 맨밑의 요소를 저장 (관찰대상)
const scrollEndRef = useRef<HTMLDivElement>(null);

...


// Intersection Observer로 다음 페이지를 호출하는 로직 구현
useEffect(() => {
    if (!scrollEndRef.current) return;
    if (!hasNextPage) return;

    const observer = new IntersectionObserver(
      (entries) => {
        if (entries[0].isIntersecting && hasNextPage) {
          fetchNextPage();
        }
      },
      {
        root: scrollEndRef.current.parentElement,
        rootMargin: "0px 0px 100px 0px",
      }
    );

    observer.observe(scrollEndRef.current);

    return () => {
      observer.disconnect();
    };
  }, [scrollEndRef.current, hasNextPage]);

여기서 끝이 아니다. 이미지 지연 대응하기

이미지를 가져올 API를 붙였고, 다음 페이지의 이미지도 잘 들고 옵니다.

그런데, 여기서 끝이 아닙니다.

이미지가 늦게 렌더링될 수도 있습니다.

여러가지 원인들이 있겠지만 아래와 같은 이유들이 있을 것입니다.

- 느린 네트워크 환경

- 성능이 낮은 기기

- 이미지 파일크기가 큰 경우

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

개발자 도구를 이용해서, CPU 성능을 x4 감속했고, 네트워크 속도도 빠른 4G로 낮춰봤습니다.

위의 동영상을 보시면, 브라우저는 이미지가 완전히 다운로드되기 전까지는...

이미지를 렌더링하지 않기에 유저는 빈 영역을 볼 수 없다는 사실을 확인하실 수 있습니다.

이는 유저의 사용자 경험을 떨어뜨리고, 유저를 웹 사이트에서 이탈시킬 수 있습니다.

개선방법은 대체이미지를 미리 넣어주는 것입니다.

(다른 명칭으로는 스켈레톤 이미지 또는 Placeholder 이미지)

export default function LazyPhoto({ photo }: { photo: UnsplashPhoto }) {
  const [isLoaded, setIsLoaded] = useState(false);

  return (
    <div className="py-0.5 aspect-square relative">
      // 이미지 로딩 전
      {!isLoaded && (
        <div className="absolute w-full h-full bg-gray-300 rounded-md blur-xs" />
      )}
      
      <img
        loading="lazy"
        src={photo?.urls.full}
        alt={photo?.description || "Unsplash Photo"}
        className="absolute object-cover rounded-md w-full h-full"
        onLoad={() => {
          setIsLoaded(true);
        }}
      />
    </div>
  );
}

리액트를 사용한다면, useState를 이용해서 쉽게 구현할 수 있습니다.

이미지 컨테이너를 하나 만들어서, 공간을 잡아둡니다.

이미지 로딩되기 전에 대체이미지를 이용해서 이미지 컨테이너 영역에 표시합니다.

이미지 로딩이 마치면, useState를 이용해서 DOM에서 대체이미지를 제거합니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

대체이미지를 넣어주니 좀 더 낫습니다.

유저에게 이미지가 로딩되고 있다는 것을 직관적으로 알려주기 때문입니다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

여기까지 무한스크롤링을 이용한 이미지 구현을 정리해봤습니다.

카카오맵 API: 특정 마커들이 다 보이게 지도 범위(Bounds) 조절하기

철스커 — Sun, 21 Dec 2025 22:30:05 +0900

요구사항 ✏️

실무에서 요구사항이 다음과 같았습니다.

"지도에서 특정한 매장만 보이도록 지도를 줌인/줌아웃 할 수 없나요?"

일단... 고민거리가 많이 생겼습니다.

유저가 지도의 줌인을 많이 했을 수도 있고,

반대로 지도의 줌아웃을 많이 했을 수도 있습니다.

유저의 지도레벨은 유저마다 다르다 ‍

카카오맵에서 지도를 확대/축소할 수 정도를 지도레벨이라고 표현하고 있는데요.

- 지도레벨이 13이라면, 특정한 매장만 보이게 지도레벨을 얼만큼 줌인해야 할지..?

- 지도레벨이 5정도라면, 지도레벨을 얼만큼 줌아웃해야 할지...?

판단하기 어렵습니다.

유저가 보고 있는 지도의 레벨이 얼마인지도 모르고,

얼만큼 줌인해야할지, 얼만큼 줌아웃해야할지 모릅니다.

케이스가 다양해서 복잡하다

또, 매장의 갯수나 매장의 위치가 다른 경우도 있습니다.

1. 매장의 갯수가 한 개라면?

-> 해당 매장만 보이도록 지도를 이동시키고, 지도를 최대로 줌인해주면 됩니다.

2. 매장 갯수가 2개 이고, 한 곳은 서울 한 곳은 제주도에 있다면?

-> 매장 2곳의 중간지점으로 이동해서, 지도를 최대로 줌아웃처리해야 합니다.

3. 매장 갯수가 3개 이고, 다 서울에 있다면?

-> 매장 3곳이 붙어있다면 줌인해야겠지만, 지역이 다 제각각이라면? ‍

-> 어떤 로직을 짜야할지 모르겠군요...

그런데, 카카오맵 API에서 해당 기능을 제공해줍니다. 내부적으로 구현한 로직이 있나 봅니다.

매장 좌표들을 카카오맵에 전달해주면, 줌인/줌아웃과 지도위치를 알아서 변경해줍니다.

카카오맵 API - 지도범위 재설정하기 예제

아래 링크를 통해 들어가시면, 자바스크립트로 지도범위를 재설정할 수 있는 예제를 확인하실 수 있습니다.

LatLngBounds 객체를 사용해서 지도범위에 마커 좌표를 넣어주고, 카카오맵의 지도범위를 변경해줍니다.

링크

https://apis.map.kakao.com/web/sample/setBounds/

예제

var mapContainer = document.getElementById('map'), // 지도를 표시할 div 
    mapOption = { 
        center: new kakao.maps.LatLng(33.450701, 126.570667), // 지도의 중심좌표
        level: 3 // 지도의 확대 레벨
	};

var map = new kakao.maps.Map(mapContainer, mapOption); // 지도를 생성합니다
 
// 버튼을 클릭하면 아래 배열의 좌표들이 모두 보이게 지도 범위를 재설정합니다 
var points = [
    new kakao.maps.LatLng(33.452278, 126.567803),
    new kakao.maps.LatLng(33.452671, 126.574792),
    new kakao.maps.LatLng(33.451744, 126.572441)
];

// 지도를 재설정할 범위정보를 가지고 있을 LatLngBounds 객체를 생성합니다
var bounds = new kakao.maps.LatLngBounds();    

var i, marker;
for (i = 0; i < points.length; i++) {
    // 배열의 좌표들이 잘 보이게 마커를 지도에 추가합니다
    marker =     new kakao.maps.Marker({ position : points[i] });
    marker.setMap(map);
    
    // LatLngBounds 객체에 좌표를 추가합니다
    bounds.extend(points[i]);
}

function setBounds() {
    // LatLngBounds 객체에 추가된 좌표들을 기준으로 지도의 범위를 재설정합니다
    // 이때 지도의 중심좌표와 레벨이 변경될 수 있습니다
    map.setBounds(bounds);
}

Next.js + react-kakao-maps-sdk 예제

Next.js 환경에서는 react-kakao-maps-sdk 라이브러리를 이용하면 아래와 같이 구현해볼 수 있습니다.

"use client";

import Script from "next/script";
import { Map, MapMarker, useMap } from "react-kakao-maps-sdk";

const latLngs = {
  mapCenter: { lat: 33.55635, lng: 126.795841 },
  marker1: { lat: 33.55635, lng: 126.795841 },
  marker2: { lat: 33.451475, lng: 126.570667 },
  marker3: { lat: 33.489011, lng: 126.498302 },
};

const ChangeButton = () => {
  const map = useMap();
  const handleSetBounds = () => {
    const bounds = new kakao.maps.LatLngBounds();

    bounds.extend(
      new kakao.maps.LatLng(latLngs.marker1.lat, latLngs.marker1.lng)
    );
    bounds.extend(
      new kakao.maps.LatLng(latLngs.marker2.lat, latLngs.marker2.lng)
    );
    bounds.extend(
      new kakao.maps.LatLng(latLngs.marker3.lat, latLngs.marker3.lng)
    );

    map.setBounds(bounds);
  };

  return (
    <div style={{ marginTop: "10px" }}>
      <button
        style={{
          padding: "10px 20px",
          backgroundColor: "#FFD700", // 노란색
          color: "#000", // 검정색
          borderRadius: "5px",
          cursor: "pointer",
        }}
        onClick={handleSetBounds}
      >
        지도영역 변경하기
      </button>
    </div>
  );
};

export default function KakaoMapBoundsPage() {
  return (
    <main>
      <section
        id="map"
        style={{ border: "1px solid #ccc", width: "500px", height: "500px" }}
      >
        <Map
          center={latLngs.mapCenter}
          level={12}
          style={{ width: "100%", height: "100%" }}
        >
          <MapMarker position={latLngs.marker1}>
            <div>마커1</div>
          </MapMarker>
          <MapMarker position={latLngs.marker2}>
            <div>마커2</div>
          </MapMarker>
          <MapMarker position={latLngs.marker3}>
            <div>마커3</div>
          </MapMarker>

          <ChangeButton />
        </Map>
      </section>

      <Script
        src={`//dapi.kakao.com/v2/maps/sdk.js?appkey=${process.env.NEXT_PUBLIC_KAKAO_MAP_API_KEY}&autoload=false`}
        strategy="beforeInteractive"
      />
    </main>
  );
}

테스트 결과

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

[React] react-hook-form의 useWatch를 이용해 실시간으로 폼 데이터 확인하기

철스커 — Wed, 25 Dec 2024 23:17:01 +0900

이슈 발생

회사에서 업무를 보면서 폼 데이터를 구현할 일이 많았는데요.

react-hook-form을 이용하면 폼 데이터를 쉽게 관리할 수 있었습니다.

그런데, 폼 데이터 필드 갯수가 10개를 넘어 30개 정도로 굉장히 많은 경우가 있습니다.

필드별로 onChange 이벤트에 로그를 찍어서 필드값을 확인할 수도 있고,

폼 전송 시, onSubmit 이벤트를 이용해서 모든 필드값을 로그로 찍을 수 있습니다.

하지만, 필드값을 반복적으로 수정하는 경우

Submit 버튼을 누르는 것도 귀찮기도 하고, 번거롭습니다 ;;;

react-hook-form 코드 예시

import { useForm } from 'react-hook-form';

const INPUTS = {
  input1: 'input1',
  input2: 'input2',
  input3: 'input3',
  input4: 'input4',
  input5: 'input5',
};

function TestPage() {
  const { register, handleSubmit } = useForm();

  const onSubmit = (values) => {
    console.table(values);
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register(INPUTS.input1)} />
      <input {...register(INPUTS.input2)} />
      <input {...register(INPUTS.input3)} />
      <input {...register(INPUTS.input4)} />
      <input {...register(INPUTS.input5)} />
      <button type="submit">SUMBIT</button>
    </form>
  );
}

export default TestPage;

폼 데이터 값 확인이 불편함

디버깅이 번거롭습니다...

useWatch API 사용하기

react-hook-form 공식문서에서 소개된 여러 기능을 사용해보다가 useWatch API를 알게 되었습니다.
useWatch API는 특정 필드나 폼 전체의 값을 구독하고 실시간으로 값을 감지할 수 있습니다.
useWatch API를 통해 필드가 구독된 컴포넌트는 리렌더링됩니다.

const { register, control, handleSubmit } = useForm();

// 특정 필드만 감지하는 경우
const input1 = useWatch({
    control,
    name: INPUTS.input2,
  });

// 모든 필드를 감지하는 경우
const all = useWatch({
  control,
});

/**
 * 구독한 필드값을 로그로 찍음
**/
console.table(input1);
console.table(all);

useWatch API 적용 후, 폼 데이터 확인하기

useWatch API를 적용한 후, 모든 필드값을 구독하게 했습니다.
이제 필드값에 값만 넣어도, 모든 필드값을 로그로 확인할 수 있습니다.
실시간으로 폼 데이터를 간편하게 확인할 수 있습니다....!

useWatch API 적용 후, 디버깅

useMutation의 mutationFn 함수 파라미터가 없을 때, mutation 콜백 함수의 첫 번째 파라미터 void 대응하기

철스커 — Fri, 13 Dec 2024 00:24:46 +0900

이슈 내용

useMutation함수를 호출해서 정의된 mutation함수를 사용할 수 있는데요.
mutation함수의 콜백에 두번째 파라미터에 옵션에 onSuccess, onError 등을 이용해서
비동기함수의 성공, 실패를 처리할 수 있습니다.

useMutation함수를 정의할 때, mutationFn함수를 전달할 수 있는데요.
그런데, mutationFn함수의 파라미터가 없을 수도 있습니다.

예제 코드

import { useMutation } from '@tanstack/react-query'

// mutationFn의 파라미터 없음!
const m = useMutation({
    mutationFn: () => Promise.resolve(5)
})

// 첫번째 파라미터에 어떤 값을 전달해야?
m.mutate(null, {
    onSuccess() {
        console.log('onSuccess');
    }, 
    onError() {
        console.log('onError');
    }
});

타입에러 스크린샷

mutationFn의 파라미터가 없기 때문에,

mutate 함수에 두번째 파라미터에 옵션을 사용할 때, 첫번째 파라미터는 void 형태로 표시됩니다.

대응방법

타입스크립트에서의 void 타입은 "아무 값도 없다"는 것을 의미하며, undefined와 호환됩니다.
따라서, mutationFn함수의 첫번째 파라미터에 undefined를 전달하면 됩니다.

import { useMutation } from '@tanstack/react-query'


const m = useMutation({
    mutationFn: () => Promise.resolve(5)
})


m.mutate(undefined, {
    onSuccess() {
        console.log('onSuccess');
    }, 
    onError() {
        console.log('onError');
    }
});

참고

TypeScript 플레이그라운드 - 코드예제

TanStack/query - useMutation where no variables are required 이슈

카카오톡 공유하기 (Javascript) 를 이용해 원하는 정보 전달하기

철스커 — Wed, 14 Aug 2024 16:31:42 +0900

서론

사이드 프로젝트에서 카카오톡 공유하기 기능을 구현해야 하는 경우가 생겼는데, 경험을 기록해둡니다.
어떤 UI (버튼, 이미지) 를 클릭하면, 카카오톡 API를 통해 카카오톡 앱이 열리고 친구에게 메시지를 공유할 수 있는데요.

API를 호출할 때, 특정 정보를 전달하고 이 정보를 메시지 링크에 붙여줍니다.

메시지 링크가 열리면 저희 서비스로 이동해서, 서비스에서 이 정보로 특정 액션을 할 수 있습니다.

카카오톡 공유하기 플로우

참조) https://developers.kakao.com/docs/latest/ko/message/common

카카오톡 공유하기 API

카카오에 대한 타입정의가 없기 때문에, kakao.d.ts 파일을 만들어 다음과 같은 타입정의를 하였습니다.
kakao.d.ts는 tsconfig.json에서 넣어줘서 컴파일러가 타입을 정의할 수 있도록 했습니다.

// kakao.d.ts

/**
 * 카카오 API 타입정의
 */
interface Kakao {
  init: (clientSecret: string) => void;
  Share: {
    /**
     * 사용자 정의 템플릿으로 메시지 보내기
     *
     * API Schema
     * https://developers.kakao.com/sdk/reference/js/release/Kakao.Share.html#.sendCustom
     */
    sendCustom: (params: {
      templateId: number;
      templateArgs?: Record<string, string>;
      installTalk?: boolean;
      serverCallbackArgs?: Record<string, string> | string;
    }) => void;
  };
}

declare global {
  interface Window {
    Kakao: Kakao;
  }
}

export {};

// tsconfig.json

...

"include": [
    "./types/*.d.ts", // d.ts 파일들을 컴파일러가 인식할 수 있게 함
    "next-env.d.ts",
    "**/*.ts",
    "**/*.tsx",
    ".next/types/**/*.ts",
  ],

...

카카오에서 다양한 공유하기 API를 제공하는데요.
저는 커스텀한 형태의 메시지를 전달하는 것이 필요해서 Kakao.Share.sendCustom API를 사용했습니다.

이 함수는 함수 호출 시, 데이터를 인자(args)로 전달할 수 있습니다.

templateArgs에 객체를 전달할 수 있는데 이 객체에 key-value 쌍들을 전달할 수 있어요.

// hooks.ts

export const handleShareToKakao = () => {
    ...

     Kakao.Share.sendCustom({
        templateId,
        templateArgs: {
          key: value,
          key2: value2
        },
      });
    };
}

카카오톡 개발자 페이지에서 메시지 템플릿 수정하기

공통 설정

메시지 템플릿을 하나 만드시고, 수정하는 화면에 들어가시면 되는데요.
상단에 공통 설정 영역이 있습니다.

사용자 인자를 클릭하시고, 인풋창에 입력을 할 수 있는데요.

위의 Kakao.Share.sendCustom 에서 전달한 templateArgs의 key를 입력하시면 됩니다.
templateArgs에 { name: "이름", age: "나이" }를 넘기셨으면,
인풋창에 ${name} ${age} 이런 식으로 넣으실 수 있는데요.

링크를 삽입할 때, 이 정보들을 넣어줄 수 있습니다.
pathname에 정보들을 넣어줄 수도 있고, Query String 형태로도 전달할 수 있겠네요.

사용자 인자

인풋창에 입력하시고 저장을 하셨다면, 하단에 사용자 인자 영역에

${변수명1}
${변수명2}

와 같은 텍스트들이 입력됩니다.

컴포넌트 링크 관리

컴포넌트 링크 관리 영역으로 가시면, 공통 링크를 수정하실 수 있습니다.
공통 링크는 메시지의 UI에 공통적으로 링크를 달 수 있게 하는 건데요.
UI마다 하나하나 링크를 달지 않고, 일괄적인 링크를 달 수 있게 해줍니다. (편리!)

공통 링크에서 수정을 누르시면 창이 하나 나옵니다.
DOMAIN은 지정해둔 도메인을 설정할 수 있는 영역이고요.
PATH에 앞에서 설정한 사용자 인자를 넣어 줄 수 있습니다.

Pathname이나 Query String을 이용해 사용자 인자를 전달할 수 있는 것입니다.
PATH에 ?code=${code} 와 같이 전달하면, code 키를 가진 사용자 인자 값을 전달하므로 서비스에서 이용할 수 있습니다.
카카오톡 공유로 메시지를 전달받은 유저가 링크를 클릭하면, 서비스가 열리고 code 값을 가지고 서비스에서 특정 동작을 할 수 있는 것입니다.

Tailwind-merge 사용 중에 클래스 충돌(class conflict)은 왜 발생할까?

철스커 — Wed, 7 Aug 2024 19:12:53 +0900

이슈발생

사이드 프로젝트 팀에서 사용하는 디자인 시스템을 Tailwind config에 적용해주었습니다.
색상도 커스텀한 이름으로 적용해두었고요.

Turborepo + Next.js + Tailwind 스타터킷 프로젝트를 사용했기에, Tailwind 유틸함수를 자연스럽게 사용했는데요.
Tailwind에서는 텍스트 사이즈 조정을 할 때도, 텍스트 색상을 조정할 때도 유틸리티 클래스 이름이 text-로 시작합니다.

Tailwind 유틸함수 cn (내부에 tailwind-merge 및 clsx 사용)을 이용해 아래와 같이 스타일을 입힐 수 있는데요.
그러면, text-로 시작한 클래스를 여러개 적용해두면 마지막 클래스만 남게 되는 현상이 발생했습니다.


// 커스텀-폰트크기, 커스텀-색상
className={cn('text-button-md text-gray-500')}

// 커스텀-색상, 폰트크기
className={cn('text-gray-500 text-20')}

// 커스텀-색상, 커스텀-폰트크기
className={cn('text-gray-500 text-button-md')}

Tailwind-merge는 무슨 역할을 하는 것일까?

tailwind-merge에서 제공하는 twMerge 함수에 의해 이러한 현상이 발생하는 것인데요.
그럼, twMerge는 무슨 역할을 하는 것일까요?

twMerge를 왜 사용해야 하는 지 알아야할 것 같습니다.
유틸리티 클래스(bootstrap, tailwind)를 사용하면, 만들어진 클래스를 가져다 쓰면 되니 편리한데요.

유틸리티 클래스의 단점이 존재합니다.

tailwind는 빌드 후에 CSS 파일을 생성하는 데, 여기에 우리가 사용할 유틸리티 클래스들이 정의되어 있습니다.

패딩에 대한 클래스 - p, px, pl 등도 선언되어 있습니다.

CSS에서 클래스 선택자로 동일한 CSS 속성을 사용할 경우, 나중에 선언된 클래스 선택자가 적용되는 데요. (cascading)

유틸리티 클래스에서도 마찬가지입니다.

나중에 적용한 클래스(오른쪽에 적용한 클래스)가 앞의 클래스의 CSS 속성을 덮어쓸 것이라 생각했으나 의도대로 동작하지 않습니다.


// 패딩가로가 8로 바뀔 것으로 기대했으나 4로 유지됨
className="px-4 p-8"

// 패딩왼쪽이 8로 바뀔 것으로 기대했으나 4로 유지됨
className="pl-4 px-8"

개발자 도구를 열어서, 유틸리티 클래스 파일을 살펴보면 그 원인을 알게 됩니다!
px 클래스 선택자들은 p 클래스 선택자들보다 뒤에,
pl 클래스 선택자들은 px 클래스 선택자들보다 뒤에 위치해 있기 때문입니다.

클래스 선택자 순서가 예상한 것과 다르게 위치해 있는데요.
twMerge는 클래스 선택자들의 CSS 속성이 겹칠 경우 마지막 클래스 선택자만 남겨두는 역할을 수행해줍니다.


// p-8만 남음
className={twMerge("px-4 p-8")} 

// px-8만 남은
className="px-8"

twMerge가 클래스를 삭제하는 원리는 무엇일까?

tailwind-merge 라이브러리에서는 Class group(클래스 그룹) 과 Conflicting Class group (충돌하는 클래스 그룹) 이라는 개념이 등장합니다.

Class group

Class group은 같은 CSS 속성을 사용하는 유틸리티 클래스들을 정의한 그룹 (문자열 배열) 입니다.

const positionClassGroup = ['static', 'fixed', 'absolute' ... ]

위처럼 position CSS 속성을 변경하는 클래스들을 묶어놓는 것인데요.
이런 Class group들은 tailwind-merge config에 기본적으로 적용이 되어 있습니다. (default config)

twMerge('static sticky relative') // 'relative'

어떤 유틸리티 클래스에는 접두어가 붙는 경우가 있습니다. ex) overflow-*
그런 경우에는 아래와 같이 Class group을 적용해줄 수 있습니다.

// 접두어(overflow)가 객체의 키가 됨.
const overflowClassGroup = [{ overflow: ['auto', 'hidden', 'visible', ...] }];

twMerge('overflow-auto overflow-hidden overflow-visible'); // 'overflow-visible'

일일히 나열하기 어렵다면, validator 함수를 이용해서 조건에 맞는 클래스들을 Class group에 넣을 수 있습니다.

const isUnder201 = (value: string) => Number(value) <= 200;
const fontSizeGroup = [{ text: [isUnder201] }];

Conflicting Class group (충돌하는 클래스 그룹)

Class group를 이용해 어떤 클래스를 제거해야할 지 판단할 수 있으나, 좀 더 복잡한 케이스가 존재합니다.


'pr-4 px-3' // pr-4를 없애도 문제없음
'px-3 pr-4' // px-3을 없애면 패딩왼쪽 3도 제거됨

위의 경우처럼 같은 px-3, pr-4를 사용하더라도 순서에 따라 스타일을 변경하는 의도가 달라질 수 있습니다.
패딩 CSS 속성을 변경한다고 앞의 클래스 선택자를 제거하면 문제가 됩니다.

이런 경우에 대처하기 위해 Conflicting Class group 이라는 것이 존재합니다.

const conflictingClassGroups = {
    px: ['pr', 'pl'],
      ...
}

위의 경우처럼 tailwind-merge config에 적용할 수 있습니다.
객체 키에는 Class group ID가 들어갑니다. (쉽게 생각해서 유틸리티 클래스 접두어)

충돌이 될만한 클래스를 넣어주고, 충돌되는 클래스들이 앞에 존재할 경우 제거해줍니다.


twMerge('pr-4 px-3'); // 'px-3'
twMerge('px-3 pr-4'); // 'px-3 pr-4'

그럼, 위의 경우처럼 충돌되지 않는 판단하는 경우 앞의 클래스들을 제거하지 않습니다.

자, 이제 문제를 해결해보기

어느 정도, 원리를 이해했으니 문제를 해결해봅시다.
위와 같은 이유로 tailwind-merge에서는 config에 추가적인 정보를 제공하지 않으면 충돌된다고 판단되는 클래스 들은 제거해버립니다.

text-button-md text-gray-500 text-20, 이 클래스들은 text-로 시작하고 커스텀 클래스도 있는데요.
tailwind-merge에서는 아직 모르니까 먼저 선언된 클래스들을 제거하는 것입니다.

tailwind-merge에서는 twMerge 대신 extendTailwindMerge를 사용할 수 있는데요.
extendTailwindMerge에서 앞에서 설명한 classGroup를 선언할 수 있고, 커스텀한 클래스들을 extend할 수 있습니다.

import { extendTailwindMerge } from 'tailwind-merge';

// twMerge 대신 extendTailwindMerge 사용
const customTwMerge = extendTailwindMerge({
  extend: {
    theme: {
      colors: Object.entries(sharedConfig.theme?.colors || {}).map(([k, v]: [string, Record<string, string>]) => ({
        [k]: Object.keys(v),
      })),
    },
    classGroups: {
      'font-size': [
        ...Object.keys(sharedConfig.theme?.fontSize || {}).map((key) => `text-${key}`),
        { text: [(value: string) => Number(value) <= 200] },
      ],
    },
  },
});

// cn 유틸 함수를 수정
export const cn = (...inputs: ClassValue[]) => {
  return customTwMerge(clsx(inputs));
  // return twMerge(clsx(inputs));
};

1) extend.theme.colors에 형식에 맞게 커스텀 색상 클래스를 넣어주었습니다.
2) extend.classGroups\['font-size'\]에 커스텀 폰트 클래스를 넣어주었습니다.

tailwind-merge에 위와 같은 정보를 알려주면,
text-[커스텀 컬러 클래스]와 text-[커스텀 폰트 클래스]는 다른 ClassGroup 인 것을 알게 되어 클래스 충돌을 막을 수 있어서 의도한대로 잘 동작하게 됩니다.

참고

https://github.com/dcastil/tailwind-merge/issues/368

https://stackoverflow.com/questions/76355485/tailwind-merge-not-able-to-combine-color-and-typography-classes/76376770#76376770

https://github.com/dcastil/tailwind-merge/blob/v2.3.0/docs/configuration.md

[알고리즘] 알고리즘 패턴 정리 1 (연결 리스트 편, LinkedList)

철스커 — Fri, 24 May 2024 17:46:19 +0900

연결 리스트 편 (Linked List)

1. 러너 기법을 이용하는 패턴

2개의 러너 slow와 fast, 2개의 포인터를 이용하여 연결 리스트를 순회하는 기법
빠른 러너(fast)는 느린 러너보다 두 배로 이동합니다.
fast가 끝에 도달하면, slow는 중간 노드에 위치하는데요.

이런 특성을 이용해서, 중간 위치를 찾아 낼 수 있습니다.
예시)
1) 값을 비교하기
2) 뒤집기
3) 팰린드롬 찾기

2. node.next != null && node.next.next !== null 인 조건을 체크하기

node 다음 노드를 a,
node 다음+다음 노드를 b라고 할 때,

node와 a, b 를 이용해서,
현재 노드와 다음 노드, 다다음 노드를 Swap 하는 등의 작업을 할 수 있습니다.

let node = new ListNode(0);
const root = node;

while (node.next !== null && node.next.next !== null) {
	const a = node.next;
    const b = node.next.next;
    
    a.next = b.next;
    node.next = b;
    node.next.next = a;

	node = node.next.next;
}

...

3. prev, curr, next 를 이용하기

while 문 안에서, curr = curr.next로 노드를 순회할 때,
prev, curr, next를 이용해, 이전 노드와 현재 노드, 다음 노드를 기억할 수 있습니다.

이를 이용해, 노드의 값을 swap하거나 뒤집을 수 있다.

type NodeType = ListNode | null;

let prev: NodeType = null;
let curr: NodeType = head;

// prev에 이전 노드를 계속 붙이면서, 역순으로 연결 리스트를 뒤집음
while (curr) {
	const next = curr.next;
    
	curr.next = prev;
    prev = curr;
    curr = next;
}

...

같이 알아보면 좋은 자료구조 : 스택, 데크(deque)

[CS] 부동 소수점 개념 정리해보기

철스커 — Mon, 13 May 2024 23:09:45 +0900

부동 소수점의 의미

영어로 floating point라고 하며, 소수점이 떠다닌다는 의미를 가지고 있습니다.

컴퓨터에서 실수를 표현하는 방법으로 소수점의 위치를 고정하지 않아, 사용하는 비트 수 대비 넓은 범위의 숫자를 표현한다는 장점이 있습니다.

IEEE 754에서 부동 소수점의 개념을 표준화하였습니다.

고정 소수점과의 차이

고정 소수점에서는 정수와 소수 부분의 영역을 나눠서 수를 표현하지만, 부동 소수점에서는 유동적으로 소수점을 이동시킬 수 있습니다.

32비트만큼을 사용해서 실수를 표현한다고 가정할 때, 고정 소수점을 부호 1비트, 정수 부분을 8비트, 소수 부분을 23비트로 표현한다고 합시다. (1+8+23 = 32)

그런데, 정수 부분은 8비트만큼만 사용할 수 있어서 -2^8 ~ 2^8 (-256 ~ 256) 만큼의 정수만 표현할 수가 있습니다.

소수 부분까지 합친다면 -256.xxx ~ 256.xxx 범위의 수를 표현할 수 있는 것인데요.

숫자를 표현하는 범위가 작다는 단점이 있습니다.

부동 소수점 표현

부동 소수점도 32비트로 표현해볼 수 있는데요.

부동 소수점은 1)가수 (fraction), 2)지수 (exponent), 3)밑수 (base) 로 수를 표현할 수 있습니다.

십진수 13.075를 부동 소수점으로 표현하면, 1.3075 * 10^1 또는 0.13075 * 10^2 형태로 표현할 수 있는 것이죠.

13.075를 이진수로 변경하면, 1101.11 가 되고 11.0111 * 2^2 또는 0.110111 * 2^4 처럼 부동 소수점으로 표현할 수 있습니다.

고정 소수점 (32비트 기준) 에서 정수 부분을 8비트로 잡았을 때, 숫자의 범위가 굉장히 제한적이었는데요.

부동 소수점 (32비트 기준)에서는 지수 부분이 8비트라면, 지수의 값의 범위가 0~256 되기 때문에 큰 숫자를 표현할 수 있습니다.

물론 고정 소수점에서 정수 부분의 비트 공간을 늘리고 소수 부분의 비트 공간을 줄여서, 숫자의 크기를 늘릴 수 있습니다.

그럼에도 불구하고, 표현할 수 있는 소수 범위가 좁아지고 부동 소수점에 비해 표현할 수 있는 숫자의 크기에 한계가 있습니다.

부동 소수점의 정규화

부동 소수점에서의 정규화의 의미는,,

가수의 첫 번째 자리가 밑수보다 작은 한 자리 자연수가 되도록 소수점 위치를 이동시키는 것입니다.

2진수에서 부동 소수점을 정규화하면, 가수의 첫 번째 자리 (정수 부분) 는 항상 1이 되는데요.

그렇기에, 이 1을 생략해주고 1비트 만큼의 공간이 생기므로 소수 부분의 숫자를 한 자리 더 넣어줄 수 있습니다.

이진수 1101.11을 정규화된 부동 소수점으로 표현하면 1.10111 * 2^3 이 됩니다.

가수 부분에 첫 번째 1을 생략해서 아래와 같이 표현할 수 있습니다.

지수의 값은 3이라서 이진수 11을 지수 부분에 넣어줬는데요.

실제로는 이진수 11이 아닌 다른 값이 들어가게 됩니다.

그 부분은 아래에서 추가적으로 설명하겠습니다.

편향된 지수 (biased exponent)

부동 소수점의 지수 부분에는 지수를 위한 부호 비트가 없습니다.

지수가 음수인 경우를 표현을 해줘야 하는데요.

그래서 편향된 지수라는 개념이 등장합니다.

바이어스 (biased) 라는 말처럼 지수를 어느 정도 치우치는 것인데요.

쉽게 말해서, 지수값에 특정값을 더해줘서 지수의 음수값과 지수의 양수값을 표현해주겠다는 것입니다.

지수의 값은 2^(비트 수) 만큼 표현될 수 있는데요. (8비트 기준, 2^8 = 256)

그 범위를 절반을 자르고, 0 한개를 제외한 값을 특정 상수 (바이어스 상수)로 정합니다.

(8비트 기준) (2^8 / 2) - 1 = 127

편향된 지수의 개념은, 지수값이 바이어스 상수인 경우 (여기서는 127) 지수값이 0이라고 생각하는 것입니다.

즉, 기존 지수의 값에 바이어스 상수를 빼주면, 편향된 지수의 값을 알 수 있습니다.

지수 비트가 모두 0이거나 1인 경우는 특별하게 사용되는 데요.

그 이유는 아래에서 얘기해보도록 하겠습니다.

지수 부분의 모든 비트가 0이거나 1인 경우

가수의 첫 번째 값을 1로 생략한다고 했는데, 그럼 숫자 0을 표현할 수 없습니다.

지수값이 아무리 작더라도 가수의 형태가 1.xxxxxx 이기 때문에, 0이 되지 않기 때문입니다.

그래서, 모든 비트가 0인 경우와 1인 경우는 조금 다르게 동작하는 것으로 약속을 하였습니다.

지수 부분의 모든 비트가 0인 경우

1. 생략되는 가수의 첫 번째 정수를 0으로 사용한다.

2. 편향된 지수값은 -127이 아닌 -126을 사용한다.

1-1. 1번의 경우, 모든 비트가 0이면 숫자 0을 표현할 수 있습니다.

생략되는 첫번째 가수의 비트가 0이고, 나머지 가수 부분의 비트도 0이기 때문입니다.

(0.00000 ... * 2^(-126) = 0)

1-2. **2^(-127) 보다 작은 값도 표현할 수 있게 됩니다.**

가수 부분이 23비트로 존재하고, 가장 마지막 가수 부분의 비트가 1이라면,

부동 소수점 정규화 표현으로 1 * 2^(-149) 로 표현 가능한데, 이 값은 2^(-127)보다 매우 작은 값입니다.

지수 부분의 모든 비트가 1인 경우

1. 무한 (infinity)

2. NaN (Not a Number)

1-1. 가수 부분이 모두 0이면, 무한의 값을 나타냅니다.

부호 비트에 따라 -infinity와 infinity를 나타냅니다.

(부호 비트가 1이면 -infinity, 0이면 infinity)

1-2. 가수 부분에 1이 한 개 이상 존재하면, NaN 을 나타냅니다.

위와 마찬가지로 부호 비트에 따라 -Nan과 Nan 값을 나타냅니다.

부동 소수점도 한계가 있다

부동소수점을 32비트 기준으로 설명했지만, 64비트, 128비트 등..

비트 수를 더 늘려서, 실수를 더 정밀하게 표현할 수 있습니다.

그렇지만, 무한소수처럼 부동 소수점의 표현법이나 2진수로 표현할 수 없는 값들도 존재합니다.

1.1 + 0.1 값을 표현하지 못함

부동 소수점을 잘 정의하여 넓은 범위의 숫자를 표현할 수 있게 되었지만, 모든 숫자를 표현할 수 없다는 점.

특정한 경우에는 값의 오차가 생긴다는 점을 인지하면서, 개발을 진행하시면 좋을 것 같습니다.

참고

부동소수점 위키백과

부동 소수점의 이해 - DEVOCEAN

[Web] Discord 채팅채널에 Github Action을 이용해서 Vercel 배포 알림 보내기 (Vercel Hobby Plan)

철스커 — Wed, 8 May 2024 18:34:03 +0900

문제 발생

사이드 프로젝트를 진행하고 있는데, 팀 메신저로 Discord를 사용하고 있습니다.

Vercel에 Next.js 웹 애플리케이션을 배포하면, 배포 완료되었다는 알림을 Discord 채널에 보내고 싶은데요.

마땅한 방법을 찾지 못해, 삽질을 많이 했습니다.

Vercel에서 다른 앱과 통합할 수 있는 기능을 제공하는데, Slack과의 연동은 제공해주는 것 같으나 Discord는 없는 것 같더라고요.

Integrations에서 -> Browse Market 버튼을 클릭하면, Vercel과 통합할 수 있는 앱들을 보여줍니다.

Slack은 있지만 Discord는 없습니다...

계속 구글 검색 + 챗GPT로 정보를 찾다가, Discord Pro Plan의 경우 웹훅을 Account 에서 설정할 수 있다고 합니다.

Setting Up Webhooks

Learn how to set up webhooks and use them with Vercel Integrations.

vercel.com

위의 Vercel의 문서에 들어가보면 설명이 잘 되어 있는데요.

제가 원했던 것이 위에 있었습니다.

배포 이벤트를 감지하면, 특정 URL로 HTTP POST 요청을 보낼 수 있다는 것인데요. (웹훅)

아쉽게도 위에서 얘기하고 있는 Account Webhook은 Pro 이상의 Plan 부터 사용이 가능하다고 합니다.

제가 알아본 바에 따르면, Pro Plan 비용은 개인당 1달에 $20이 발생하는 것으로 알고 있습니다.

Hobby Plan에서는 Account Webhook을 사용할 수 없어서, 다른 방법을 알아봐야 했습니다.

Vercel for Github 사용하기

저는 Github Action을 사용해서 Vercel에 배포하지 않고, Vercel for Github을 사용하고 있었는데요.

Github에서도 다른 앱과 통합할 수 있는 기능을 제공해주고 있는데, 여기에서 Vercel을 설치해서 연동한 것입니다.

프로젝트 -> Settings 탭 -> 왼쪽 메뉴에서 Integrations / Github Apps 메뉴를 클릭하면,

다른 앱과 연동할 수 있는 화면이 나옵니다.

Vercel -> Configure 버튼을 누르면, 위와 같이 앱에 대한 상세 내용을 보여줍니다.

위의 Vercel for Github이 연동되어 있으면, Github 저장소에 코드가 배포될 때마다 알아서 Vercel에 배포를 해줍니다.

(물론 Vercel에서 어떤 계정, 어떤 프로젝트, 어떤 브랜치를 어떻게 배포할지는 설정해주셔야 합니다.)

그럼, Github 프로젝트 페이지에서 Deployments 섹션이 보여지고, Vercel에서 가져온 배포 정보들도 볼 수 있습니다.

Preview, Production 버전에 대한 URL도 보여지고 있군요.

Github에서 위의 정보를 보여주고 있다는 것은, Github Action에서도 위의 정보를 꺼내서 사용할 수 있지 않을까요?

구글을 서치해보니, 배포가 실패했을 때, curl로 HTTP 요청을 보내는 워크플로우 파일도 찾을 수 있었습니다.

Vercel-GitHub-Actions/.github/workflows/deploy-failed.yml at main · jst-cyr/Vercel-GitHub-Actions

Actions useful for working with a Vercel-GitHub deployment solution. - jst-cyr/Vercel-GitHub-Actions

github.com

Github Action 으로 Discord 채널에 Vercel 배포 알림 보내기

위의 워크플로우 파일에서 힌트를 얻었습니다.

아래와 같은 순서대로 배포 정보를 보내면 됩니다.

1. Github Action에서 배포 상태를 감지

2. Discord 웹훅 URL로 curl 을 이용해 배포 정보를 전송

name: Deployment Notification to Discord

on:
  deployment_status:

jobs:
  notify-discord:
    name: Notify Discord on Deployment Status
    runs-on: ubuntu-latest
    if: github.event.deployment_status.state == 'success' || github.event.deployment_status.state == 'failure'

    steps:
      - name: Notify Discord
        env:
          DISCORD_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}
        run: |
          STATUS="${{ github.event.deployment_status.state }}"
          ENVIRONMENT="${{ github.event.deployment.environment }}"
          URL="${{ github.event.deployment_status.target_url }}"
          MESSAGE="  Deployment $STATUS  \nENVIRONMENT: $ENVIRONMENT\nURL: $URL\n"
          curl -H "Content-Type: application/json" \
               -d "{\"content\": \"$MESSAGE\"}" \
               $DISCORD_WEBHOOK_URL

위와 같이 워크플로우 파일을 작성해볼 수 있는데요.

deployment_status 이벤트가 발생할 때, 워크플로우가 실행이 되는데요.

타사 (여기서는 Vercel) 에서 배포 상태를 제공할 때, 이벤트가 발생한다고 볼 수 있습니다.

아래 3가지 정보가 중요하다고 판단해서, 이것을 DIscord 채널로 보낼 예정입니다.

deployment_status.state : 배포 상태 (pending, success, failure, error)

deployment.enviroment : 배포 환경 (string 타입, Vercel에서는 preview와 production)

deployment_status.target_url : 타겟 URL (Vercel에서는 preview 또는 production 환경의 URL을 보여줍니다.)

github.event.deployment, github.event.deployment_status 페이로드 참고

https://docs.github.com/ko/webhooks/webhook-events-and-payloads#deployment

https://docs.github.com/ko/webhooks/webhook-events-and-payloads#deployment_status

Discord에서 웹훅 URL 만들기

Discord에서 웹훅 URL을 만들어서 Github Secret에 등록하면 됩니다.

서버 설정 -> 왼쪽 메뉴에서 연동 클릭 -> 웹후크를 클릭합니다.

새 웹후크 버튼을 클릭하면, 웹훅 항목이 하나 생길 텐데요.

이름을 변경하실 수 있고, 어떤 채널에서 웹훅 URL을 받을 것인지 선택합니다.

웹후크 URL을 복사한 후, 이것을 다른 앱에 적용하시면 됩니다.

위의 워크플로우 파일에서는 Github Secret에 등록했기 때문에,

Github에서 워크플로우를 사용할 프로젝트에서 적절한 Secret 이름을 등록하시고, 값으로 Discord 웹훅 URL을 넣어주시면 되겠습니다.

결과

이제 Github을 통해 Vercel 배포가 완료될 때마다, Discord 채널에 배포 알림을 보내줍니다!!

[Typescript] 객체 전개 연산자(Object Spread)에 객체 외에 다른 타입을 넘긴다면?

철스커 — Sun, 21 Jan 2024 23:23:53 +0900

객체를 얕은 복사할 때, 전개 연산자(...)를 많이 사용합니다.

객체 전개 연산자 (Object Spread) 라는 단어처럼 연산자 앞에 객체만 가능할 것이라고 생각했는데요.

아니었습니다.

포스팅 제목과 같은 고민을 하게 된 계기는, 객체 전개 연산자를 특이하게 사용한 코드를 이해하려고 했기 때문인데요.

검색 기능을 제공하는 사이트에서, 필터링 기능을 구현할 때 쿼리 스트링 (URL 파라미터)을 많이 사용하는데, 특정 쿼리를 넘기고 싶지 않을 때가 있습니다.

// 쿼리스트링
const query = {
	name: name,
    age: age,
    ...(isCategory && { category: category }) // isCategory 값에 따라 category 쿼리 유무를 결정
};

// 쿼리스트링을 이용해 라우팅
router.push({
	pathname: '/search'
 	query: query
});

위의 경우처럼 query라는 객체에 isCategory 값에 따라 category 프로퍼티와 값을 전달할 수도 있고, 제거할 수도 있습니다.

isCategory 값이 truthy이면, ...{ category: category }의 결과값이 query 객체로 복사가 됩니다.

isCategory가 falsy이면, ...isCategory의 결과값이 query 객체로 복사가 됩니다.

그렇다는 말은 isCategory의 값이 undefined, null, 0, '', false 될 수 있는데 이 값들 앞에 객체 전개 연산자를 사용할 수 있다는 의미입니다.

// ???

...undefined
...null
...0
...false
...''

객체 전개 연산자를 이용하면, 위의 값들은 객체에 어떻게 전달될까요?

MDN 문서를 확인해보고 해당 문서에 참조된, tc39/proposal-object-rest-spread README 문서에 다음과 같이 적혀있었습니다.

Null/Undefined Are Ignored

let emptyObject = { ...null, ...undefined }; // no runtime error

위의 내용을 살펴보면, "특정값들은" 객체 전개 연산자를 사용하더라도 무시되고, 런타임 에러를 발생하지 않는다는 것을 알게 됩니다.

자바스크립트에서 어떻게 동작하는 지 한번 확인해보도록 하겠습니다. (크롬 브라우저 개발자 도구를 이용)

크롬 브라우저에서 테스트

몇 가지 원시타입을 테스트해보았는데요.

undefined, null, number, boolean 타입의 경우, 객체 전개 연산자를 사용하면 런타임 오류는 발생하지 않지만, 무시 (ignore) 처리되는 걸 확인할 수 있습니다. 모든 경우 객체에 아무런 복사행위를 하지 않습니다.

그렇다면, 참조타입에 객체 전개 연산자를 사용하면 어떨까요?

배열, 문자열, Set, Map 들을 테스트해봤는데요.

배열과 문자열의 경우, 인덱스가 프로퍼티가 되어 객체 안에 값이 복사가 된 것을 확인했습니다.

그런데, Set과 Map은 무시되었습니다.

일단은, 배열과 문자열만 객체로 복사가 되는 것 같습니다.

타입스크립트 환경에서 타입 에러 체크 (TS Playground)

- 타입스크립트 버전 V5.3.3 기준

원시타입의 경우, 타입에러를 표시합니다. ( Spread types may only be created from object types.(2698) )

실행을 해보면, 콘솔에 빈 객체만 찍히는 데요.

런타임 에러는 발생하지 않았습니다.

참조타입을 비롯해서, 이터러블 가능한 값들을 테스트해봤습니다.

참조타입은 타입에러를 발생시키지 않는데요.

위의 크롬 개발자 도구에서 테스트한 것과 마찬가지로 런타임 결과는 동일했습니다.

'123', [1, 2, 3]의 경우 인덱스를 프로퍼티로 갖는 값을 객체로 복사

Set과 Map은 무시됨

결론

객체 전개 연산자 라는 말처럼 객체 앞에서만 사용하는 것이 가장 적절해 보입니다.

하지만, 위의 내용을 바탕으로 객체를 조건적으로 전달하는 코드를 작성할 수 있을 것 같습니다.

참고

MDN 전개 구문 - 객체 전개 구문

ts39/proposal-object-spread/Spread.md

[Typescript] 제네릭 타입을 문자열 리터럴 타입으로 제한하는 몇 가지 방법

철스커 — Sun, 21 Jan 2024 21:33:57 +0900

제네릭 타입을 선언해서, 문자열 리터럴 타입으로 추론하도록 하고 싶은 상황이 발생해서 이것저것 시도하다가 찾은 방법을 정리해봅니다.

세 가지 경우를 예시로 정리해보려고 합니다.

1) 함수에 단일값을 받는 경우

2) 함수에 배열 한 개를 받기

3) 함수에 배열 한 개를 받되, 제네릭 타입을 문자열 타입으로 제한하는 경우

1) 함수에 단일값을 받는 경우

// 단일값
function getValue<T>(param: T) {
    return param
}

const v1 = getValue('string') // 'string' 타입
const v2 = getValue('ABC') // 'ABC' 타입

단일값을 제네릭으로 지정한 경우, 문자열 리터럴 타입으로 타입 추론을 잘하고 있습니다.

2) 함수에 배열 한 개를 받는 경우

function getArray<T>(...params: T[]) {
    return [...params];
}

const a1 = getArray('string1', 'string2', 'string3'); // string[] 타입으로 추론
const a2 = getArray('A' as const, 'B' as const, 'C'); // string[] 타입으로 추론
const a3 = getArray('A' as const, 'B' as const, 'C' as const); // ('A' | 'B' | 'C')[] 타입으로 추론

배열값을 제네릭으로 지정하면, 문자열 값을 넘기면 리터럴 타입이 아닌 문자열(string) 타입으로 추론합니다.

배열 요소의 공통적인 타입을 파악해서, 그 타입으로 추론하는 듯 합니다.

함수 인자에 상수 문자열을 넘겨줘도, 한 개가 문자열 타입이면, 문자열 타입으로 추론합니다.

모든 인자를 상수 문자열로 넘겨줘야, 문자열 리터럴 타입으로 추론하기 시작합니다.

그런데 문자열 리터럴 타입으로 만들기 위해서는 인자 하나하나에 as const를 붙여줘야 합니다.

개발자 입장에서 많이 귀찮을 수 있습니다.

그래서, 다른 방법이 있는지 또 찾아봤습니다.

3) 함수에 배열 한 개를 받되, 제네릭 타입을 문자열 타입으로 제한

function getEnumArray<T extends string>(...params: T[]) {
    return [...params];
}

const e1 = getEnumArray('string1', 'string2', 'string3'); // ('string1' | 'string2' | 'string3')[] 타입으로 추론
const e2 = getEnumArray('A' as const, 'B' as const, 'C'); // ('A' | 'B' | 'C')[] 타입으로 추론
const e3 = getEnumArray('A' as const, 'B' as const, 'C' as const); // ('A' | 'B' | 'C')[] 타입으로 추론

제네릭 인자 T를 문자열(string) 타입으로 제한하면, 이제야 문자열 리터럴 타입으로 잘 추론하기 시작합니다.

위의 예시에서 e2, e3의 경우 인자 일부 또는 전체에 as const를 붙였는데, as const를 빼도 문자열 리터럴 타입으로 추론해줍니다 :)

Typescript 공식 홈페이지의 Playground에서 예제 코드를 테스트해보았는데요.

아래 링크에서 예제 코드를 확인해보실 수 있습니다.

TypeScript Playground에서 테스트 해본 예제 코드

[Javascript] 이터러블과 이터레이터 개념정리

철스커 — Tue, 14 Nov 2023 17:39:02 +0900

이터러블

Symbol.iterator를 프로퍼티 키로 사용한 메서드를 구현하거나 프로토타입 체인을 통해 상속받은 객체.

- for ... of 문으로 순회할 수 있습니다.

- 스프레드 문법, 배열 디스트럭처링 할당을 사용할 수 있습니다.

const arr = [1, 2, 3];

// Symbol.iterator 메서드
console.log(Symbol.iterator in arr) // true;


// for .. of 문
for (const val of arr) {
	console.log(val);
}


// 스프레드 문법
const arr2 = [...arr];


// 배열 구조분해 할당
const [val1, val2] = arr;

이터레이터

이터러블 객체의 Symbol.iterator 메소드를 호출하면 반환되는 객체

이터레이터는 next 메서드를 갖습니다.

이터레이터의 next 메서드는 이터러블 각 요소를 순회하기 위한 포인터 역할을 해주는데요.

next 메서드를 호출하면 순차적으로 한 단계씩 순회하며 순회 결과를 나타내는 "이터레이터 Result 객체"를 반환합니다.

이터레이터 Result 객체는 value와 done 프로퍼티를 갖는 객체입니다.

const arr = [1, 2, 3];

const iterator = arr[Symbol.iterator]();

console.log(iterator.next()); // { value: 1, done: false }
console.log(iterator.next()); // { value: 2, done: false }
console.log(iterator.next()); // { value: 3, done: false }
console.log(iterator.next()); // { value: undefined, done: true }

등장 배경

ES6 이전의 순회 가능한 데이터 컬렉션 (배열, 문자열, 유사 배열 객체, DOM 컬렉션 등)

다들 제각각으로 순회할 수 있는 방법을 제시했습니다. (for 문, for ... in 문, forEach 메서드 등)

ES6부터는 이터러블을 만족하면, 해당 데이터 컬렉션은 (for ... of 문, 스프레드 문법, 배열 구조분해 할당) 등을 사용할 수 있도록 했습니다. 즉, 내부에 Symbol.iterator 메서드가 구현되어 있고, Symbol.iterator가 이터레이터를 반환한다면 어떤 데이터 컬렉션이든 이터러블이 되며, 위의 기능들을 사용할 수 있는 것입니다.

for ... of 문 내부 작동 원리

내부적으로 이터레이터의 next 메서드를 호출하여 이터러블을 순회합니다.

next 메서드가 반환한 이터레이터 리절트 객체의 value 프로퍼티 값을 for ... of 문의 변수에 할당합니다.

이터레이터 리절트 객체의 done 프로퍼티 값이 false이면 계속 순회, true이면 이터러블 순회를 중단합니다.

사용자 정의 이터러블 구현 (피보나치)

객체 내부에 Symbol.iterator 메소드를 구현하고, Symbol.iterator 메소드는 이터레이터를 반환해야 합니다.

이터레이터는 next 메소드를 가지고 있고, next 메소드는 이터레이터 Result 객체를 반환하도록 해줍니다.

const fibo = {
    [Symbol.iterator]() {
      let [pre, cur] = [0, 1];
      const max = 10;

      return {
        next() {
          [pre, cur] = [cur, pre + cur];

          return { value: cur, done: cur >= max };
        },
      };
    },
  };

  for (const v of fibo) {
    console.log(v); // 1 2 3 5 8
  }

참고

모던 자바스크립트 Deep Dive, Ch 34 이터러블

[Javascript] 정규표현식을 이용한 다양한 패턴 예제 정리해보기

철스커 — Sun, 15 Oct 2023 21:34:34 +0900

정리하는 이유

실무에서 사용하거나 알고리즘 테스트를 볼 때, 매번 정규표현식 사용법을 까먹어서 다시 구글링을 하는 경우가 많습니다.

정규표현식 사용법을 찾기 위한 시간적인 비용을 줄이기 위해 자주 사용되는 패턴을 정리해보았습니다.

정규표현식의 정의

일정한 패턴을 가진 문자열의 집합을 표현하기 위해 사용하는 형식 언어 (formal language).

위의 정의는 표현이 어렵게 되어 있는데, 쉽게 말해서 문자열에서 특정 패턴을 찾아서 검색, 치환 등의 작업을 처리할 수 있는 방법이라고 생각하면 될 것 같습니다.

정규표현식과 관련된 자바스크립트 Prototype 메서드

1. RegExp.prototype.xxx

- exec : 패턴에 매칭되는 문자들을 배열로 반환, 매칭하지 않으면 null 반환

- test : 패턴에 매칭하면 true, 아니면 false 반환

2. String.prototype.xxx

- match : 패턴에 매칭되는 문자들을 배열로 반환, 매칭하지 않으면 null 반환

- replace : 패턴에 매칭되는 문자를 특정 문자로 치환할 수 있음, 치환된 문자열을 반환

정규표현식에서 사용하는 메타 문자

정규표현식에서는 특정한 의미를 가진 메타 문자들도 존재합니다.

이것들은 MDN 문서나 아래 링크를 참고하시면 좋을 것 같습니다.

정규표현식에서 자주 사용하는 패턴을 정리하는 위주로 포스팅을 하는 것이라 메타 문자에 대한 자세한 설명을 생략합니다.

정규표현 메타 문자

Metacharacter 정규표현 메타 문자(2023-09-19)

www.ktword.co.kr

정규표현식 패턴 정리

모던 자바스크립트 Deep Dive 책이 정규표현식 패턴을 잘 정리해서, 참고를 많이 했습니다.

사용한 예제는 책과 최대한 다르게 작성하려고 노력했습니다.

1. 문자열 검색

const text = 'Regexp Recording ...';
const regexp = /Regexp/;

// 결과
regexp.test(text); // true
text.match(regexp); // ['Regexp']

2. 임의의 문자열 검색 (메타문자 .을 사용)

const text = 'Regexp Recording ...';
const regexp = /R../g;

// 결과
regexp.test(text); // true
text.match(regexp); // ['Reg', 'Rec']

3. 반복 검색

const text = 'The fear of the LORD is the beginning of knowledge';

// t로 시작하고 뒤에 문자 1개 또는 2개
text.match(/t.{1,2}/gi); // ['The', 'the', 'the]

// t로 시작하고 뒤에 문자 4개
text.match(/t.{4}/gi); // ['The f', 'the L', 'the b']

// o로 시작하고 뒤에 f 1개 이상
text.match(/of{1,}/gi); // ['of', 'of]

// b로 시작하고 뒤에 문자 1개 이상 존재
text.match(/b.+/gi); // ['beginning of knowledge']

// t로 시작하고 뒤에 문자 0개 또는 1개
text.match(/t.?/gi); // ['Th', 'th', 'th']

4. OR 검색

const text = 'The fear of the LORD is the beginning of knowledge';

// 대문자 L '또는' O '또는' R '또는' D
text.match(/L|O|R|D/g); // ['L', 'O', 'R', 'D']

// 대문자 L '또는' O '또는' R '또는' D
text.match(/[LORD]/g); // ['L', 'O', 'R', 'D']

// t로 시작하는 두글자 '또는' o로 시작하는 두글자
text.match(/t.|o./g); // ['of', 'th', 'th', 'of', 'ow']

// 단어 경계에서부터 세글자인 소문자
text.match(/\b[a-z]{3}/g); // ['fea', 'the', 'the', 'beg', 'kno']

// 단어 경계에서부터 시작하는 문자 그리고 단어 경계로 끝나야 함
text.match(/\b[a-z]+\b/g); // ['fear', 'of', 'the', 'is', 'the', 'beginning', 'of', 'knowledge']

5. NOT 검색

const text = 'My name is cheolsker AND age is 999';

// 공백, 알파벳을 제외한 1개 이상의 문자
text.match(/[^A-Za-z\s]+/g); // ['999']

6. 시작 위치로 검색

// 주의 : [] 밖의 ^는 문자열의 시작을 의미, [] 안의 ^은 NOT을 의미합니다.

const text = 'My name is cheolsker AND age is 999';
const regexp = /^My /;

// My로 시작하는 문자열인지 검사
regexp.test(text); // true

7. 마지막 위치로 검색

// 주의 : [] 밖의 ^는 문자열의 시작을 의미, [] 안의 ^은 NOT을 의미합니다.

const text = 'My name is cheolsker AND age is 999';
const regexp = /999$/;

// 999로 끝나는 문자열인지 검사
regexp.test(text); // true

자주 정규표현식 패턴 정리

1. 숫자로만 이루어진 문자열인지 검사

const num = '202310152112'

// case 1
/^\d+$/.test(num); // true

// case 2
/^[0-9]+$/.test(num); // true

// case 3
/^[^\D]+$/.test(num); // true

2. 아이디로 사용 가능한지 검사

const id = 'cheolsker101';

// 8 ~ 12자리인 알파벳 대소문자와 숫자의 조합인지 검사
/^[A-za-z0-9]{8,12}$/.test(id); // true

3. 메일 주소 형식에 맞는지 검사

const email = 'cheolsker101@tistory.com';

/^[0-9a-zA-Z]([-_\.]?[0-9a-zA-Z])*@[0-9a-zA-Z]([-_\.]?[0-9a-zA-Z])*\.[a-zA-Z]{2,3}$/
.test(email) // true;

4. 핸드폰 번호 형식에 맞는지 검사

const phone = '010-0000-0000';

/^\d{3}-\d{3,4}-\d{4}$/.test(phone); // true

5. 특수 문자 포함 여부 검사

const text = '특수 Special !@# 문자 !';

// NOT을 이용한 특수문자 검사
(/[^A-Za-z0-9]/gi).test(text); // true

// OR을 이용해서 특수문자 검사 (특수문자를 직접 타이핑)
(/[\{\}\[\]\/?.,;:|\)*~`!^\-_+<>@\#$%&\\\=\(\'\")]/gi)
.test(text); // true;

참고

모던 자바스크립트 Deep Dive: 자바스크립트의 기본 개념과 동작원리, Ch 31 RegExp

정규표현 메타 문자

[Next.js] 페이지 성능 개선하기 3 - API Prefetch 하기

철스커 — Tue, 22 Aug 2023 17:54:39 +0900

모바일 기준, 성능 점수

두 차례 성능 최적화를 진행하고 측정했던 성능 점수입니다.

지난 이야기...

[Next.js] 페이지 성능 개선하기 2 - 번들 사이즈 개선, Tree Shaking

지난 시간에 측정했던 성능 점수입니다. (모바일 기준) 지난 시간에 성능 개선을 시도했던 흔적 [Next.js] 페이지 성능 개선하기 1 - Next/image, CSS 프리로드 최근 들어 성능 최적화에 대한 고민을

cheolsker.tistory.com

이번 포스팅으로 이번 시리즈(?)를 마무리해볼까 합니다.

배너 이미지(LCP)가 늦게 렌더링 되는 원인은 API 호출 후, 이미지 링크를 받아오기 때문인데요.

이 API를 사전에 호출하면 LCP를 개선해볼 수 있을 것 같습니다.

이 프로젝트는 React-Query를 사용하고 있고, 마침 이 라이브러리는 prefetchQuery라는 기능을 가지고 있습니다.

또한 Next.js는 페이지 렌더링 이전에 데이터를 가져올 수 있는 함수를 제공합니다.

배너 이미지는 자주 변경될 수 있을 가능성이 있으므로 페이지 요청할 때마다 데이터를 미리 가져와야 겠습니다. (getServerSideProps 함수 사용할 예정)

export const getServerSideProps: GetServerSideProps = async (context) => {
	const queryClient = new QueryClient();

    try {
        await queryClient.prefetchQuery([QUERIES.GET_CATALOGS], () =>
            getCatalogs({
            	size: 100,
        	}).then(({ data }) => data.content),
    	);

        return {
            props: {
                dehydratedState: dehydrate(queryClient),
            },
        };
    } catch (e) {
        return {
        	props: {},
        };
    } finally {
    	queryClient.clear();
    }
};

페이지 레벨에서 해당 Query를 미리 호출(prefetch)하고, 배너를 사용하는 쪽에서 캐시된 Query를 사용하면 됩니다.

모바일 기준으로 61 -> 77점으로 대폭 상승했습니다.

FCP 0.8s -> 0.9s (+0.1s)

LCP 6.2s -> 3.8s (-2.4s 만큼 개선)

TBT 40ms -> 40ms (동일)

CLS 0.247 -> 0.087 (-0.16만큼 개선)

Speed Index 5.2s -> 21.4s (+16.2 만큼 악화)

Lighthouse 검사를 할 때, 점수가 들쭉날쭉하는 경우가 있는데, Next 서버와 API 서버의 거리 (네트워크 상으로)가 멀어서 그런 것 같습니다. Speed Index가 악화된 원인은 Next 서버에서 데이터를 가져와서 렌더링하기까지, 클라이언트에 HTML을 전달하지 않은 것으로 보입니다.

[Next.js] 페이지 성능 개선하기 2 - 번들 사이즈 개선, Tree Shaking

철스커 — Mon, 21 Aug 2023 19:19:19 +0900

지난 시간에 측정했던 성능 점수입니다. (모바일 기준)

지난 시간에 성능 개선을 시도했던 흔적

[Next.js] 페이지 성능 개선하기 1 - Next/image, CSS 프리로드

최근 들어 성능 최적화에 대한 고민을 많이 해보고 싶어서, 성능 최적화를 해봐야 겠다는 생각이 들었습니다. 예전에 진행했던 프로젝트 중 하나가, Lighthouse 점수가 낮게 나와서 몇 가지 개선을

cheolsker.tistory.com

번들 사이즈를 개선할 필요가 있을 것 같습니다.

@next/bundle-analyzer를 설치하고, next.config.js에 적용하였습니다.

@next/bundle-analyzer 설치

// 터미널에서 설치
yarn add -D @next/bundle-analyzer

또는

pnpm add -D @next/bundle-analyzer

// next.config.js

const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',  // 환경변수 ANALYZE가 true일 때 실행
  openAnalyzer: false,  // 브라우저에 자동으로 분석결과를 새 탭으로 Open하는 것을 방지
});


...


module.exports = withBundleAnalyzer(nextConfig);

ANALYZE=true next build

빌드가 된 후, 번들된 파일들을 분석할 것이므로 위와 같이 빌드 명령어를 입력합니다.

빌드가 끝나면, .next 폴더에 analyze 폴더가 생성이 되고 번들링을 분석한 HTML 파일이 생성됩니다.

client.html : 클라이언트에서 사용되는 번들링 분석

nodejs.html : 서버사이드에서 사용되는 번들링 분석

edge.html : ???, 이 파일을 열어보면 빈 화면만 나오고, 문서(docs) 상으로도 설명이 없습니다..

client.html를 열어 번들 파일 분석

client.html

클라이언트 쪽에서 사용하는 번들링만 확인해보려고 하는데요.

이 번들링 파일 중에서 _app-***.js 파일의 크기가 유독 큽니다.

_app-***.js 사각형 화면에 마우스를 올려보면, Stat size / Parsed size / Gzipped size 가 보입니다.

Stat size : Minification, Uglify 등의 변형이 일어나기 전의 크기

Parsed size : Minification, Uglify 등의 변형이 일어난 후의 크기 (최적화 후), 브라우저에서 파싱 후, 실행될 크기

Gzipped size : Gzip 알고리즘으로 압축된 파일 크기, 네트워크를 통해 전송되는 크기

(출처 : https://www.npmjs.com/package/webpack-bundle-analyzer#size-definitions)

즉, Parsed size와 Gzipped size를 줄인다면,

브라우저에서 자바스크립트를 다운로드하고 실행하는 시간과 네트워크 상에서 전송되는 시간을 단축시킬 수 있습니다.

chunk 번들

페이지별 번들

Next 빌드를 실행하면 위 그림과 같이 chunk 번들과 페이지 번들이 생성됩니다.

chunk 파일은 페이지 공통적으로 사용되는 것으로 알려져 있습니다.

bundle-analyzer로 이 chunk 번들을 살펴보면, 다음과 같이 추정해볼 수 있습니다.

chunks/framework-*** : 프레임워크와 관련 (react-dom과 react)

chunks/main-*** : Next와 관련된 기능 (next/dist - router 포함)

chunks/pages/_app-*** : _app 페이지와 관련

chunks/webpack-*** : 웹팩 스크립트 코드 (build-manifest.json을 확인해서 페이지 이동 시, 필요한 JS를 로드, 참고)

이 chunk들은 모든 페이지에서 사용되는 파일들이기 때문에, 파일 사이즈를 줄이는 것이 좋겠습니다.

다른 chunk과 다르게 _app-*** 파일이 크기도 하고 수정가능할 것으로 보입니다.

chunks/pages/_app-*** 번들 파일 분석

_app-*** 번들

_app-*** 번들에서 components 부분을 확대

_app 페이지는 공통 레이아웃, CSS, 로직들을 포함하고 있습니다.

그런데 Alert, Loading 등... 특정 동작이 발생할 때만, 컴포넌트를 렌더링해도 되는 경우도 있어서, 관련 컴포넌트는 지연 로딩으로 처리해도 될 것 같습니다. (초기 로딩에는 필요없기에)

또한 swiper, xregexp 등의 라이브러리도 사용해서 그런지 _app-*** 번들에 관련 모듈이 확인되고 있는데요.

_app 페이지의 코드를 살펴보면, 실제로 사용되고 있지는 않았습니다.

유틸 모듈에서 일부 함수만 export해서 사용하고 있는데, 유틸 모듈 내부의 export하지 않은 함수 일부가 xregexp 라이브러리를 사용하고 있습니다. 그런데 이 함수들도 빌드 과정에서 같이 번들링된 것입니다. 특정 모듈에서 사용하지 않은 함수들은 번들링될 필요가 없는데, 빌드 단계에서 이 함수들을 제거하지 않는 것으로 보입니다. 즉, Tree Shaking이 동작하고 있지 않았습니다.

컴포넌트 지연 로딩

import dynamic from 'next/dynamic';

...

const Spinner = dynamic(() => import('@/components/common/Spinner'));
const Portal = dynamic(() => import('@/components/layouts/Portal'));
const Alert = dynamic(() => import('@/components/common/Alert'));

function AppLayout({ children }: AppLayoutProps) {
    const { alert, closeAlert } = useAlert();
    const { isLoading } = useLoading();

    return (
        <StyledAppLayout>
            {children}
            {isLoading && <Spinner isFullScreen />}
            {alert.isOpen && (
                <Portal>
                    <Alert {...alert} onClose={closeAlert} />
                </Portal>
            )}
        </StyledAppLayout>
    );
}

위와 같이 dynamic을 사용하여 컴포넌트를 지연로딩 시켜줍니다.

Alert가 open되거나, 로딩이 true인 상태일 때 필요한 컴포넌트를 로딩 & 렌더링시켜주면 됩니다.

Tree Shaking 적용하기

package.json에 sideEffects 옵션을 제공하여 웹팩에게 사이드 이펙트(부수 효과)가 있는 파일들을 알려줄 수 있습니다.

// package.json

{
    "name": "opt",
    "version": "1.0.0",
    "sideEffects": false,
    ...
}

sideEffects를 false로 설정하면, 사이드 이펙트가 없기 때문에 웹팩에게 사용하지 않은 export는 빌드 단계에서 제거하도록 알려줍니다.

// package.json

{
    "name": "opt",
    "version": "1.0.0",
    "sideEffects": [
    	'**/*.css'
    ]
    ...
}

sideEffects가 있는 파일이 있으면 배열 안에 Glob 패턴의 문자열 값을 넣어줍니다.

이 파일들은 Tree Shaking 대상에서 제거됩니다.

_app-*** 번들

_app-*** 번들의 components 부분 확대

Tree Shaking을 적용한 후, 빌드된 _app 번들 파일을 확인해봤습니다.

그 결과, swiper, xregexp 라이브러리들이 _app-*** 번들에서 제거되었고, 지연로딩처리했던 Alert, Loading 등의 컴포넌트들도 번들에서 제거되었습니다.

번들 사이즈는 Parsed size와 Gzipped size 각각

550.11KB -> 292.07KB

169.76KB -> 88.32KB

로 줄어들었는데 기존의 절반에 가까운 사이즈로 줄어들었습니다.

줄어든 _app 번들 사이즈는 초기 페이지 로딩 개선에 도움이 될 것입니다.

모바일 기준, 성능 점수 결과

모바일 기준으로 59 -> 61점으로 소폭 상승했네요.

FCP 0.8s -> 0.8s (동일)

LCP 7.4s -> 6.2s (-1.2s 만큼 개선)

TBT 100ms -> 40ms (-60ms 만큼 개선)

CLS 0.247 -> 0.247 (동일)

Speed Index 5.4s -> 5.2s (-0.2s 만큼 개선)

배너 이미지는 API 결과로 받아온 이미지 링크를 렌더링하기 때문에 늦어지는 부분이 있는데요.

이 부분을 개선하고, CLS 부분을 좀 더 개선할 필요가 있겠습니다.

참고

how-analyze-next-js-app-bundles

Tree Shaking | 웹팩

[Next.js] 페이지 성능 개선하기 1 - Next/image, CSS 프리로드

철스커 — Thu, 17 Aug 2023 20:46:13 +0900

최근 들어 성능 최적화에 대한 고민을 많이 해보고 싶어서, 성능 최적화를 해봐야 겠다는 생각이 들었습니다.

예전에 진행했던 프로젝트 중 하나가, Lighthouse 점수가 낮게 나와서 몇 가지 개선을 통해 성능 개선을 하려고 합니다.

이 프로젝트는 Next 12 버전을 이용하여 개발되었고, HTTP/2 프로토콜을 사용하고 있습니다.

앱 서비스이기 때문에, Lighthouse에서 모바일 기준으로 성능 검사를 진행하였습니다.

Lighthouse를 이용한 성능 점수 확인

Lighthouse 점수와 진단 항목

이 페이지는 이미지가 굉장히 많습니다.

상단에 배너 슬라이드를 통해 여러 개의 이미지가 보여지고, 뷰포트 아래에도 섹션별로 많은 이미지를 로드합니다.

LCP도 무려 15.8초가 걸립니다.. 일단은 이미지 로드에 대한 개선이 확실히 필요할 것 같습니다.

이미지 크기가 큰 순서대로 정렬

이미지 요청 개수는 41개이고, 총 크기는 15.8MB 입니다.

어떤 이미지는 1MB가 넘어갑니다.

Next/image를 사용하지 않은 컴포넌트가 많았는데요.

Next/image를 통해서 개선하고자 합니다.

Next/Image를 사용하려는 이유

첫번째로 Lazy loading이 있습니다.

지연 로딩이라고 부르는 이것은 이미지 또는 JS 파일을 나중에 로드하는 것을 의미합니다.

사용자가 보게 되는 첫 화면에서는 화면 밖의 이미지를 미리 불러올 필요가 없습니다.

Next/Image를 사용하여 이미지를 로드하는 경우, 기본적으로 지연 로딩이 적용이 됩니다.

이미지가 많은 페이지에서는 Next/Image를 사용하는 것이 브라우저에 초기 이미지 요청 갯수를 확연하게 줄여줄 수 있습니다.

두번째로 WebP 이미지를 생성해줍니다.

WebP 이미지 포맷은 구글에서 만든 것으로 JPEG (손실 압축)과 비손실 압축 (PNG, GIF) 등의 이미지를 대체할 수 있습니다.

또한 이미지 파일 크기도 20~30% 정도 줄일 수 있다고 합니다.

Next.js는 이미지 최초 요청 시, 이미지를 WebP 포맷으로 변환하여 생성하고 원본 이미지 대신 변환된 이미지를 제공합니다.

Next.js 서버에 생성된 WebP 이미지

그 밖에 placeholder 이미지를 제공하거나, priority 옵션, sizes 등을 제공할 수 있는데요.

크게 두 가지 이유를 통해 브라우저의 이미지 로딩 속도를 개선해볼 수 있겠습니다.

Next/Image로 생성되는 img 요소의 srcset, sizes 지정하기

Next/Image로 생성된 img 요소를 검사해보면 다음과 같이 렌더링이 됩니다.

srcset에 굉장히 많은 이미지 링크들이 매핑이 되고 있는데요.

사용자의 화면 크기에 따라 최적화된 이미지를 제공하는 것입니다.

하지만 이미지 최초 요청 시, 필요한 이미지보다 많은 이미지를 생성할 수 있어서, 최초 이미지 로딩 시간이 지연될 수 있고 Next 서버 쪽에도 불필요한 이미지로 인한 용량이 증가할 수 있습니다.

next.config.js 설정파일에 images에서 이 문제점을 해결할 수 있는데요.

imagesSizes와 deviceSizes를 지정해주면 됩니다.

imagesSizes는 디바이스 크기보다 작은 이미지 사이즈를 정의한 배열이고, deviceSizes는 디바이스 크기를 정의한 배열입니다.

이 두 개가 합쳐져서 이미지들이 생성되고, srcset에도 이미지 링크들이 매핑되는 것입니다.

// next.config.js
const nextConfig = {
	images: {
		imageSizes: [33, 50],
		deviceSizes: [420, 768, 1080, 1200, 1920, 2048],
    },
    
    ...
},

next.config.js를 수정하고 확인해보면, srcset에 필요한 이미지 링크들만 제공할 수 있습니다.

sizes도 사용해서 이미지 크기가 디바이스 크기보다 작은 경우, 더 작은 사이즈의 이미지를 로딩하도록 처리했습니다.

// 예시
<Image
    src={data.bannerImage}
    alt={data.title}
    layout="responsive"
    width={768}
    height={450}
    sizes="(max-width: 420px) 420px, (max-width: 768px) 768px"
/>

CSS 프리로드 하기

https://web.dev/avoid-invisible-text/

Chrome 성능 탭으로 폰트 로딩 체크

폰트가 나중에 로드되어 문제가 생길 수 있다는 진단이 있었습니다.

글꼴이 바뀌는 현상이 일어나거나 CLS 문제를 일으킬 소지가 있어 보입니다.

CSS-in-JS를 사용하여 폰트를 로드하는 코드를 커스텀 앱 페이지 (_app)에 넣어주었는데요.

JS가 로드되고 나서 폰트를 로드하는 것으로 추정됩니다.

// _app.tsx

...
<Head>
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui, viewport-fit=cover"
    />
<link rel="preload" href="/fonts/campton.css" as="style" />
<title>opt</title>
</Head>

campton.css 를 먼저 로드하기 시작

커스텀 앱 페이지를 수정해줄 필요가 있겠습니다.

폰트를 로드하는 부분을 CSS 파일로 분리한 뒤, 커스텀 앱에 Next.js에서 제공하는 Head 태그를 사용해서 프리로드하도록 코드를 수정했습니다.

이제 브라우저에서 폰트와 관련된 CSS를 우선적으로 로드하게 됩니다.

성능 개선 결과는 ?

초기 화면을 로딩하는 데 다운로드한 총 이미지 크기가 428kB 입니다.

개선 전에는 15.8MB 였는데, 15.8MB -> 428kB로 최적화된 것입니다..!

(15.8 * 1024) / 428 -> 약 1/38 크기로 줄어들었습니다.

개선 후에 가장 큰 이미지 크기는 42.6kB입니다. (1MB에 비해 이미지 사이즈가 굉장히 줄어들었습니다.)

그럼 Lighthouse 점수는 어떻게 될까요?

모바일 기준

모바일 기준으로 59점으로 소폭 상승했네요.

FCP 1.0s -> 0.8s

LCP 15.8s -> 7.4s

TBT 70 -> 100

CLS 0.211 -> 0.247

Speed Index 18.6s -> 5.4s

LCP와 Speed Index가 많이 개선되었습니다.

모바일 기준으로 후한 성능 점수를 받지 못했네요.

다른 부분을 더 개선할 필요가 있어 보입니다.

PC 기준

PC 기준으로 검사해보면 성능 점수가 무려 94점이 나옵니다.. !

모바일 기준은 매우 엄격하네요.

다른 부분도 좀 더 개선해보도록 하겠습니다.

참고

Next/Image를 활용한 이미지 최적화

Next.js 공식문서 - Next/Image

[Jest] Web Storage 테스트하기 (LocalStorage, SessionStorage)

철스커 — Sat, 5 Aug 2023 19:40:24 +0900

웹 스토리지 유틸 함수에 대한 테스트 코드를 작성하다가 조금 헤매고 난 후에 해결해서 그 과정을 글로 남기고자 합니다.

스토리지 유틸 함수를 만든 이유

스토리지 API를 이용해서 바로 특정 값을 가져올 수도 있을 텐데요.

그럼에도 불구하고, 유틸 함수를 별도로 만드는 이유는 스토리지가 문자열 값만 저장하기 때문입니다.

특히 스토리지에 객체를 JSON 형태의 문자열로 저장하는 것이 유용할 텐데요.

객체를 바로 스토리지에 저장하게 되면 [object Object] 형태의 문자열로 변환되어 저장되기 때문에 유틸 함수에서 JSON 문자열로 변환시켜서 스토리지에 저장하려는 것입니다. (toString의 동작방식 때문)

// 스토리지 유틸 함수 예시
export const getSessionStorageItem = (key: string) => {
	const storageItem = sessionStorage.getItem(key) || '';

    if (!storageItem) {
	    return null;
    }

    try {
	    return JSON.parse(storageItem);
    } catch (e) {
    	console.error(e);

    	return storageItem;
    }
};

export const setSessionStorageItem = (key: string, value: string) => {
    if (!key || !value) {
        throw new Error('잘못된 key를 전달했습니다.');
    }

    sessionStorage.setItem(key, value);
};

세션 스토리지의 메소드를 모킹하면 될까?

위의 예제에서 유틸 함수 내부에 sessionStorage의 getItem, setItem을 사용하여 기능을 구현하고 있습니다.

sessionStorage의 getItem과 setItem을 모킹해서 어떤 객체에 값을 읽거나 쓰도록 해서 테스트를 구현하면 되지 않을까? 라는 생각이 듭니다.

// storageUtil.test.ts

// 각 테스트 suite 실행되기 전에 스토리지 모킹 & 셋팅
beforeAll(() => {
    const storage: Record<string, any> = {
	    wrongKey: ' ',
    	goodKey: 1,
    };

    sessionStorage.getItem = jest.fn((key: string) => {
        // 모킹한 함수가 실행되는지 로그로 확인
        console.log('/// getItem ///');

        return storage[key];
    });

    sessionStorage.setItem = jest.fn((key: string, value: string) => {
        // 모킹한 함수가 실행되는지 로그로 확인
        console.log('/// setItem ///');

        storage[key] = value;
    });
});

// getSessionStorageItem 테스트
describe('getSessionStorageItem', () => {
    it('key에 대한 값을 반환한다.', () => {
	    expect(getSessionStorageItem('goodKey')).toBe(1);
    });
});

// setSessionStorageItem 테스트
describe('setSessionStorageItem', () => {
    it('key에 대한 value값을 세션스토리지에 저장한다.', () => {
	    setSessionStorageItem('key', 'key');

    	expect(getSessionStorageItem('key')).toBe('key');
    });
});

위와 같이 sessionStorage의 getItem, setItem을 모킹하고, 혹시 몰라서 모킹 함수 내부에 로그를 넣었습니다.

테스트를 돌려보면, 로그가 찍히지 않고 getItem과 관련된 테스트는 실패하게 되는데요.

왜 이런 현상이 발생하는 지 명확한 원인을 찾기가 쉽지 않습니다...

(세션 or 로컬) 스토리지는 Storage 객체의 인스턴스 일뿐...

크롬 브라우저에서 sessionStorage가 어떤 프로퍼티를 가지고 있는 지 확인하고 있습니다.

보시면 sessionStorage 내부가 아닌 Storage.prototype 객체에 스토리지의 메소드들이 구현이 되어 있습니다.

즉, 로컬 스토리지와 세션 스토리지는 Storage 객체의 인스턴스일 뿐이며, 자체적으로 메소드가 없기 때문에 getItem, setItem을 모킹해도 기대했던 동작을 하지 않았던 것입니다. (로컬 스토리지나 세션 스토리지에서 메소드를 호출할 때는 프로토타입 체이닝으로 호출)

2가지 방법으로 스토리지를 모킹할 수 있습니다.

첫 번째 방법은 localStorage 또는 sessionStorage 자체를 모킹하는 것입니다.

별도의 객체를 만들어서 getItem, setItem 등의 메소드를 구현해볼 수 있을 텐데요.

좀 번거롭다는 부분이 있습니다.

두 번째 방법은 Storage.prototype의 메소드를 모킹하는 것입니다.

Storage.prototype.getItem, Storage.prototype.setItem 부분만 모킹하면 되기 때문에 위의 방법보다는 단순하게 테스트를 검증해볼 수 있겠습니다. 두 번째 방법으로 테스트 코드를 작성해보겠습니다..!

// storageUtil.test.ts

// 여기 부분만 바꿔주면 되겠네요..! 
beforeAll(() => {
    const storage: Record<string, any> = {
        wrongKey: ' ',
        goodKey: 1,
	};

    Storage.prototype.getItem = jest.fn((key: string) => {
        console.log('/// getItem ///');
        return storage[key];
    });

    Storage.prototype.setItem = jest.fn((key: string, value: string) => {
        console.log('/// setItem ///');
        storage[key] = value;
    });
});

// getSessionStorageItem 테스트
describe('getSessionStorageItem', () => {
	...
});

// setSessionStorageItem 테스트
describe('setSessionStorageItem', () => {
	...
});

beforeAll 내부의 코드만 변경해주면 될 것 같네요.

혹시 몰라서, 모킹 함수 내부에 로깅을 남겨 보겠습니다.

테스트 코드를 돌려보면, 로그가 정상적으로 찍히고 테스트 구문(Suite)들이 정상적으로 통과하게 됩니다.

[Jest] 테스트 작성 시, window.alert 모킹하기 (jest.fn, jest.spyOn)

철스커 — Sat, 5 Aug 2023 15:01:14 +0900

문제 발생

쪽지 작성 API를 실패했을 때

웹 서비스를 개발하던 중에, 다음과 같이 특정 API를 호출하고 실패했을 때 window.alert로 사용자에게 오류 메시지를 보여주는 기능을 구현했습니다. 버튼을 클릭하면 로딩이 보이면서, API 호출이 마무리될 때까지 기다렸다가 성공하면 다음 페이지로 이동하고, 실패하면 오류 메시지를 보이는 형태입니다.

위의 기능과 관련된 컴포넌트에 대한 테스트 코드를 작성하고 있던 중이었습니다.

API를 모킹해서 실패하도록 처리한 후, 오류 메시지를 보이는 것. 즉, window.alert가 실행되었는 지 검증하는 중이었는데요.

다음과 같은 오류가 발생했습니다.

Not implemented: window.alert 에러

Jest의 테스트 환경 (testEnviroment)는 jest-environment-jsdom 으로 셋팅되어 있는데요.

JSDOM 환경에는 window.alert가 구현이 안되어 있는 것입니다.

결국 window.alert를 모킹해서 테스트를 검증해야 합니다.

Jest에서 제공하는 기능 중, 두 가지를 사용해서 위의 문제를 해결할 수 있었습니다.

jest.fn 사용하기

Jest에서 제공하는 모킹 함수를 사용하는 것입니다.

window.alert를 모킹 함수로 대체하고, window.alert('오류 메시지') 형태의 함수를 실행하기 때문에, 인자(argument)로 오류 메시지를 잘 받는 지 검증하면 됩니다.

it('API 실패 시, 에러 메시지를 보여준다.', async () => {
  // API 호출하는 코드 ... (생략)

  // window.alert를 모킹 함수로 대체
  window.alert = jest.fn();

  // 버튼을 클릭하면 API를 호출합니다.
  fireEvent.click(screen.getByText('쪽지 작성완료'));

  // 비동기적으로 API를 호출하기 때문에 waitFor를 사용했습니다.
  await waitFor(() => {
    // 오류 메시지를 인자로 받는 지 검증합니다.
    expect(window.alert).toBeCalledWith('쪽지 작성하기를 실패했습니다.');
  });
});

jest.spyOn 사용하기

jest.spyOn은 jest.fn()과 비슷하게 모킹 함수를 생성해서 리턴하지만, 특정 객체의 메소드를 추적(Track)하는 기능을 제공합니다. 원본 객체를 수정하지 않고, 어떤 행동을 하는 지 감시할 수 있는데요.

앞서 설명했듯이, JSDOM에서는 window.alert가 구현되어 있지 않기 때문에, 단순하게 jest.spyOn을 사용하면 window.alert가 없다는 오류가 발생합니다.

다행히 jest.spyOn도 추적하는 메소드를 모킹할 수 있는데요.

jest.fn()과 똑같이 mockImplementation(fn)을 사용하면 됩니다.

it('API 실패 시, 에러 메시지를 보여준다.', async () => {
  // API 호출하는 코드 ... (생략)

  // window.alert를 추적, 모킹
  const spy = jest.spyOn(window, 'alert').mockImplementation(() => null);

  // 버튼을 클릭하면 API를 호출합니다.
  fireEvent.click(screen.getByText('쪽지 작성완료'));

  // 비동기적으로 API를 호출하기 때문에 waitFor를 사용했습니다.
  await waitFor(() => {
    // 이번엔 spy 함수가 오류 메시지를 인자로 받는 지 검증합니다. 
    expect(spy).toBeCalledWith('쪽지 작성하기를 실패했습니다.');
  });
});

테스트 통과 !

위의 두 가지 방법 중, 한 가지를 선택해서 테스트 코드를 작성하면 테스트를 성공적으로 통과하게 됩니다.

[React] 컴포넌트를 어떻게 잘 구현할 수 있을까?

철스커 — Sat, 29 Jul 2023 19:56:03 +0900

컴포넌트 구현을 안 해본 FE 개발자는 없을 것입니다.

개발자마다 각자의 기준에 의해 컴포넌트 단위를 결정하고 컴포넌트의 형태, 기능을 정의합니다.

컴포넌트 구현 방법은 명확한 정답은 없다고 생각합니다.

- 컴포넌트마다도 형태, 기능이 다르기도 하고,

- 어느 곳에서 사용하는 지,

- 개발 기한이 얼마나 주어졌는지에 따라 컴포넌트 설계에 대한 고민의 시간이 달라지기 때문입니다.

다만, 컴포넌트를 잘 구현해놓으면 개발 생산성이 높아지기 때문에 많은 고민이 필요한 것은 사실인 것 같습니다.

저는 주로 신규 프로젝트에 많이 참여했었고, 프로젝트들 별로 디자인이 달랐습니다.

그래서 아토믹 디자인 패턴을 사용하지 않았고, 회사 내에 디자인 시스템도 만들 필요가 없었는데요.

이런 환경의 기준 (소규모 프로젝트) 으로 컴포넌트를 다음과 같이 정리했습니다.

컴포넌트를 만들 수 있는 경우 4가지

1. 여러 페이지에서 사용이 되는가? (공통 컴포넌트 or 디자인 시스템 컴포넌트 일 가능성 ⬆️)

2. 반복적으로 사용되는 UI를 가지고 있는가?

3. 페이지에서 의미론적으로 구분해야 하는가?

4. 뷰 로직이 많아져서 정리할 필요가 있는가?

* 여러 페이지에서 사용이 되는가?

페이지에서 전역적으로 사용할 수 있는 컴포넌트를 의미합니다.

버튼, 팝업, 모달, 네비게이션 바 등이 있으며, 공통 컴포넌트 또는 디자인 시스템의 컴포넌트로 정의할 수 있습니다.

이런 컴포넌트는 여러 곳에서 사용할 수 있다는 점에서 재사용적인 의미가 강하게 드러납니다.

'네비게이션 바'와 '버튼'이 두 페이지에서 사용되고 있다.

* 반복적으로 사용되는 UI를 가지고 있는가?

반복적으로 UI를 그려야 할 때가 있습니다.

댓글 리스트의 댓글, 이벤트 배너 슬라이드의 배너, 어떤 리스트의 특정 항목 하나와 같이

반복적으로 표현할 수 있는 UI + 데이터의 조합을 컴포넌트로 구분할 수 있습니다.

* 페이지에서 의미론적으로 구분할 수 있는가, 뷰 로직을 정리할 필요가 있는가?

이 두 가지 경우로 컴포넌트를 만드는 경우는 같은 이유로 설명할 수 있을 것 같습니다.

바로 '가독성'인데요.

가령, 위 페이지의 '글 작성하기', '오늘의 사진' 부분을 구현한다고 했을 때,

<PageContainer css={containerCss}>
	<Navigation>
		<Navigation.Back />
		<Navigation.Title>쪽지 작성</Navigation.Title>
	</Navigation>
    
    {/* 글 작성하기, 오늘의 사진 */}
	<section>
		<div>
        	<h3>글 작성하기</h3>
            <div>
        		<textarea placeholder="예)" value={text} onChange={handleChange} />
      		</div>
            <div>
				<span>{text.length}/500</span>
            </div>
        </div>
        <div>
            <h3>오늘의 사진</h3>
            <PhotoUpload>
	            <label htmlFor="fileUpload">
            	<Button variant="dashed">
    	        	<ButtonContents>
            			<Icon name="Camera" width={24} height={24} />
		            	<div>사진 추가하기</div>
        	    	</ButtonContents>
            	</Button>
            </label>
            <input
                id="fileUpload"
                type="file"
                accept="image/*"
                multiple
                max={3}
                onChange={handleChange}
                onClick={(e: any) => (e.target.value = null)}
            />
            </PhotoUpload>
        </div>
    </section>
	
    ...
</PageContainer>

이렇게 구현하면 뷰 로직이 많아져서 한 눈에 보기 어려운 경우가 있습니다.

<PageContainer css={containerCss}>
	<Navigation>
		<Navigation.Back />
		<Navigation.Title>쪽지 작성</Navigation.Title>
	</Navigation>
    
    {/* 글 작성하기, 오늘의 사진 */}
    <ContentBody>
	    <TextSection>
            <Description>글 작성하기</Description>
            <TextContent />
	    </TextSection>
    	<PhotoSection>
    		<Description>오늘의 사진</Description>
		    <PhotoContent />
    	</PhotoSection>
    </ContentBody>
	
    ...
</PageContainer>

컴포넌트로 구분하고, 네이밍을 잘 활용하면 가독성을 높일 수 있습니다.

좋은 네이밍은 의미론적으로 화면의 영역을 구분할 수 있도록 하여, 추후 변경사항이 발생할 때도 빠르게 원하는 영역을 찾을 수 있도록 도와줍니다.

컴포넌트의 구성

컴포넌트는 UI (or 형태) 와 기능으로 구성되어 있습니다.

기능은 상태, 액션 등을 의미합니다.

대부분의 컴포넌트들이 이 두 가지를 포함하고 있습니다.

그런데,

어떤 컴포넌트는 기능은 동일하지만 UI가 달라질 필요가 있고,

어떤 컴포넌트는 기능과 UI가 경우에 따라 달라질 필요가 있습니다.

어떤 경우가 있는지 살펴보겠습니다.

기능은 동일하지만 UI가 달라질 필요가 있다?

공통 컴포넌트로 사용할 수 있는 버튼이 좋은 예시가 될 수 있습니다.

버튼을 다음과 같이 정의해보겠습니다.

UI : 기본적인 UI를 가지고 있고,

UI : 내부에 텍스트 또는 다른 UI를 보여줄 수 있으며,

기능 : 클릭하면 특정 함수를 실행할 수 있습니다.

interface ButtonProps extends PropsWithChildren {
    disabled?: boolean;
    variant: 'primary' | 'dashed';
	onClick?: () => void;
}

export default function Button({
    variant,
    disabled,
    children,
	onClick,
}: ButtonProps) {
    return (
        <StyledButton variant={variant} disabled={disabled} onClick={onClick}>
        	{children}
        </StyledButton>
    );
}

const StyledButton = styled.button<{
    variant: ButtonProps['variant'];
	disabled: ButtonProps['disabled'];
}>`
    border-radius: 8px;
    width: 100%;
	height: ${layouts.button};

    ${(props) =>
	    props.variant === 'primary' &&
    `
        background-color: #000;
        color: #fff;
        font-weight: 700;
	`}

    ${(props) =>
	    props.variant === 'dashed' &&
    `
        border: dashed 1px #e4e4e4;
        background-color: #fff;
        color: #555;
        font-weight: 600;
	`}

	${(props) => props.disabled && `background-color: #ddd;`}
`;

몇 가지 테마를 정의해서 개발자가 UI를 변경할 수 있도록 했습니다.

버튼 컴포넌트와 스타일 로직이 결합되어 있는 경우입니다.

버튼 내부에 텍스트 외에 다른 UI 또는 컴포넌트를 전달할 수 있는 확장성(children)을 제공합니다.

커스텀하게 스타일을 수정할 수 있도록 style Prop을 제공해도 좋을 것 같네요.

버튼 컴포넌트

또 다른 예시로 아이콘을 들 수 있습니다.

아이콘은

크기, 색깔, 클릭할 수 있다는 공통적인 특징이 있으며,

아이콘 별로 UI와 이름이 달라질 수 있습니다.

import * as Icons from '@/public/emotionIcons';

type EmotionIconProps = {
    name: keyof typeof Icons;
    width: number | string;
    height: number | string;
    fill: string | 'none';
    stroke?: string;
    onClick?: () => void;
};

export default function EmotionIcon(props: EmotionIconProps) {
    const Icon = Icons[props.name];

    return <Icon {...props} />;
}

// @/public/emotionIcons.tsx

import Default from './default.svg';
import Depressed from './depressed.svg';
import Flutter from './flutter.svg';
import Glad from './glad.svg';
import Touched from './touched.svg';

export { Default, Depressed, Flutter, Glad, Touched };

감정 아이콘 (Emotion Icon) 컴포넌트

기능과 UI가 경우에 따라 달라지는 경우 ?

대표적인 예로 팝업창을 들 수 있습니다.

팝업 내부에 텍스트를 보여줄 지, 이미지를 보여줄 지, 버튼을 하나만 보여줄 지, 버튼을 두 개 보여줄 지 등...

요구사항이 변동될 수 있는 경우가 많고, 그에 따라 기능과 UI가 달라질 수 있습니다.

다른 예시로 네비게이션 바를 들 수도 있습니다.

네비게이션 바 디자인 in 피그마

위의 디자인을 보고 네비게이션 바를 설계한다고 했을 때,

UI적으로는 1) 뒤로가기 아이콘, 2) 타이틀, 3) 완료 텍스트 가 필요해보입니다.

기능적으로는 1) 뒤로가기 아이콘 클릭, 2) 완료 텍스트 클릭 이 필요해보입니다.

type NavigationProps = {
    isBack?: boolean;
    isComplete?: boolean;
    title?: string;
    onBack?: () => void;
    onComplete?: () => void;
};

export default function Navigation({
    isBack,
    isComplete,
    title,
    onBack,
    onComplete,
}: NavigationProps) {
	const router = useRouter();

    return (
        <StyledNavigation>
            <div>
            {isBack && (
                <Icon
                    name="ArrowRight"
                    width={20}
                    height={20}
                    onClick={onBack || router.back}
                />
            )}
            </div>
            <div>{title}</div>
            <div>{isComplete && <div onClick={onComplete}>완료</div>}</div>
        </StyledNavigation>
    );
}

초기에 정의한 내용을 가지고 위와 같이 구현해보았습니다.

뒤로가기 버튼, 완료 버튼은 선택적(optional)으로 렌더링하도록 했습니다.

그런데,,, 만약에 요구사항이 추가/변경되면 어떻게 될까요?

- 뒤로가기 버튼 자리에 다른 아이콘을 넣는다던가?

- 완료 버튼 자리에 X버튼을 넣는다던가?

- 타이틀 자리에 이미지를 넣는다던가?

한번, 이 요구사항들을 적용해볼까요?

type NavigationProps = {
    isBack?: boolean;
    isComplete?: boolean;
    isClose?: boolean;
    title?: children;
    onBack?: () => void;
    onClickIcon?: () => void;
    onComplete?: () => void;
    onClose?: () => void;
};

export default function Navigation({
    isBack,
    isComplete,
    title,
    onBack,
    onClickIcon,
    onComplete,
    onClose
}: NavigationProps) {
	const router = useRouter();

    return (
        <StyledNavigation>
            <div>
            {isBack && (
                <Icon
                    name="ArrowRight"
                    width={20}
                    height={20}
                    onClick={onBack || router.back}
                />
            )}
            {isIcon && (
            	<Icon
                	name="Something"
                    width={20}
                    height={20}
                    onClick={onClickIcon}
            )/>
            </div>
            <div>{children}</div>
            <div>{isComplete && <div onClick={onComplete}>완료</div>}</div>
            <div>{isClose && (
            	<Icon
                	name="Close"
                    width={20}
                    height={20}
                    onClose={onClose}
            )}</div>
        </StyledNavigation>
    );
}

이런 식으로 구현해볼 수 있겠지만... 하나의 컴포넌트의 기능들만 늘어가고 Props는 너무 많아지고 있습니다.

이 네비게이션 바를 여러 페이지에서 사용한다고 가정해봅시다.

요구사항이 변경됨에 따라, 새로운 기능을 추가하거나 기존의 기능을 수정한다고 할 때...

네비게이션 바를 사용하는 곳의 코드도 전부 수정해야 할 수도 있습니다.

네비게이션 바와 특정 기능들이 아주 강하게 결합되어 있는 경우입니다.

적절한 추상화 작업을 통해서 이런 결합을 느슨하게 처리해줄 수 있습니다.

추상화 1 : Render Props를 이용해보자

네비게이션 바를 살펴보면, 디자인 상으로 3개의 영역으로 구분할 수 있습니다.

이 3개의 영역이란 개념을 사용하여, 각각의 영역에 컴포넌트를 주입(DI)시켜주면 어떨까요?

type NavigationProps = {
	left?: React.ReactNode;
    middle?: React.ReactNode;
    right?: React.ReactNode;
};

export default function Navigation({
	left,
    middle,
    right,
}: NavigationProps) {
    return (
        <StyledNavigation>
        	{left && left}
            {middle && middle}
            {right && right}
        </StyledNavigation>
    );
}

// 네비게이션 바를 사용하는 특정 페이지

...

const Left = <Icon name="Back width={20} height={20} onClick={handleBack}
const Middle = <div>타이틀</div>
const Right = <div onClick={handleComplete}>완료</div>


<Navigation
	left={<Left />}
    middle={<Middle />}
    right={<Right />}
/>

이렇게 컴포넌트를 설계하면, 컴포넌트를 사용하는 곳에서 UI + 기능을 정의할 수 있어서 자유도가 높아집니다.

어떤 새로운 요구사항이 들어와도, 세 가지 영역에 적절하게 컴포넌트를 주입해주면 되겠네요 !

조금 아쉬운 점은 세 가지 영역으로 제한을 했다는 것과 매번 컴포넌트를 주입해줘야 한다는 부분이 있습니다.

추상화 2 : Compound 패턴을 이용해보자

Compound 패턴은 여러 컴포넌트를 조합해서 하나의 컴포넌트를 구현하는 패턴입니다.

네비게이션 바를 뜯어보면 뒤로가기, 타이틀, 완료와 같이 몇 가지 부품으로 더 쪼갤 수 있는데,

컴포넌트를 사용하는 곳에서 사용하고 싶은 부품만 조립해서 사용하면 되는 것입니다.

Render Props 패턴을 사용하면 어떤 컴포넌트던지 주입할 수 있다는 장점이 있지만,

사용하고 싶은 컴포넌트를 매번 만들어서 주입해줘야 하는 단점이 있습니다.

Compound 패턴은 몇 가지 부품들을 만들어놓기 때문에 이런 불편함이 다소 줄어듭니다.

type NavigationProps = {
	children: React.ReactNode;
};

type BackProps = {
	onClick?: () => void;
};

type TitleProps = {
	children: React.ReactNode;
};

type CompleteProps = {
	onClick: () => void;
};

function Navigation({ children }: NavigationProps) {
	return <StyledNavigation>{children}</StyledNavigation>;
}

function Back({ onClick }: BackProps) {
	const router = useRouter();

    return (
        <StyledBack>
        <Icon
            name="ArrowRight"
            width={20}
            height={20}
            onClick={onClick || router.back}
        />
    </StyledBack>
    );
}

function Title({ children }: TitleProps) {
	return <StyledTitle>{children}</StyledTitle>;
}

function Complete({ onClick }: CompleteProps) {
	return <StyledComplete onClick={onClick}>완료</StyledComplete>;
}

export default Object.assign(Navigation, {
    Back,
    Title,
    Complete,
});

// 네비게이션 바 사용

<PageContainer css={containerCss}>
    <Navigation>
        <Navigation.Back />
        <Navigation.Title>작성한 쪽지 확인</Navigation.Title>
        <div>쪽지는 내일까지!</div>
    </Navigation>

...

</PageContainer>

위처럼 조립하고 싶은 부품만 꺼내서 사용하면 됩니다. (Navigation.Back, Navigation.Title)

또, 별도의 UI + 기능을 넣고 싶다면 Navigation 하위에 넣어주면 되는 것입니다.

무조건 추상화가 좋은 것일까요 ?

여태까지 자이언트 컴포넌트(Props가 많아지는 경우, 위의 예시로 네비게이션 바)를 뜯어고치는 추상화 작업을 거쳤습니다.

요구사항 수정이 많이 발생할 수 있는 컴포넌트에 추상화를 적용하여 효율적으로 사용함을 확인했습니다.

그렇다면, 수정이 많이 발생할 것 같은 컴포넌트에 추상화를 적용해야만 할까요?

GNB 컴포넌트

GNB 컴포넌트는

- 스타일이 변경될 소지도 있고,

- 아이콘 위치, 순서라던가,

- 아이콘 갯수도 변경될 수 있어 보이네요.

function Gnb() {
	const router = useRouter();

    const goPage = (pathname: '/home' | '/noteWrite?page=1' | '/myPage') => {
    	router.push(pathname);
};

    return (
        <StyledGnb>
            <div>
                <button onClick={() => goPage('/home')}>
	                <i className="fa-solid fa-house fa-lg" aria-label="홈" />
                </button>
            </div>
            <div>
                <button onClick={() => goPage('/noteWrite?page=1')}>
                	<i className="fa-solid fa-plus fa-lg" aria-label="쪽지작성" />
                </button>
            </div>
            <div>
                <button onClick={() => goPage('/myPage')}>
                	<i className="fa-solid fa-user fa-lg" aria-label="마이페이지" />
	            </button>
            </div>
        </StyledGnb>
    );
}

export default memo(Gnb);

const StyledGnb = styled.nav`
    background-color: #ddd;
    position: fixed;
    left: 50%;
    bottom: 0;
    transform: translateX(-50%);
    text-align: center;
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    align-items: center;
    width: 100%;
    max-width: ${layouts.deviceWidth};
    height: ${layouts.gnb};

    div > button {
        width: 50%;
        height: ${layouts.gnb};
    }
`;

코드를 살펴보면, GNB 스타일 로직과 특정 페이지 이동 기능이 GNB 버튼들과 결합이 되어 있습니다.

이런 경우라면 추후 변경사항이 일어날 때, 많은 코드를 수정하는 등의 비용이 발생할까요?

이 경우에는 그렇지 않습니다.

GNB 컴포넌트는 최상위 레이아웃 컴포넌트와 결합이 되어 있고, 이 곳 한 군데에서만 사용하고 있습니다.

변경이 발생하더라도 GNB 컴포넌트 하나만 수정하면 되기 때문에, 굳이 GNB 컴포넌트를 추상화하거나 쪼개는 작업을 할 이유가 없어 보입니다.

결론

- 컴포넌트를 만들 수 있는 경우의 수

- 컴포넌트의 구성

- 컴포넌트를 언제 추상화할 수 있는지

등을 알아봤습니다.

컴포넌트를 구현하기에 앞서, 다음과 같은 고민이 우선되어야 할 것으로 보입니다.

- 컴포넌트의 변경사항은 얼마나 발생할 지?

- 컴포넌트를 어디에서 사용하는 지?

- 컴포넌트를 얼마나 사용하는 지?

등의 몇 가지 기준을 통해, 추상화 정도를 결정하는 것이 좋은 컴포넌트 구현의 밑거름이 되지 않을까 싶습니다.

참고

카카오엔터 FE 기술블로그 : 합성 컴포넌트로 재사용성 극대화하기

단단한 컴포넌트 부수기(feat. 조합, IoC)

FECONF 2022 [B1] 디자인 시스템, 형태를 넘어서

[Web] Storybook를 시작해보자 (with Typescript, Next.js)

철스커 — Fri, 7 Jul 2023 19:43:17 +0900

Storybook 이란?

스토리북(Storybook)은 컴포넌트의 다양한 경우를 정리할 수 있도록 도와주는 시각화 도구(tool)입니다.

예를 들어, 버튼 컴포넌트가 있다고 하면 상태(데이터)에 따라서 UI나 액션이 달라질 수 있습니다.

variant 값이 primary이면 일반 버튼, dashed이면 점선이 있는 버튼으로 버튼 UI를 표현할 수 있습니다.

스토리북과 같은 도구 없이도 컴포넌트를 개발할 수 있지만, 점점 늘어나는 컴포넌트들을 한 눈에 정리하는 것은 쉽지 않습니다.

스토리북은 컴포넌트들을 시각적으로 정리할 수 있게 도와줄 뿐만 아니라, 컴포넌트의 구현 코드를 문서화해줍니다.

디자이너와 협업할 때 컴포넌트의 UI가 잘 구현되었는지 피드백을 받을 수 있으며,

다른 개발자와 협업할 때는 컴포넌트를 어떻게 구현했는지, 또 컴포넌트 사용방법을 스토리북을 통해 보여줄 수 있습니다.

스토리북은 컴포넌트 기반으로 개발하는 CDD(Component Driven Development) 방법론에서 출발한 것으로 보이며, 아토믹 디자인 패턴을 현업에서 사용하고 있다면 스토리북은 강력한 툴이 될 것 같습니다.

스토리북은 문서를 만들어 준다. (autodocs)

스토리 별로 컴포넌트 UI를 확인할 수 있다

스토리북을 통해 컴포넌트 별로 스토리 파일 (OOO.stories.tsx 또는 OOO.stories.jsx) 을 만들 수 있으며, 각 파일은 컴포넌트를 import할 수 있습니다. 컴포넌트 안에 여러 개의 스토리를 만들 수 있는데, 스토리는 일종의 시나리오라고 보시면 됩니다.

맨 위에서 설명한 버튼을 예로 들면, 버튼은 variant 값에 따라서 primary 버튼이 될 수도 있고, dashed 버튼이 될 수도 있습니다.

이 버튼 컴포넌트에 대해 2가지 스토리로 만들 수 있는 것입니다. (primary, dashed)

Storybook 설치하기

* Next.js, React, TypeScript 환경에서 설치를 진행했습니다.

// npx
npx storybook@latest init

// 또는 pnpm
pnpm dlx storybook@latest init

pnpm dlx storybook@latest init

../Library/pnpm/store/v3/tmp/dlx-94005   | +702 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
../Library/pnpm/store/v3/tmp/dlx-94005   | Progress: resolved 662, reused 610, downloaded 31, added 702, done

 storybook init - the simplest way to add a Storybook to your project. 

 • Detecting project type. ✓
 • Adding Storybook support to your "Next" app
  ✔ Getting the correct version of 8 packages
✔ We have detected that you're using ESLint. Storybook provides a plugin that gives the best experience with Storybook and helps follow best practices: https://github.com/storybookjs/eslint-plugin-storybook#readme

Would you like to install it? … yes
    Configuring Storybook ESLint plugin at .eslintrc.json
  ✔ Installing Storybook dependencies
. ✓
 • Preparing to install dependencies. ✓
 
 ...

스토리북 설치를 진행하면, 알아서 프로젝트의 프레임워크를 감지합니다.

저는 Next.js 환경에서 설치를 진행했는데요.

프레임워크 환경에 맞게 의존성 모듈들을 설치되었고, 설정 파일도 생성이 되었습니다.

// package.json
{
    "name": "story-test",
    "version": "0.1.0",
    "private": true,
    "scripts": {
        "dev": "next dev",
        "build": "next build",
        "start": "next start",
        "lint": "next lint",
        "storybook": "storybook dev -p 6006",
        "build-storybook": "storybook build"
    },
	"dependencies": {
        "@types/node": "20.4.0",
        "@types/react": "18.2.14",
        "@types/react-dom": "18.2.6",
        "eslint": "8.44.0",
        "eslint-config-next": "13.4.9",
        "next": "13.4.9",
        "react": "18.2.0",
        "react-dom": "18.2.0",
        "typescript": "5.1.6"
    },
    "devDependencies": {
        "@storybook/addon-essentials": "^7.0.26",
        "@storybook/addon-interactions": "^7.0.26",
        "@storybook/addon-links": "^7.0.26",
        "@storybook/blocks": "^7.0.26",
        "@storybook/nextjs": "^7.0.26",
        "@storybook/react": "^7.0.26",
        "@storybook/testing-library": "^0.0.14-next.2",
        "eslint-plugin-storybook": "^0.6.12",
        "storybook": "^7.0.26"
    }
}

scripts에 storybook과 build-storybook 스크립트가 추가된 것을 확인할 수 있습니다.

각 스크립트는 스토리북을 로컬서버로 실행시키거나 스토리북을 빌드(원격 서버에 배포하기 위해)해주는 역할을 합니다.

main.ts 파일과 preview.ts 파일

스토리북 설치를 완료하면, .storybook 폴더 하위에 .main.ts와 .preview.ts 파일이 생성됩니다.

// .storybook/main.ts

import type { StorybookConfig } from "@storybook/nextjs";

const config: StorybookConfig = {
    // 스토리북에 사용할 .mdx, .stories 파일의 위치
    stories: ["../stories/**/*.mdx", "../stories/**/*.stories.@(js|jsx|ts|tsx)"],
    // 적용할 addon
    addons: [
        "@storybook/addon-links",
        "@storybook/addon-essentials",
        "@storybook/addon-interactions",
    ],
    // 프레임워크 종류
    framework: {
        name: "@storybook/nextjs",
        options: {},
    },
    // docs 관련
    docs: {
	    autodocs: "tag",
    },
};

export default config;

.main.ts 파일에서 스토리북에 대한 전반적인 설정을 할 수 있습니다.

The main configuration defines a Storybook project's behavior, including the location of stories, addons to use, feature flags, and other project-specific settings.

// .storybook/preview.ts

import type { Preview } from "@storybook/react";

const preview: Preview = {
	// parameters는 스토리에 대한 메타데이터 정보들, 주로 스토리북 feature와 addon에 대한 설정
    parameters: {
        actions: { argTypesRegex: "^on[A-Z].*" },
        controls: {
            matchers: {
                color: /(background|color)$/i,
                date: /Date$/,
            },
        },
    },
};

export default preview;

preview.ts는 preview (미리보기) 화면에 대한 설정을 적용할 수 있습니다.

Parameters are a set of static, named metadata about a story, typically used to control the behavior of Storybook features and addons. (Parameters에 대한 설명)

미리보기(Preview)는 컴포넌트 (스토리)를 미리 보여주는 영역이라고 할 수 있는데요.

preview.ts를 통해 UI가 어떻게 렌더링될 것인지 설정할 수 있습니다.

preview.ts 내부에 CSS를 import하거나 Javascript를 로드할 수도 있는데요.

normalize.css같은 CSS를 import하면 브라우저 별로 조금씩 다른 CSS를 정리해볼 수 있을 것 같습니다. (크로스 브라우징)

This is loaded in the Canvas UI, the “preview” iframe that renders your components in isolation. Use preview.js for global code (such as CSS imports or JavaScript mocks) that applies to all stories.

Storybook 기본 사용법

* CSF3 (Component Story Format 3), V7.0.26 기준으로 글을 작성하였습니다.

// Button.tsx
interface ButtonProps extends PropsWithChildren {
    disabled?: boolean;
    variant: 'primary' | 'dashed';
    onClick?: () => void;
}

export default function Button({
    variant,
    disabled,
    children,
    onClick,
}: ButtonProps) {
    return (
            <StyledButton variant={variant} disabled={disabled} onClick={onClick}>
            {children}
        </StyledButton>
    );
}

버튼(Button) 컴포넌트를 이용해서 스토리 파일을 만들어보겠습니다.

버튼 컴포넌트는 위와 같은 코드로 구현했습니다.

// Button.stories.tsx

import type { Meta, StoryObj } from '@storybook/react';

import Button from './index';

// 메타 데이터, 제네릭에 Button 컴포넌트의 타입을 넘겨준다.
const meta: Meta<typeof Button> = {
	// 사이드바에 표시할 카테고리
    title: 'Components/Common/Button',
	// 컴포넌트
    component: Button,
	// 컴포넌트에 대한 문서를 자동으로 생성
	tags: ['autodocs'],
    argTypes: {},
};

// 메타 데이터를 디폴트로 export
export default meta;

// 스토리 타입, StoryObj의 제네릭에 컴포넌트의 타입을 넘겨준다.
type Story = StoryObj<typeof Button>;

// 하나의 스토리, 스토리는 named export 해준다
// 스토리 이름도 사이드바 카테고리에 표시된다
export const Primary: Story = {
	// 컴포넌트에 필요한 arguments, 리액트 컴포넌트에게는 Props
    args: {
	    variant: 'primary',
    	children: 'Primary',
	},
};

// 또 하나의 스토리 (Dashed)
export const Dashed: Story = {
    args: {
        variant: 'dashed',
        children: 'Dashed',
    },
};


// Primary 스토리의 args값을 재사용했다.
export const Disabled: Story = {
	args: {
		...Primary.args,
		children: 'Disabled',
        disabled: true,
    },
};

버튼에 대한 스토리 파일(OOO.stories.tsx</code>)을 작성합니다.

스토리북을 실행해줍니다. (npm run storybook 또는 pnpm storybook)

기본적인 설정으로는 6006포트에 스토리북이 실행이 됩니다.

스토리북 화면에 버튼 컴포넌트에 대한 스토리 화면들이 렌더링됩니다.

메타 데이터의 title에 title: 'Components/Common/Button' 과 같이 전달해주었는데요.

/로 카테고리를 구분합니다.

Components가 최상위 카테고리, Commpon이 다음 카테고리, Button이 그 다음 카테고리로 표시됩니다.

Decorators

컴포넌트에 대한 스토리를 렌더링했지만, 경우에 따라서 스토리를 감싸는 UI 또는 레퍼 컴포넌트가 필요할 수 있습니다.

이런 경우에는, decorators를 사용하면 됩니다.

어떤 스토리는 Redux나 Recoil 같은 상태 관리 라이브러리의 API를 사용할 수 있습니다.

이런 경우, 해당 스토리에 Provider를 전달해줘야 하는데요.

decorators를 이용할 수 있습니다.

// Button.stories.tsx

...

// Primary 스토리
export const Primary: Story = {
    args: {
        variant: 'primary',
        children: 'Primary',
    },
    decorators: [(story) => <div style={{ padding: 100 }}>{story()}</div>],
};

위와 같이 decorators에 배열을 전달해주고, 배열 안에 JSX를 리턴하는 함수를 넣어주면 되는데요.

이 함수는 story를 argument로 받습니다.

story를 레퍼 컴포넌트 (or JSX) 내부에서 호출해주면 됩니다. (story( ) )

Global Level, Component Level, Story Level

스토리북은 세 단계로 특정 옵션을 제공할 수 있습니다.

Global Level은 전역적인 범위

Component Level은 컴포넌트 범위

Story Level은 스토리 범위 를 의미합니다.

위에서 적용했던 decorators를 세 단계에 적용할 수 있는데요.

// .storybook/preview.ts
import type { Preview } from '@storybook/react';

const preview: Preview = {
	decorators: [(story) => <div style={{ padding: 100 }}>{story()}</div>],
};

export default preview;

Global Level에 적용하려면 preview.ts에 옵션을 적용하면 됩니다.

위와 같이 적용하면 패딩값이 100인 div 태그가 모든 스토리를 감쌀 것입니다.

// Button.stories.tsx

...

const meta: Meta<typeof Button> = {
    title: 'Components/Common/Button',
    component: Button,
    tags: ['autodocs'],
    argTypes: {},
    decorators: [(story) => <div style={{ padding: 100 }}>{story()}</div>],
};

export default meta;

type Story = StoryObj<typeof Button>;

// Primary 스토리
export const Primary: Story = {
    args: {
        variant: 'primary',
        children: 'Primary',
    }
};

Component Level에 적용하려면 Meta 정보에 옵션을 적용하면 됩니다.

위와 같이 적용하면 패딩값이 100인 div 태그가 컴포넌트 단위의 모든 스토리를 감쌀 것입니다.

// Button.stories.tsx

...

// Primary 스토리
export const Primary: Story = {
    args: {
        variant: 'primary',
        children: 'Primary',
    },
    decorators: [(story) => <div style={{ padding: 100 }}>{story()}</div>],
};

Story Level에 적용하려면 Story에만 옵션을 적용하면 됩니다.

위와 같이 적용하면 패딩값이 100인 div 태그가 스토리만 감쌀 것입니다.

참고

스토리북 공식문서 - 튜토리얼 문서

스토리북 공식문서 - Configure story rendering (preview)

스토리북 공식문서 - Main configuration

[개발이슈] Storybook에서 SVG 이슈 발생 (Element type is invalid ... )

철스커 — Thu, 6 Jul 2023 12:37:56 +0900

이슈 발생

Storybook에서 SVG 아이콘을 사용하는 컴포넌트로 스토리를 만들고 있었는데요.

갑자기 위와 같은 오류가 발생했습니다.

Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.

구글링도 해보고, Github Issue를 여러 개 살펴본 뒤에 file-loader 관련 이슈라는 것을 알게 되었습니다.

Storybook은 Webpack을 사용하고 있고 기본적으로 file-loader가 사용되고 있는데, SVG 파일을 import하는 과정에서 file-loader가 객체 형태로 변환한 것으로 보입니다.

File-loader란?

출처 : https://v4.webpack.js.org/loaders/file-loader/

file-loader는 특정 모듈을 출력(Output) 디렉토리로 복사(Emit)해주는 로더입니다.

Webpack에서 사용하는 로더란?

출처 : https://webpack.kr/concepts/loaders/

SVG 파일은 import 아이콘_컴포넌트 from '아이콘.svg' 형태로 컴포넌트에서 사용되고 있는데요.

Webpack이 SVG 파일을 해석(resolve)할 때, file-loader가 이 파일을 객체 형태로 변환한 것입니다.

원하는 동작은 SVG 파일을 리액트 컴포넌트로 변환하는 것입니다.

에러 해결하기 - Webpack module 설정을 변경

Webpack 설정에는 module이라는 항목이 존재합니다.

여기에서 모듈 유형에 따라 어떤 작업을 할 것 인지 (어떤 로더를 사용할 것 인지) 설정해줄 수 있습니다.

출처 : https://webpack.kr/concepts/loaders/

@svgr/webpack은 SVG 파일을 import 할 때, 리액트 컴포넌트로 변환해줍니다.

Storybook에 적용된 Webpack의 모듈 설정을 아래와 같이 변경해주면 됩니다.

// .storybook/main.ts

import type { StorybookConfig } from '@storybook/nextjs';

const config: StorybookConfig = {
  stories: ['../components/**/*.stories.@(js|jsx|ts|tsx)'],
  addons: [
    '@storybook/addon-links',
    '@storybook/addon-essentials',
    '@storybook/addon-interactions',
    '@storybook/addon-a11y'
  ],
  framework: {
    name: '@storybook/nextjs',
    options: {},
  },
  docs: {
    autodocs: 'tag',
  },
  // webpackFinal을 통해 Webpack 설정을 변경
  webpackFinal: async (config) => {
    if (!config.module || !config.module.rules) {
      return config;
    }

    config.module.rules = [
      ...config.module.rules.map((rule) => {
        if (!rule || rule === '...') {
          return rule;
        }

        if (rule.test && /svg/.test(String(rule.test))) {
          return { ...rule, exclude: /\.svg$/i };
        }
        return rule;
      }),
      {
        test: /\.svg$/,
        use: ['@svgr/webpack']
      }
    ]
    
    return config;
  }
};
export default config;

module의 rules 배열을 순회하면서 rule.test가 svg를 포함하고 있으면, 해당 rule의 exclude에 /\.svg$/i를 적용합니다.

즉, file-loader가 svg 모듈을 무시하도록 합니다.

그 후에 svg 모듈을 @svgr/webpack이 처리하도록 새로운 rule을 넣어줍니다.

이슈 해결 완료

Storybook을 다시 실행시키면 정상적으로 SVG 파일을 컴포넌트 안에 불러올 수 있습니다.

참고

Storybook Github 이슈

Webpack 공식문서 - Loader

Webpack v4 공식문서 - file-loader

@svgr/webpack - npm

svgr - Github

[React] 리액트 컴포넌트 최적화해보기 (with. useCallback, React.memo)

철스커 — Thu, 22 Jun 2023 15:20:23 +0900

간단한 웹 페이지 기능 소개

쇼핑몰 기능 중 하나인 장바구니 기능을 구현한 웹 페이지입니다.

장바구니에 등록된 상품 중에서 결제할 상품을 선택하고, 상품 갯수에 따라 최종 금액을 유저에게 보여줍니다.

리액트 컴포넌트 설명

컴포넌트 2개가 있습니다.

1. 상품 컴포넌트 : 장바구니 상품 정보를 보여주는 컴포넌트

2. 상품 리스트 컴포넌트 : 상품 컴포넌트들을 보여주고, 필요한 비즈니스 로직을 제공합니다.

2번 컴포넌트는 컨테이너 - 프레젠테이션 패턴의 컨테이너라고도 볼 수 있을 텐데요.

컨테이너를 별도로 구별하려면, ~ 컨테이너라는 코드컨벤션이 생기고 별도의 디렉토리 폴더를 관리해줘야 하는데

개인적인 생각으로는 코드의 양이 늘어나고, 비즈니스 로직을 가지고 있는 컴포넌트들을 컨테이너로 엄격하게 구분하기 어렵다는 생각을 가지고 있습니다.

위의 이유로 비즈니스 로직의 유무에 상관없이 컴포넌트들을 한 곳에 정리하고 있습니다.

하단의 결제 금액을 보여주는 UI는 설명에서 제외하겠습니다.

1. 상품 컴포넌트 (CartProductItem)

function CartProductItem({
	productItem,
	onIncrease,
	onDecrease,
	onCheck,
}: CartProductItemProps) {
const { detailImageUrl, itemName, price, count, itemNo, isPurchase } = productItem;

	return (
        <StyledCartProductItem>
            <CartProductImage>
                <img src={detailImageUrl} alt={itemName} />
            </CartProductImage>
            <CartProductInfo>
                <div>{itemName}</div>
                <div>{price.toLocaleString()}원</div>
                <div>
                    <button onClick={() => onIncrease(productItem)}>+</button>
                    <span>{count}</span>
                    <button onClick={() => onDecrease(productItem)}>-</button>
                </div>
                <div>
                    <input
                        id={`purchase-${itemNo}`}
                        type="checkbox"
                        checked={isPurchase}
                        onChange={() => onCheck(productItem)}
                    />
                    <label htmlFor={`purchase-${itemNo}`}>결제할 상품에 포함하기</label>
                </div>
            </CartProductInfo>
        </StyledCartProductItem>
	);
}

상품 컴포넌트는 상품 데이터와 핸들러 함수들을 전달받습니다.

UI에서는 위와 같습니다.

2. 상품 리스트 컴포넌트 (CartProductItems)

export default function CartProductItems() {
	const { cartProductItems, handleIncrease, handleDecrease, handleCheck } = useCartProductItems();

    return (
        <StyledCartProductItems>
            {cartProductItems.map((productItem) => (
                <CartProductItem
                    key={productItem.itemNo}
                    productItem={productItem}
                    onIncrease={handleIncrease}
                    onDecrease={handleDecrease}
                    onCheck={handleCheck}
                />
            ))}
        </StyledCartProductItems>
    );
}

상품 리스트 데이터를 받아서 상품 컴포넌트들을 렌더링해줍니다.

상품수량 조정, 결제상품에 포함(handleCheck) 하는 비즈니스 로직도 제공합니다.

문제 발생 - 리렌더링이 될 필요 없는 상품 컴포넌트가 리렌더링된다.

리액트 최적화는 리렌더링과 관련이 있습니다.

State나 Props가 변경되면 리액트 컴포넌트는 리렌더링을 합니다.

리액트 컴포넌트는 주로 함수로 구현을 하는데 내부의 변수, 함수 등이 다시 실행되는 것입니다.

리액트 DevTools를 이용하면 리렌더링이 얼마나 자주 일어나는 지 육안으로 확인할 수 있습니다.

상품수량을 수정하거나, 결제상품에 포함/취소할 때 상품리스트 데이터를 수정해야 합니다.

상품리스트 데이터는 State로 구현이 되어 있고, 상품리스트 컴포넌트에서 구독하고 있는데요.

State가 바뀌면 상품리스트 컴포넌트가 리렌더링됩니다.

그러면, 상품리스트 내부의 비즈니스 로직 (데이터, 핸들러 함수) 들도 재생성됩니다.

상품 컴포넌트의 Props로 전달하는 데이터, 핸들러 함수들이 바뀌기 때문에, 상품 컴포넌트가 리렌더링되는 것입니다.

문제는 리렌더링될 필요가 없는 상품 컴포넌트들도 다시 리렌더링된다는 점입니다.

특정 상품의 정보가 바뀌면 해당 상품만 리렌더링이 발생하면 되는데, 다른 상품들도 리렌더링되고 있습니다.

첫번째 상품수량을 증가시키면, 첫번째 상품만 리렌더링되면 되는데, 두번째, 세번째 상품도 리렌더링 된다는 것이죠.

1. React.memo 적용하기

memo를 적용하면 props가 변경이 되지 않는 이상, 예전에 렌더링된 컴포넌트(메모이제이션된 컴포넌트)가 반환됩니다.

불필요한 리렌더링을 막을 수 있습니다.

memo에서는 이전 props와 현재 props를 비교하는 데요.

기본적으로 리액트에서 제공하는 shallowEqual 함수를 사용합니다.

shallowEqual 함수는 두 props가 원시 타입일 때, 값이 같으면 true를 반환하고

두 props가 객체일 때는 한 depth의 동일한 key-value를 가지고 있으면 true를 반환합니다.

그 밖의 경우에는 모두 false를 처리합니다.

const valA = 10;
const valB = 10;

const objA = { a: 1, b: 2 };
const objB = { a: 1, b: 2 };

const objC = { a: 1, b: { c: 2 } };
const objD = { a: 1, b: { c: 2 } };

// test
shallowEqual(valA, valB) // true
shallowEqual(objA, objB) // true
shallowEqual(objC, objD) // false

// 상품 컴포넌트 (CartProductItem)

...


export default React.memo(CartProductItem)

위와 같이 memo를 적용하면 되는데요.

현재로써는 이 상태를 적용해도, 상품정보가 바뀌지 않은 상품 컴포넌트들이 아직도 리렌더링되는 문제가 발생합니다.

상품 컴포넌트는 props로 productItem, onIncrease, onDecrease, onCheck 를 전달받고 있는데요.

productItem은 객체 타입을 가지고 있고, 나머지는 함수 타입입니다.

shallowEqual 함수는 함수의 내부 로직이 같아도 함수의 레퍼런스가 다르면 false 처리를 처리하기 때문입니다.

2. useCallback 적용하기

// 상품리스트 컴포넌트
export default function CartProductItems() {
	const { cartProductItems, handleIncrease, handleDecrease, handleCheck } = useCartProductItems();

    return (
        <StyledCartProductItems>
            {cartProductItems.map((productItem) => (
                <CartProductItem
                    key={productItem.itemNo}
                    productItem={productItem}
                    onIncrease={handleIncrease}
                    onDecrease={handleDecrease}
                    onCheck={handleCheck}
                />
            ))}
        </StyledCartProductItems>
    );
}

상품리스트 State (cartProductItems)가 업데이트 되더라도 핸들러 함수는 동일한 함수, 즉 메모리에서 같은 레퍼런스를 가리키고 있어야 합니다.

useCallback을 사용하면 메모이제이션된 함수를 유지할 수 있습니다.

// useCartProductItems hook 내부

const handleIncrease = useCallback((productItem) => {
	... 로직
}, [])

const handleDecrease = useCallback((productItem) => {
	... 로직
}, []);

const handleCheck = useCallback((productItem) => {
	... 로직
}, []);

최적화 적용 후, 결과

상품 정보가 바뀌는 상품만 렌더링되는 것을 확인할 수 있습니다..!!

참고

React.memo() 현명하게 사용하기

React.dev (memo)

React Github : shallowEqual

Object.is (MDN 문서)

[Web] Git 원격저장소의 브랜치 추적하기

철스커 — Wed, 24 May 2023 16:38:15 +0900

Github이나 Gitlab 등의 원격저장소에 git push 하거나 git fetch or git pull하는 경우가 많습니다.
그런데 로컬저장소의 브랜치가 원격저장소의 브랜치를 추적하지 않으면 위의 명령어를 사용할 수 없습니다.

git push 원격저장소명 브랜치명 형태로 사용해야 합니다.

조금 귀찮을 수도 있습니다.

그래서 로컬 브랜치가 원격저장소 브랜치를 추적할 수 있는 방법을 찾아보았습니다.
편의상 로컬저장소의 브랜치를 로컬 브랜치, 원격저장소의 브랜치를 원격 브랜치로 부르겠습니다.

git clone 시

git clone을 이용하면 main브랜치는 자동으로 원격저장소의 main브랜치를 추적합니다.

원격 브랜치를 추적하는 로컬 브랜치를 생성할 경우

git fetch를 통해서 원격 브랜치를 가져왔다면, git checkout 명령어를 통해서 원격 브랜치를 추적하는 로컬 브랜치를 만들 수 있습니다.

1. git checkout -b 브랜치명 원격저장소명/브랜치명
위의 명령어는 로컬 브랜치이름을 원격 브랜치이름과 다르게 지정할 수 있습니다.

<이름을 다르게 지정한 경우>

git checkout -b chore origin/feature/chore

branch 'chore' set up to track 'origin/feature/chore'.
Switched to a new branch 'chore'

<이름을 같게 지정한 경우>

git checkout -b feature/chore origin/feature/chore

branch 'feature/chore' set up to track 'origin/feature/chore'.
Switched to a new branch 'feature/chore'

2. git checkout --track 원격저장소명/브랜치명
--track을 이용하면 자동으로 원격 브랜치이름과 동일한 이름의 로컬 브랜치가 생성됩니다.

git checkout --track origin/feature/chore 

branch 'feature/chore' set up to track 'origin/feature/chore'.
Switched to a new branch 'feature/chore'

3. git branch -u 원격저장소명/브랜치명
위의 1,2번은 브랜치를 새로 생성하는 상황이었는데요.

이미 존재하는 브랜치에 원격 브랜치를 추적할 수도 있습니다.

git branch -u origin/feature/chore
branch 'feature/chore' set up to track 'origin/feature/chore'.

추적브랜치 확인

git branch -vv를 사용하면 로컬 브랜치들이 추적하는 원격 브랜치를 알 수 있습니다.
대괄호([ ])에 원격 브랜치가 표시됩니다.

참고

3.5 Git 브랜치 - 리모트 브랜치

[알고리즘] BFS (너비우선탐색) 구현해보기 (feat. TypeScript)

철스커 — Mon, 8 May 2023 15:59:55 +0900

BFS에 대한 소개

BFS는 Breadh-First-Search의 약자로 너비우선탐색이라고 합니다.

그래프가 주어졌을 때, 노드(Vertex)를 가까운 노드부터 탐색하는 알고리즘입니다.

BFS 알고리즘을 구현할 때는 큐와 배열을 사용합니다.

큐는 현재 노드로부터 인접한 노드들을 담아주는 역할을 해줍니다.

배열은 현재 노드를 방문했는지 체크하는 역할로 사용됩니다.

가까운 노드(인접 노드)부터 탐색하기 때문에 A노드에서 B노드까지의 최단거리를 구할 수 있습니다.

DFS 알고리즘과 마찬가지로

그래프, 현재노드, 방문여부 정보를 넘겨줌으로써 알고리즘을 구현할 수 있습니다.

알고리즘

1. 시작 노드를 큐에 삽입합니다.

2. 방문하지 않았다면 방문했다고 체크합니다.

3. 큐에서 노드를 제거한 후, 해당 노드의 모든 인접 노드 중에서 방문하지 않은 노드들을 큐에 삽입하고 방문체크를 합니다.

4. 큐가 비어질 때까지 3을 반복합니다.

시간 복잡도

O(V+E)

노드 갯수 + 인접노드(간선 갯수)만큼 시간 복잡도가 발생합니다.

BFS 알고리즘을 하나씩 실행한 모습

012345678

BFS 구현 코드 (with TypeScript)

{
  function bfs(graph: number[][], v: number, visited) {
    const queue = [v];
    visited[v] = true;

    while (queue.length) {
      const v = queue.shift();
      console.log(v);

      for (const i of graph[v]) {
        if (!visited[i]) {
          queue.push(i);
          visited[i] = true;
        }
      }
    }
  }

  const graph = [[], [2, 3, 4], [1, 5], [1, 6, 7], [1], [2], [3, 7], [3, 6]];
  const visited = new Array(graph.length).fill(false);

  // 시작 노드를 4부터 시작
  bfs(graph, 4, visited);
}

출력결과

4 -> 1 -> 2 -> 3 -> 5 -> 6 -> 7

BFS 알고리즘을 하나씩 실행한 모습 (최단거리 표시)

01234567

BFS 구현 코드 (최단거리)

{
  function bfs_shortest_path(
    graph: number[][],
    v: number,
    visited,
    pathLengths: number[]
  ) {
    const queue = [v];
    visited[v] = true;

    while (queue.length) {
      const v = queue.shift();
      // console.log(v);

      for (const i of graph[v]) {
        if (!visited[i]) {
          queue.push(i);
          visited[i] = true;
          pathLengths[i] = pathLengths[v] + 1;
        }
      }
    }
  }

  const graph = [[], [2, 3, 4], [1, 5], [1, 6, 7], [1], [2], [3, 7], [3, 6]];
  const visited = new Array(graph.length).fill(false);
  const pathLengths = new Array(graph.length).fill(0);

  bfs_shortest_path(graph, 4, visited, pathLengths);
  
  // 4번 노드로부터의 최단거리 출력
  console.log(pathLengths);
}

출력결과

[ 0, 1, 2, 2, 0, 3, 3, 3 ]

[알고리즘] DFS (깊이우선탐색) 구현해보기 (feat. TypeScript)

철스커 — Mon, 8 May 2023 13:36:20 +0900

DFS에 대한 소개

DFS는 Depth-First-Search의 약자로, 깊이우선탐색이라고 합니다.

그래프가 주어졌을 때, 노드(또는 정점, Vertex)를 되도록 깊이 탐색하는 알고리즘입니다.

DFS 알고리즘을 구현할 때, 스택과 배열을 사용합니다.

재귀함수로 구현하게 되면 재귀함수 자체가 스택 역할을 담당해줍니다.

배열은 노드를 방문했는지를 체크합니다. 노드의 갯수만큼의 크기를 가지고 있습니다.

DFS 알고리즘 함수에 다음의 정보를 넘겨줌으로써, 그래프 탐색이 시작됩니다.

1. 2차원 배열로 노드와 간선(Edge)을 구현한 그래프

2. 탐색할 노드 번호

3. 방문 여부를 체크할 배열

알고리즘

1. 노드를 스택에 삽입한다.

2. 방문하지 않았으면 방문했다고 표시한다.

3. 해당 노드의 인접 노드를 탐색한다. 방문하지 않은 노드이면, 1번과 2번을 실행한다.

4. 현재 노드의 인접 노드를 모두 방문했으면, 스택에서 제거(Pop)한다.

5. 모든 노드를 탐색하게 되면 스택이 빈 상태가 되고, 알고리즘이 종료된다.

시간 복잡도

O(V+E)

노드(V, Vertex)와 간선(E, Edge)의 크기만큼 시간복잡도가 발생합니다.

모든 노드(V)를 방문하고, 인접노드(E 만큼의 크기)를 방문하기 때문입니다.

DFS 알고리즘을 하나씩 실행한 모습

01234567891011121314

DFS 구현 코드 (with TypeScript)

function dfs(graph: number[][], v: number, visited: boolean[]) {
  visited[v] = true;

  console.log(v, " ");

  for (const i of graph[v]) {
    if (!visited[i]) {
      dfs(graph, i, visited);
    }
  }
}

// 그래프
const graph = [[], [2, 3, 4], [1, 5], [1, 6, 7], [1], [2], [3, 7], [3, 6]];

// 방문체크
const visited = new Array(graph.length).fill(false);

dfs(graph, 1, visited);

출력결과

1 -> 2 -> 5 -> 3 -> 6 -> 7 -> 4 순서로 노드를 방문

[Web] Gitlab-runner 명령어 몇 가지 정리해보기

철스커 — Sat, 29 Apr 2023 12:45:15 +0900

Gitlab-runner를 CI/CD를 위해서 사용하는 데, 종종 다시 설치하거나 특정 명령을 실행시켜줘야 하는 경우가 있었습니다.

그래서 사용하는 명령어를 정리해줄 필요를 느꼈습니다.

gitlab-runner

- list

List all configured runners

Runner 목록 보여주기

- run

run multi runner service

여러 개의 Runner를 실행

- register

새로운 Runner를 등록

- install

install service

Runner 서비스를 설치

명령어 이름이 install 이어서 조금 헷갈릴 수 있는데, service를 설치해주는 명령어입니다.

gitlab-runner를 설치하는 것과는 별개라고 보시면 됩니다.

명령어에 --user=계정이름, --working-directory=Git 소스코드 저장할 폴더 ... 등의 파라미터를 전달할 수 있습니다.

- uninstall

uninstall service

Runner 서비스를 제거

- start

start service

Runner 서비스를 시작

- stop

stop service

Runner 서비스를 중지

- verify

verify all registered runners

등록된 Runner들을 검증

Gitlab에 Runner를 등록했음에도 Runner가 비활성일 때, 이 명령어를 통해 Runner를 활성화시킬 수 있습니다.

만약 Gitlab CI에 Runner가 삭제되었거나 Runner가 정상적이지 않은 상태이면, 파라미터에 --delete를 전달해서 Runner 서비스에 등록된 Runner를 목록에서 제거할 수 있습니다.

[Web] Gitlab-runner 설치 & Runner 등록하기 (Amazon Linux 2 - Centos 계열)

철스커 — Fri, 28 Apr 2023 16:49:00 +0900

Gitlab CI 를 이용하기 위해서는 gitlab-runner를 설치해줘야 합니다.

리눅스 종류가 다양하지만, 여기서는 Amazon Linux 2 (Centos) 에 대한 설치를 진행해보도록 하겠습니다.

AWS Linux 2에 Gitlab-runner 설치하기

1. AWS 서버에 접속합니다.

2. 다음 명령어를 이용해서 패키지 매니저(yum)에 Gitlab 저장소 위치를 저장시킵니다.

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash

3. yum 을 이용해서 gitlab-runner를 설치합니다.

sudo yum install gitlab-runner

* 설치하겠냐고 물어볼텐데, y를 누르시면 됩니다.

4. gitlab-runner 설치가 되었다면, /usr/bin에 gitlab-runner 가 생성되었을 겁니다.

* 참고 - Gitlab docs : Gitlab Runner install

Install GitLab Runner using the official GitLab repositories | GitLab

Documentation for GitLab Community Edition, GitLab Enterprise Edition, Omnibus GitLab, and GitLab Runner.

docs.gitlab.com

Runner 등록하기

Gitlab에서 제공하는 Runner는 세 가지 종류가 있습니다.

- Shared Runner : 누구나 사용할 수 있는 Runner

- Group Runner : 그룹 내에서만 사용할 수 있는 Runner

- Project Runner : 프로젝트 내에서만 사용할 수 있는 Runner

여기서는 Project Runner를 등록해보도록 하겠습니다.

1. 프로젝트 Settings > CI/CD 페이지로 들어오셔서, Runners 항목을 펼쳐줍니다.

Project runners, Shared runners 가 보이고, 오른쪽 하단에는 Group runners 섹션이 보이실 겁니다.

Project runners 섹션을 보시면, registration token이 있습니다.

이것을 잘 기억해두세요.

2. Show runner installation instructions 버튼 클릭

Show runner installation instructions 버튼을 클릭해보세요.

그럼, Gitlab-runner 설치와 Runner 등록 방법이 나오는데요.

이미 Gitlab-runner 설치를 했기 때문에 curl 명령어를 실행하실 필요는 없습니다.

저희는 yum을 이용해서 설치했기 때문에 /usr/bin에 gitlab-runner가 설치가 된 상태입니다.

설치 외에 저 메뉴얼대로 Runner를 등록해보겠습니다.

3. 실행할 수 있는 권한을 gitlab-runner에 부여합니다.

sudo chmod +x /usr/bin/gitlab-runner

4. gitlab-runner 계정을 추가해줍니다.

sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

5. gitlab-runner 서비스를 설치해줍니다.

sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner

--user : 사용자 계정

--working-directory : git clone할 디렉토리 위치

* 참고 : gitlab-runner install 명령어에 넘겨줄 옵션

GitLab Runner commands | GitLab

Documentation for GitLab Community Edition, GitLab Enterprise Edition, Omnibus GitLab, and GitLab Runner.

docs.gitlab.com

저는 메뉴얼에 소개된 명령어와 다르게, 사용자 계정을 root로 디렉토리 위치도 다른 곳으로 변경해서 적용해보겠습니다.

sudo gitlab-runner install --user=root --working-directory=/home/ec2-user

install 명령어 후에는 gitlab-runner 서비스를 실행시켜야 합니다.

sudo gitlab-runner start

그러면, gitlab-runner 서비스가 등록이 되었습니다.

gitlab-runner list 명령어를 입력하면 아직 등록된 Runner는 안 보입니다.

6. Runner를 등록해줍니다.

sudo gitlab-runner register

명령어를 실행하면, 차례대로 token, description, tags, note, executor 를 입력해주어야 합니다.

registration token은 아까 기억해둔 token값을 넣어주시고,

description은 Runner를 설명할 문구, tag는 .yml 파일에서 tag 옵션에 사용할 문구입니다.

executor는 어떤 환경에서 Runner를 실행할 것인지를 의미합니다. 저는 shell에서 사용할 것이기에 shell을 입력해주었습니다.

Runner가 잘 등록되었다면, gitlab-runner list 명령어 후 목록에 나타날 것입니다.

Gitlab CI/CD 설정 페이지에서도 Runner가 보입니다.

만약, Runner가 정상적이지 않다면 빨간 동그라미 또는 느낌표 등의 아이콘이 보일 겁니다.

그럴 경우에는 gitlab-runner verify를 통해서 아직 제대로 활성화되지 않은 Runner를 활성화시킬 수도 있습니다.

이것으로 gitlab-runner 설치 & Runner 등록 (Project Runner) 을 마치도록 하겠습니다.

[프로그래머스] Lv. 2 문제해결 현황

철스커 — Sat, 8 Apr 2023 12:53:55 +0900

Lv. 2 해결한 문제

(2023.04.08 기준) 총 27문제

문제 해결한 날짜 | 문제 이름

(2023.04.08) 다음 큰 숫자

(2023.04.06) [3차] n진수 게임

(2023.04.05) k진수에서 소수 개수 구하기

(2023.04.04) [3차] 압축

(2023.03.17) [1차] 뉴스 클러스터링 해결

k진수에서 소수 개수 구하기

k진수에서 소수 개수 구하기

문제해결 아이디어 정리 (노션)

https://www.notion.so/Lv-2-717c25051fcb4c2c97a3ca06856dc6c8?pvs=4

Github 링크

https://github.com/CheolWoongChoi/Algorithms/tree/main/programmers/Lv2

[Next.js] Custom App 페이지를 이용해서 페이지 로그(log) 기록하기

철스커 — Sat, 18 Mar 2023 22:48:50 +0900

개요

서비스를 운영하다 보면, 로그를 쌓을 일이 많이 생길 텐데요.

페이지별 로그도 쌓아야 하는 경우가 생깁니다.

Next.js에서는 Custom App 페이지를 (_app.jsx 또는 _app.tsx) 제공하고 있는데요.

Custom App 페이지에서 페이지에 공통적으로 사용할 로직을 적용할 수 있습니다.

Next.js에서 제공하는 router를 통해 URL pathname을 파악할 수 있는데요.

페이지 path를 파일로 관리하여 router pathname과 비교하면, 어떤 페이지인지 알아낼 수 있습니다.

프로젝트 구조 예시

페이지 & 페이지 pathname

메인 : /main
메인 상세 : /main/[idx]
About : /about

페이지 파일 생성 (pages.ts)

// @/constants/pages.ts

export const pages = {
    Main: "/main",
    MainDetail: "/main/[idx]",
    About: "/about",
} as const;

Custom App 페이지 (_app.tsx)

import AppContainer from "@/containers/AppContainer";
import "@/public/normalize.css";
import type { AppProps } from "next/app";

export default function App({ Component, pageProps }: AppProps) {
    return (
		<AppContainer>
			<Component {...pageProps} />
		</AppContainer>
    );
}

_app.tsx의 Component 컴포넌트는 페이지 컴포넌트를 의미합니다.

AppContainer 로직

import { pages } from "@/constants/pages";
import { useRouter } from "next/router";
import { PropsWithChildren, useEffect } from "react";

export default function AppContainer(props: PropsWithChildren) {
    const router = useRouter();
    const keys = Object.keys(pages);

    const getPage = (pathname: string) => {
        return keys.find((key) => pages[key] === pathname);
    };

    const handlePageLog = () => {
        const page = getPage(router.pathname);

        // Logging...
        // 여기에 3rd-party 로그 라이브러리를 사용해도 됩니다..
        console.log(page);
    };

    useEffect(() => {
        handlePageLog();
    }, []);

    return <>{props.children}</>;
}

AppContainer로 페이지 컴포넌트 감싸주고, 페이지에 공통적으로 적용할 로직을 적용할 수 있는데요.

위와 같이 페이지 로그를 기록하는 로직을 작성하였습니다.

결과

[Web] 스타일 컴포넌트를 어떻게 잘 관리할 수 있을까? (feat. Emotion.js)

철스커 — Sat, 18 Mar 2023 19:25:19 +0900

* Emotion.js를 사용해서 스타일 컴포넌트를 생성하려고 합니다.
* React 디자인 패턴인 Presentational - Container 패턴을 사용한 기준으로 설명하였습니다.

고민

Native하게 HTML Element + CSS or Sass를 사용할 수도 있겠지만, CSS in JS의 편리함 때문에 스타일 컴포넌트를 많이 사용하고 계실 겁니다.

스타일 컴포넌트는 페이지 / 컨테이너 / 컴포넌트 어느 곳이든 사용할 수 있을 텐데요.

개발을 진행하면 할수록, 계속 쌓여가는 스타일 컴포넌트를 어떻게 관리해야 할지? 에 대한 고민이 생깁니다.

1. 페이지 Level

// Page.js
import styled from '@emotion/styled';
import Container from '@/containers/Container';

function Page() {
    // 비즈니스 로직...

    return (
        <PageWrapper>
            <Container />
            {/* JSX... */}
        </PageWrapper>
    )
}

// styled
const PageWrapper = styled.main``;

// 다른 스타일 컴포넌트들...

2. 컨테이너 Level

// Container.js
import styled from '@emotion/styled';
import Component from '@/components/Component';

function Container() {
    // 비즈니스 로직...

    return (
        <ContainerWrapper>
            <Component />
            {/* JSX... */}
        </ContainerWrapper>
    )
}

// styled
const ContainerWrapper = styled.section``;

// 다른 스타일 컴포넌트들...

3. 컴포넌트 Level

// Component.js
import styled from '@emotion/styled';

function Component(props) {
    return (
        <ComponentWrapper>
            {/* JSX... */}
        </ComponentWrapper>
    )
}

// styled
const ComponentWrapper = styled.div``;

// 다른 스타일 컴포넌트들...

스타일 컴포넌트를 별도의 파일로 관리하기

비즈니스 로직도 많아지고, 스타일 컴포넌트도 많아지면 한 개의 파일 안의 코드가 방대해집니다.

그러면 가독성도 떨어지고, 개발을 할 때 코드를 찾는 시간이 오래 걸릴 것입니다. (생산성 DOWN)

스타일 컴포넌트를 별도의 파일 안에 모아 놓고, 모듈로 내보내서 필요할 때 가져쓰는 방법이 있습니다.

스타일 컴포넌트를 사용하는 쪽에서는 모듈로 불러와서 사용하기만 하면 되고, 스타일 관리에 대한 관심사를 분리시킬 수 있습니다.

그리고 코드량이 줄어들어 보다 코드가 깔끔해집니다.

// Container.js
import styled from '@emotion/styled';
import Component from '@/components/Component';
import { ContainerWrapper } from './styles';

function Container() {
    // 비즈니스 로직...

    return (
        <ContainerWrapper>
            <Component />
        </ContainerWrapper>
    )
}

// styles.js
import styled from '@emotion/styled';

export const ContainerWrapper = styled.section``;

// 다른 스타일 컴포넌트들...

장점

스타일 관리에 대한 관심사를 분리시킬 수 있다.
페이지 / 컨테이너 / 컴포넌트 파일에서 코드량이 줄어든다.

단점

공통 컴포넌트 (버튼, 팝업 등..) 와 스타일 컴포넌트의 구분이 어려울 수 있다.
이름 중복이 발생할 수 있다. -> 인터페이스 또는 다른 컴포넌트와 이름이 겹치면, 이름이 안 겹치도록 네이밍을 잘 지정해줘야 합니다.

스타일 컴포넌트를 별도의 파일로 관리 + 네임스페이스 지정

이름 중복 이슈를 막으려면, 이름만 안 겹치도록 하면 되는데요.

실제 개발을 하면 유일한 이름을 짓기가 쉽지 않는 경우가 많습니다.

다행하게도, named export 모듈들을 as 키워드를 통해 그룹핑할 수 있습니다.

그러면 스타일 컴포넌트들을 별도의 네임스페이스 안에서 관리할 수 있는 것입니다.

// Container.js
import styled from '@emotion/styled';
import Component from '@/components/Component';
import * as S from './styles';

function Container() {
    // 비즈니스 로직...

    return (
        <ContainerWrapper>
            <Component />
            <S.Contents>
                <S.Title>제목</S.Title>
                <S.Description>설명</S.Description>
            </S.Contents>
        </ContainerWrapper>
    )
}

스타일 컴포넌트는 S라는 네임스페이스 안에 있습니다.

그래서 공통 컴포넌트 Component와 구분이 가능해집니다.

// styles.js
import styled from '@emotion/styled';

export const ContainerWrapper = styled.section``;

export const Contents = styled.div``;

export const Title = styled.h1``;

export const Description = styled.p``;

// 다른 스타일 컴포넌트들...

장점

스타일 관리에 대한 관심사를 분리시킬 수 있다.
페이지 / 컨테이너 / 컴포넌트 파일에서 코드량이 줄어든다.
공통 컴포넌트 (버튼, 팝업 등..) 와 스타일 컴포넌트의 구분을 쉽게 할 수 있다.
이름 중복을 막을 수 있다.
네임스페이스 내부의 스타일 컴포넌트를 코드 에디터가 자동완성으로 알려준다.

단점

네임스페이스 이름을 붙여야 하기 때문에, 코드가 조금 지저분해보일 수 있다? 안 예쁠 수 있다.

자동완성 시, 비슷한 이름의 컴포넌트들이 목록에 많이 나타날 수 있다.

스타일 컴포넌트를 모듈로 관리할 때, 또 발생하는 문제점이 있는데요.

컴포넌트들을 자동완성으로 불러오려고 할 때, 비슷한 이름인 것들이 많아질 수 있다는 것입니다.

네임스페이스로 구분하면 이름 중복을 피할 수 있지만, 이런 문제점? Trade-off가 발생할 수 있습니다.

개인적인 결론

개인적인 결론으로는 스타일 컴포넌트를 최대한 분리하는 쪽으로 가되,

스타일 컴포넌트를 몇 개 사용안하는 곳에서는 스타일 컴포넌트를 분리시키지 말고,

스타일 컴포넌트가 많아지는 곳에서는 파일 & 모듈로 구분하는 것이 좋을 것 같습니다.

상황에 맞게 유연하게 컴포넌트들을 관리해주면 어떨까 싶습니다.

여기까지 제가 고민한 내용을 정리했습니다.

혹시 더 좋은 구조 & 방법이 있다면 알려주세요! ㅎㅎㅎ

[Javascript] 쓰로틀링(throttle), 디바운싱(debounce)을 헷갈리지 말자!

철스커 — Wed, 15 Mar 2023 00:28:00 +0900

프론트엔드 개발을 하다 보면 정말 많이 들어본 개념일 것입니다.

무의미하게 무수하게 발생하는 이벤트를 막기 위한 기법들입니다.

타이머 함수, setTimeout을 통해서 간단하게 구현할 수 있습니다.

쓰로틀링(Throttle)

throttle은 영어로 조르다, 목을 조르다라는 의미를 가지고 있습니다.

이벤트의 목을 조른다(?)라고 볼 수 있는데요.

이벤트가 무수하게 발생하더라도, 일정 시간 동안 이벤트가 1번만 발생하도록 처리하는 것을 의미합니다.

스크롤 이벤트에 쓰로틀링을 적용해서 이벤트 최적화를 해볼 수 있는데요.
스크롤을 할 때 최적화하지 않으면, 이벤트가 무수히 많이 발생하기 때문입니다.

한 개의 버튼이 있고, 이 버튼을 누르면 로그인 기능이 동작한다고 가정해볼까요?

클릭방지를 하지 않는다면 유저가 버튼을 계속 클릭했을 때, 로그인 로직이 작동할 것입니다.

이 로직이 API를 호출하거나 상태값을 변경하거나 하면 골치아픈 문제가 될 수 있습니다.

쓰로틀링을 이용해서, 1초에 한번의 이벤트만 실행되도록 해봅시다.

// throttle.js

let timer = 0;

const handleLogin = () => {
	console.log('클릭!');
    
	if (timer) {
    	return;
    }
    
    timer = setTimeout(() => {
	   console.log('로그인!');
       timer = 0;
    }, 1000);
}

handleLogin 함수가 어떤 버튼에 클릭 이벤트로 등록이 되었다고 합시다.

위의 코드는 버튼을 계속 클릭하더라도, 1초동안 단 한번의 로그인! 로그를 남기고 있습니다.

https://playcode.io/react

눈으로 비교하기 쉽게 클릭과 로그인 로그를 남기도록 했습니다.

디바운싱(Debounce)

이벤트가 무수히 발생하더라도 마지막 이벤트를 기준으로 일정 시간이 지나면 이벤트를 1번만 발생시키는 기법입니다.

마지막 이벤트까지의 이벤트들을 하나의 그룹으로 생각해서, 한 개의 이벤트를 발생시키는 것입니다.

다른 말로 말하면, 일정한 시간이 지나기 전에 이벤트가 계속 발생하면 이벤트를 막아버립니다.

// debounce.js

let timer = 0;

const handleLogin = () => {
	console.log('클릭!');
    
    clearTimeout(timer);
    
    timer = setTimeout(() => {
	   console.log('로그인!');
    }, 1000);
}

https://playcode.io/react

[Next.js] Dynamic Import와 Suspense를 같이 쓰지 말기

철스커 — Thu, 9 Mar 2023 01:35:02 +0900

import dynamic from 'next/dynamic';
import { Suspense } from 'react';

const LazyComponent = dynamic(
	() => import('@/components/LazyComponent')
);

export default function MainPage() {
	return (
		<Suspense fallback={<div>Loading...</div>}>
        	<LazyComponent />
        </Suspense>
    );
}

위와 같이 Next.js에서 제공하는 dynamic(Dynamic Import)을 이용하면,

컴포넌트를 지연 로딩할 수 있어서 Suspense와 같이 사용하려고 했었는데요.

계속 테스트를 진행해도, Suspense의 fallback 컴포넌트가 보이질 않았습니다...

next/dynamic is a composite extension of React.lazy and Suspense, 
components can delay hydration until the Suspense boundary is resolved.

Next.js 공식 문서에서 dynamic import에 이런 설명이 있었습니다.

즉, dynamic 자체가 React.lazy + Suspense 기능을 제공하는 것인데요.

import dynamic from 'next/dynamic';

const LazyComponent = dynamic(
	() => import('@/components/LazyComponent'),
    {
    	loading: () => <div>Loading...</div>
    }
);

export default function MainPage() {
	return (
		<LazyComponent />
    );
}

dynamic으로 불러온 컴포넌트를 Suspense로 감싸도 Suspense의 fallback 컴포넌트가 보이질 않습니다.

dynamic 옵션의 loading에 fallback 컴포넌트를 넣어주면 됩니다.

하지만... Suspense가 눈에 보이지 않아서, Suspense 바운더리를 바로 확인하기 어려울 것 같습니다.

개인적으로는 Suspense와 React.lazy를 직접 사용해서 컴포넌트를 지연로딩하는 게 낫지 않을까 싶습니다.

Suspense 바운더리를 한눈에 파악할 수 있기 때문입니다.

import { lazy, Suspense } from 'react';

const LazyComponent = lazy(
	() => import('@/components/LazyComponent'),
);

export default function MainPage() {
	return (
		<Suspense fallback={<div>Loading...</div>}>
			<LazyComponent />
		</Suspense>
    );
}

[GitLab] The pipeline failed due to the user not being verified 이슈 해결

철스커 — Thu, 9 Mar 2023 01:07:22 +0900

회사에 새로 입사하신 분이 오셔서, GitLab 그룹에 초대했는데요.

새로 오신 분이 GitLab에 커밋을 push하니까 GitLab 파이프라인이 실행되지 않는 현상이 발생했습니다.

GitLab runner 문제인 줄 알고, 삽질하다가...

파이프라인 에러에 마우스를 올려보니... 아래와 같은 오류 메시지를 확인할 수 있었습니다.

오류 메시지

The pipeline failed due to the user not being verified

원인

명확한 원인인지는 모르겠습니다.

추측되는 것은... GitLab에서 Shared Runner에 대한 일정 시간을 무료 제공하는데요.
그 이상부터는 결제가 필요한데, 카드등록을 안해서 발생하는 오류인듯 합니다.

그래서 Shared Runner를 Off하면 문제가 해결되는 것 같습니다.

StackOverflow에서 한 명만 카드등록을 하면 되지, 왜 새로운 멤버도 카드등록을 해야 하냐고 반문하는 글도 봤습니다.

GitLab 버그가 아닐까 싶네요...

해결 방법

여러 차례 구글링을 해보면서, Shared Runner를 Off하면 문제가 해결되는 것으로 확인했습니다.

프로젝트 설정 -> CI/CD -> Runners -> Shared runners Off

참고

https://stackoverflow.com/questions/67875196/why-am-i-getting-pipeline-failed-due-to-the-user-not-being-verified-detache

[Typescript] 자료구조 : 큐 (Queue)

철스커 — Wed, 22 Feb 2023 00:31:39 +0900

큐의 모습

큐의 특징

탐색 시, O(n) 만큼 소요됩니다.
추가, 삭제 시, O(1) 만큼 소요됩니다.
맨 앞의 노드를 head, 맨 뒤의 노드를 tail로 기억합니다.
식당에서 순서를 기다리는 대기열과 비슷합니다.

데이터 노드 구현하기

class Node {
    value: number;
    prev: Node | null = null;
    next: Node | null = null;

    constructor(value: number) {
      this.value = value;
    }
  }

prev, next 프로퍼티가 있습니다.

value 프로퍼티로 데이터를 받고 있고, 숫자 데이터만 받기로 정했습니다.

* 큐를 이중 연결 리스트를 이용해서 구현했습니다.

[ 이중 연결 리스트 개념 ]

[Typescript] 자료구조 : 이중 연결 리스트 (doubly-LinkedList)

단방향 연결 리스트에 이어서 이번엔 이중 연결 리스트입니다. 단방향 연결 리스트 개념을 보고 오시는 것이 좋습니다 :) [Typescript] 자료구조 : 단방향 연결 리스트 (Singly-LinkedList) 자료구조를 공

cheolsker.tistory.com

큐 구현하기

class Queue {
    private head: Node | null = null;
    private tail: Node | null = null;
    private size = 0;

    isEmpty() {
      return this.size === 0;
    }

    enqueue(node: Node) {
      if (this.isEmpty()) {
        this.head = node;
        this.tail = node;
        this.size = 1;
        return;
      }

      const tailPrevNode = this.tail;

      tailPrevNode.prev = node;
      node.next = tailPrevNode;

      this.tail = node;
      this.size++;
    }

    dequeue(): Node | null {
      if (this.isEmpty()) {
        console.log("Queue is Empty!");
        return null;
      }

      const node = this.head;
      this.head = node.prev;

      node.prev = null;

      if (this.size > 1) {
        this.head.next = null;
      }

      this.size--;
      return node;
    }
  }

구현한 코드를 테스트 해보기

const queue = new Queue();

queue.enqueue(new Node(1));
queue.enqueue(new Node(2));
queue.enqueue(new Node(3));

console.log(queue.dequeue());
console.log(queue.dequeue());
console.log(queue.dequeue());
console.log(queue.dequeue());

console 출력값

Node { next: null, prev: null, value: 1 }
Node { next: null, prev: null, value: 2 }
Node { next: null, prev: null, value: 3 }
Queue is Empty!
null

[Typescript] 자료구조 : 스택 (Stack)

철스커 — Wed, 22 Feb 2023 00:23:49 +0900

스택의 모습

스택의 특징

탐색 시, O(n) 만큼 소요됩니다.
추가, 삭제 시, O(1) 만큼 소요됩니다.
최상위 노드를 top을 통해 기억하고 있습니다.
접시 쌓는 것과 비슷한 모양을 가지고 있습니다.

데이터 노드 구현하기

class Node {
    value: number;
    prev: Node | null = null;
    next: Node | null = null;

    constructor(value: number) {
      this.value = value;
    }
  }

prev, next 프로퍼티가 있습니다.

value 프로퍼티로 데이터를 받고 있고, 숫자 데이터만 받기로 정했습니다.

* 이번 글에서는 스택을 이중 연결 리스트를 이용해서 구현하기로 했습니다.

* 스택은 단방향 연결 리스트로도 구현 가능합니다만, 편의를 위해서 이중 연결 리스트를 사용하기로 했습니다.

[ 이중 연결 리스트 개념 ]

[Typescript] 자료구조 : 이중 연결 리스트 (doubly-LinkedList)

cheolsker.tistory.com

스택 구현하기

class Stack {
    private top: Node | null = null;
    private size = 0;

    isEmpty() {
      return this.size === 0;
    }

    push(node: Node) {
      if (this.isEmpty()) {
        this.top = node;
        this.size = 1;
        return;
      }

      this.top.next = node;
      node.prev = this.top;
      this.top = node;

      this.size++;
    }

    pop(): Node | null {
      if (this.isEmpty()) {
        console.log("Stack is Empty!");
        return null;
      }

      const node = this.top;

      this.top = node.prev;
      node.prev = null;
      node.next = null;
      this.size--;

      return node;
    }
  }

구현한 코드를 테스트 해보기

const stack = new Stack();

stack.push(new Node(1));
stack.push(new Node(2));
stack.push(new Node(3));

console.log(stack.pop());
console.log(stack.pop());
console.log(stack.pop());
console.log(stack.pop());

console 출력값

Node { next: null, prev: null, value: 3 }
Node { next: null, prev: null, value: 2 }
Node { next: null, prev: null, value: 1 }
Stack is Empty!
null

[Typescript] 자료구조 : 이중 연결 리스트 (doubly-LinkedList)

철스커 — Sun, 19 Feb 2023 23:57:53 +0900

단방향 연결 리스트에 이어서 이번엔 이중 연결 리스트입니다.

단방향 연결 리스트 개념을 보고 오시는 것이 좋습니다 :)

[Typescript] 자료구조 : 단방향 연결 리스트 (Singly-LinkedList)

자료구조를 공부할 때, 처음 등장하는 녀석입니다. 연결 리스트. 말 그대로, 데이터 (노드)를 연결해 놓은 것입니다. 단방향 연결 리스트의 모습 단방향 연결 리스트의 특징 탐색 시, O(n) 만큼 소

cheolsker.tistory.com

이중 연결 리스트의 모습

이중 연결 리스트의 특징

탐색 시, O(n) 만큼 소요됩니다.
추가, 삭제 시, O(1) 만큼 소요됩니다.
메모리 상으로 인접하지 않은 데이터들을 연결할 수 있습니다. (공간 효율성이 뛰어남)

* 단방향 연결 리스트와 특징이 유사합니다.

단방향 연결 리스트와의 차이점

이전 노드(prev) 를 참조할 수 있습니다.
정방향으로 모든 노드를 순회할 수 있고, 역방향으로도 모든 노드를 순회할 수 있습니다. (prev가 있기 때문)
다음 노드(next)의 위치를 잃어버려도, 이전 노드(prev)를 기억하고 있으면 데이터 손실을 방지할 수 있습니다.
단방향 연결 리스트에 비해 자료구조 크기가 크고, 구현 로직이 복잡합니다.

데이터 노드 구현하기

class Node {
    value: number;
    prev: Node | null = null;
    next: Node | null = null;

    constructor(value: number) {
      this.value = value;
    }
  }

prev, next 프로퍼티가 있습니다.

value 프로퍼티로 데이터를 받고 있고, 숫자 데이터만 받기로 정했습니다.

이중 연결 리스트 틀 잡기

class doublyLinkedList {
    private head: Node = null;
    private tail: Node = null;
    private size: number = 0;

    isEmpty() { ... }

    traverse() { ... }

    traverseBack() { ... }

    insertFront(node: Node) { ... }

    insertBack(node: Node) { ... }

    insertAt(idx: number, node: Node) { ... }

    removeFront() { ... }

    removeBack() { ... }

    removeAt(idx: number) { ... }
}

프로퍼티

head : 첫 노드를 참조합니다.
tail : 마지막 노드를 참조합니다.
size : 노드의 갯수입니다.

메소드

* 총 9개의 메소드를 제공하려고 합니다.

* 노드의 인덱스(idx)는 0부터 시작합니다.

isEmpty : 연결 리스트가 비었는지 체크합니다.
traverse : 연결 리스트를 정방향으로 순회합니다. (head 노드부터)
traverseBack : 연결 리스트를 역방향으로 순회합니다. (tail 노드부터)
insertFront : 맨 앞에 노드를 추가합니다.
insertBack : 맨 뒤에 노드를 추가합니다.
insertAt : 인덱스 위치에 노드를 추가합니다.
removeFront : 맨 앞의 노드를 삭제합니다.
removeBack : 맨 뒤의 노드를 삭제합니다.
removeAt : 인덱스 위치의 노드를 삭제합니다.

isEmpty 메소드 구현

isEmpty() {
  return this.size === 0;
}

탐색 메소드 (traverse, traverseBack) 구현

// traverse
traverse() {
    if (this.isEmpty()) {
        console.log("null");
        return;
    }

    let current = this.head;
    let result = current.value + "";

    while (current.next) {
        current = current.next;
        result += " <-> " + current.value;
    }

    result += " -> null";
    console.log(result);
}


// traverseBack
traverseBack() {
    if (this.isEmpty()) {
        console.log("null");
        return;
    }

    let current = this.tail;
    let result = current.value + "";

    while (current.prev) {
        current = current.prev;
        result += " <-> " + current.value;
    }

    result += " -> null";
    console.log(result);
}

삽입 메소드 (insertBack, insertFront, insertAt) 구현

// insertFront
insertFront(node: Node) {
    if (this.isEmpty()) {
        this.head = node;
        this.tail = node;
    } else {
        const secondNode = this.head;

        node.next = secondNode;
        secondNode.prev = node;

		this.head = node;
	}

	this.size++;
}

// insertBack
insertBack(node: Node) {
    if (this.isEmpty()) {
        this.head = node;
        this.tail = node;
    } else {
        const tailPrevNode = this.tail;

        tailPrevNode.next = node;
        node.prev = tailPrevNode;

        this.tail = node;
    }

	this.size++;
}

// insertAt
insertAt(idx: number, node: Node) {
    if (idx < 0 || idx > this.size) {
        console.log("index error!");
        return;
    }

    if (idx === 0) {
        this.insertFront(node);
        return;
    }

    if (idx === this.size) {
        this.insertBack(node);
        return;
    }

    // 중간노드 삽입
    let current = this.head;
    let currentIdx = 0;

    while (idx !== currentIdx) {
        current = current.next;
        currentIdx++;
    }

    node.next = current;
    node.prev = current.prev;
    current.prev.next = node;
    current.prev = node;

    this.size++;
}

삭제 메소드 (removeBack, removeFront, removeAt) 구현

// removeFront
removeFront() {
    if (this.isEmpty()) {
        console.log("list is empty!");
        return;
    }

    if (!this.head.next) {
        this.head = null;
        this.tail = null;
        this.size = 0;
    	return;
    }

    const secondNode = this.head.next;

    this.head = secondNode;
    secondNode.prev = null;

    this.size--;
}

// removeBack
removeBack() {
    if (this.isEmpty()) {
        console.log("list is empty!");
        return;
    }

    if (!this.tail.prev) {
        this.head = null;
        this.tail = null;
        this.size = 0;
	    return;
    }

    const tailPrevNode = this.tail.prev;

    this.tail = tailPrevNode;
    tailPrevNode.next = null;

    this.size--;
}

// removeAt
removeAt(idx: number) {
    if (idx < 0 || idx > this.size - 1) {
	    console.log("index error!");
    	return;
	}

    if (idx === 0) {
        this.removeFront();
        return;
    }

    if (idx === this.size - 1) {
        this.removeBack();
        return;
    }

    // 중간노드 제거
    let current = this.head;
    let currentIdx = 0;

    while (idx !== currentIdx) {
        current = current.next;
        currentIdx++;
    }

    current.prev.next = current.next;
    current.next.prev = current.prev;
    current.prev = null;
    current.next = null;

    this.size--;
}

구현한 코드를 테스트 해보기

// Test
const list = new doublyLinkedList();

list.insertBack(new Node(1));
list.insertBack(new Node(2));
list.insertBack(new Node(3));

list.removeAt(2);

list.traverse();
list.traverseBack();

console 출력값

1 <-> 2 -> null
2 <-> 1 -> null

[Typescript] 자료구조 : 단방향 연결 리스트 (Singly-LinkedList)

철스커 — Sat, 18 Feb 2023 22:32:05 +0900

자료구조를 공부할 때, 처음 등장하는 녀석입니다.

연결 리스트. 말 그대로, 데이터 (노드)를 연결해 놓은 것입니다.

단방향 연결 리스트의 모습

단방향 연결 리스트의 특징

탐색 시, O(n) 만큼 소요됩니다.
추가, 삭제 시, O(1) 만큼 소요됩니다.
메모리 상으로 인접하지 않은 데이터들을 연결할 수 있습니다. (공간 효율성이 뛰어남)
다음 노드의 위치(next)를 잃어버린다면, 데이터 손실이 일어날 수 있습니다.

배열과의 비교하기

배열의 특징

탐색 시, O(1) 만큼 소요됩니다. (인덱스로 데이터에 접근 가능)
추가, 삭제 시, O(n) 만큼 소요됩니다. (데이터 추가 or 삭제 후, 모든 데이터를 이동시켜야 하기 때문)
데이터들이 메모리상으로 인접한 위치에 있습니다.
탐색할 일이 많다면 배열, 추가 & 삭제할 일이 많다면 연결 리스트를 사용하는 것이 좋습니다.

위에서 얘기한 배열은, 크기가 고정된 배열 (정적 배열)을 의미합니다.

자바스크립트에서 사용하는 배열은 크기가 가변하는 동적 배열인데요.

일반적으로 "정적 배열"과 "연결 리스트"를 비교하기 때문에 위와 같이 정리하였습니다.

데이터 노드 구현하기

class Node {
    item: number; 
    next: Node | null = null;

    constructor(item: number) {
      this.item = item;
    }
  }

Node 객체는 숫자 데이터와 다음 노드를 기억하도록 했습니다.

단방향 연결 리스트 틀 잡기

class linkedList {
    private head: Node = null;
    private length: number = 0;

    traverse() {
    	...
    }

    append(node: Node) {
    	...
    }

    insertAt(idx: number, node: Node) {
    	...
    }

    deleteAt(idx: number) {
    	...
    }

단방향 연결 리스트 객체는 head와 length를 가지고 있습니다.

head는 처음 노드를 length는 노드의 갯수를 의미합니다.

총 4개의 메소드를 제공하려고 합니다.

첫 번째 노드의 인덱스(idx)를 1로 정했습니다.

traverse : 연결 리스트를 순회하고, 노드의 데이터를 출력해줍니다.
append : 연결 리스트 맨 끝에, 새로운 노드를 추가합니다.
insertAt : 연결 리스트 중간에, 새로운 노드를 추가합니다.
deleteAt : 연결 리스트 중간의, 특정 노드를 삭제합니다.

traverse, append 메소드 구현

// traverse
traverse() {
  let current = this.head;
  let result = "";

  while (current) {
    result += current.item + " -> ";
    current = current.next;
  }

  result += "null";

  console.log(result);
}

// append
append(node: Node) {
  let current = this.head;

  if (!current) {
    this.head = node;
    this.length += 1;

    return;
  }

  while (current.next) {
    current = current.next;
  }

  current.next = node;
  this.length += 1;
}

insertAt, deleteAt 메소드 구현

// insertAt
insertAt(idx: number, node: Node) {
  if (idx > this.length) {
    console.log("error!");
    return;
  }

  if (idx === 1) {
    node.next = this.head;
    this.head = node;
    this.length += 1;

    return;
  }

  let prev = null;
  let current = this.head;
  let currentIdx = 1;

  while (current.next && idx !== currentIdx) {
    prev = current;
    current = current.next;
    currentIdx += 1;
  }

  node.next = current;
  prev.next = node;
  this.length += 1;
}


// deleteAt
deleteAt(idx: number) {
  if (idx > this.length) {
    console.log("error!");
    return;
  }

  if (idx === 1) {
    this.head = this.head.next;
    this.length -= 1;

    return;
  }

  let prev = null;
  let current = this.head;
  let currentIdx = 1;

  while (current.next && idx !== currentIdx) {
    prev = current;
    current = current.next;
    currentIdx += 1;
  }

  prev.next = current.next;
  this.length -= 1;
}

구현한 코드를 테스트 해보기

// Test
  const list = new linkedList();

  list.append(new Node(1));
  list.append(new Node(2));
  list.append(new Node(3));

  list.traverse();

  // 중간 데이터 제거
  list.deleteAt(2);

  list.traverse();

  // 중간 데이터 삽입
  list.insertAt(2, new Node(4));

  list.traverse();
}

console 출력값

// 출력값
1 -> 2 -> 3 -> null
1 -> 3 -> null
1 -> 4 -> 3 -> null

[Typescript] 디자인 패턴 : 팩토리 패턴, 정리해보기

철스커 — Sun, 12 Feb 2023 18:30:50 +0900

팩토리 패턴은 이름처럼, 객체를 생성해주는 패턴을 의미합니다.

공장에서 제품들을 찍어내듯이, 코드 상으로 비슷한 객체를 조건에 맞게 찍어냅니다.

팩토리 패턴의 특징

- 상위 클래스는 클래스의 뼈대를 제공한다. ( 추상 클래스를 사용하곤 합니다. )

- 하위 클래스에서 구체적인 정보를 전달해줍니다.

- 팩토리 함수 or 팩토리 클래스에서 조건에 맞게 객체를 생성해줍니다.

- 상위 클래스에서 주로 로직을 관리하기 때문에 유지보수하기 쉽다는 장점이 있습니다.

타입스크립트를 이용해서 팩토리 패턴 사용해보기 1 ( 추상 클래스 )

type LectureType = 'Database' | 'Algorithm' | 'SelfStudy';

// 상위 클래스 (추상 클래스)
abstract class Lecture {
    public abstract getInfo(): string;
}

// 하위 클래스's
class Database extends Lecture {
    constructor(private lectureName: string, private duration: number) {
        super();
    }
    
    public getInfo() {
        return '<DB> ' + this.lectureName + ',' + this.duration + 'm';
    }
}

class Algorithm extends Lecture {
    constructor(private lectureName: string, private duration: number) {
        super();
    }

    public getInfo() {
        return '<AG> ' + this.lectureName + ',' + this.duration + 'm';
    }
}

class SelfStudy extends Lecture {
    constructor(private lectureName: string, private duration: number) {
        super();
    }

    public getInfo() {
        return '[SelfStudy]' + this.lectureName + ',' + this.duration + 'm';
    }
}

// 팩토리 클래스
class LectureFactory {
    static getLecture (type: LectureType, name: string, duration: number) {
        if (type === 'Database') {
            return new Database(name ,duration)
        } else if (type === 'Algorithm') {
            return new Algorithm(name, duration);
        } else {
            return new SelfStudy(name, duration);
        }
    }
}


// test
const databaseLecture = LectureFactory.getLecture('Database', 'db', 90);
const algorithmLecture = LectureFactory.getLecture('Algorithm', 'ag', 120);

console.log(databaseLecture);   // { "lectureName": "db", "duration": 90 } 
console.log(algorithmLecture);  // { "lectureName": "ag", "duration": 120 }
}

추상 클래스를 사용하면, 하위 클래스 별로 메소드를 오버라이딩해서 별도의 로직을 구현할 수 있습니다.

위의 코드는 공통적인 로직이 많기 때문에 비효율적으로 보이네요..

추상클래스를 사용하지 않고, 다음 코드에서 해결해보도록 하겠습니다.

타입스크립트를 이용해서 팩토리 패턴 사용해보기 2 ( 클래스 )

type LectureType = 'Database' | 'Algorithm' | 'SelfStudy';

// 추상 클래스 대신 일반 클래스
class Lecture {
    constructor(private lectureName: string, private duration: number) {}

    public getInfo() {
        this.lectureName + ',' + this.duration;
    }
}

// 하위 클래스's
class Database extends Lecture {
    constructor(lectureName: string, duration: number) {
        super(lectureName, duration);
    }
}

class Algorithm extends Lecture {
    constructor(lectureName: string, duration: number) {
        super(lectureName, duration);
    }
}

class SelfStudy extends Lecture {
    constructor(lectureName: string, duration: number) {
        super(lectureName, duration);
    }
}

// 팩토리 클래스
class LectureFactory {
    static getLecture (type: LectureType, name: string, duration: number) {
        if (type === 'Database') {
            return new Database(name ,duration)
        } else if (type === 'Algorithm') {
            return new Algorithm(name, duration);
        } else {
            return new SelfStudy(name, duration);
        }
    }
}


const databaseLecture = LectureFactory.getLecture('Database', 'db', 90);
const algorithmLecture = LectureFactory.getLecture('Algorithm', 'ag', 120);

console.log(databaseLecture);
console.log(algorithmLecture);

상위 클래스에 공통 프로퍼티 + 공통 메소드를 정의했고, 하위 클래스에서는 불필요한 프로퍼티 + 메소드를 제거했습니다.

추상 클래스를 사용해서 작성한 코드보다 보다 간결해졌습니다 :)

[Typescript] 디자인 패턴 : 싱글톤 패턴, 정리해보기

철스커 — Sat, 11 Feb 2023 19:49:21 +0900

디자인 패턴에서 가장 먼저 배우게 되는 싱글톤 패턴입니다.

객체를 생성할 때, 매번 새로운 참조값을 가진 객체를 생성할 수 있는데요.

만약, 같은 객체를 사용해야 한다면 비효율적인 방법이 될 수 있습니다.

싱글톤 패턴을 이용하면, 몇 가지 장점이 있습니다.

싱글톤 패턴을 사용하는 이유

- 하나의 인스턴스를 사용하기 때문에 불필요한 메모리 낭비를 방지

- 하나의 인스턴스로 불필요한 코드를 덜 작성

- 데이터베이스 연결 모듈에 많이 사용한다고 합니다.

타입스크립트를 이용해서 싱글톤 패턴을 만들어보기

2가지 방법을 이용해서 싱글톤 패턴을 코드로 표현해봤습니다.

1. static 변수를 이용해서 구현

2. 일반적인 클래스로 구현

// static 변수를 이용해서 구현
class Singleton {
    private static module1 = {
        func1: () => {},
        func2: () => {},
    }
    private static instance: Singleton.module1;
    
    static getInstance() {
        return Singleton.instance;
    }
}

const s1 = Singleton.getInstance();
const s2 = Singleton.getInstance();

console.log(s1 === s2); // true

// 일반적인 클래스로 구현
class Singleton {
    private instance;

    constructor() {
        if (!this.instance) {
            this.instance = {
                func1: () => {},
                func2: () => {}
            };
        }

        return this;
    }

    public getInstance() {
        return this.instance;
    }
}

const singleton = new Singleton();
const s1 = singleton.getInstance();
const s2 = singleton.getInstance();

console.log(s1 === s2); // true

[React] React-Query 기본 사용법 정리 (useQuery, useMutation)

철스커 — Fri, 20 Jan 2023 00:49:29 +0900

[ 목차 ]
사용자에게 최신 데이터를 보여주려는 노력
useQuery
useMutation
queryClient.invalidQueries

사용자에게 최신 데이터를 보여주려는 노력

React-Query는 사용자에게 새로운 정보를 보여줄 수 있는 옵션을 제공합니다.

1. Remount

컴포넌트 또는 페이지를 다시 mount 했을 때, 새로운 데이터를 갱신합니다.

refetchOnMount 옵션을 통해 설정할 수 있으며, default 값은 true입니다.

2. Window refocus

윈도우 창을 다시 focus 할 때, 새로운 데이터를 갱신합니다.

refetchOnWindowFocus 옵션을 통해 설정할 수 있으며, default 값은 true입니다.

3. Network reconnect

네트워크가 다시 연결되면, 새로운 데이터를 갱신합니다.

refetchOnReconnect 옵션을 통해 설정할 수 있으며, default 값은 true입니다.

그 밖에 주기적으로 데이터를 새로운 데이터를 갱신할 수 있는 refetchInterval, refetchIntervalInBackground 등의 옵션을 제공하고 있습니다.

기본적으로 사용해보기

Query 함수에 아래의 API를 이용할 예정입니다.

// apis.ts

interface Post {
  id: number;
  title: string;
  body: string;
  userId: number;
}


// 기본 API들을 정의합니다.
export const getPost = (id: number): Promise<Post> => {
  return axios.get(`/posts/${id}`);
};

export const createPost = (payload: Omit<Post, "id">): Promise<Post> => {
  return axios.post("/posts", payload);
};

export const updatePost = (payload: Post) => {
  return client.put(`/posts/${payload.id}`, payload);
};

useQuery

useQuery를 이용해서 데이터를 fetching 할 수 있습니다.

HTTP GET 요청을 할 때, 주로 사용합니다.

useQuery는 queryKey, queryFn, options를 이용해서 코드를 작성할 수 있습니다.

queryKey는 Query를 Unique하게 지칭할 배열,

queryFn은 Promise를 리턴하는 함수,

options는 다양한 옵션들을 전달할 수 있는 객체

// QueryFn을 async/await를 이용해서 작성

const { data, error, isLoading } = useQuery(['getPost'], async () => {
  // getPost는 idx값을 받아서 Post 데이터를 가져오는 API
  const data = await getPost(1);

  return data;
});

// QueryFn을 Promise.prototype.then을 이용해서 작성

const { data, error, isLoading } = useQuery(["/getPost"], () =>
	getPost(1).then((res) => res)
);

// useQuery를 객체 형태로 작성

const { data, error, isLoading } = useQuery({
	queryKey: ["/getPost"], 
    queryFn: () => getPost(1).then((res) => res),
    refetchOnMount: false
});

useMutation

서버의 데이터를 변경할 때 사용합니다.

HTTP POST, PUT, DELETE 요청을 사용할 수 있습니다.

mutationFn은 queryFn처럼 Promise를 리턴하는 비동기 함수입니다.

파라미터를 전달받을 수 있습니다.

mutationFn 파라미터는 useMutation의 리턴값인 mutate 함수의 인자로 전달됩니다.

mutationFn에서는 어떻게 동작할지 정의만 하고, mutate 함수를 통해 나중에 실행되는 것입니다.

// useMutation 기본 사용법
const { mutate } = useMutation((post: Omit<Post, "id">) => createPost(post), {
    onSuccess: () => { 	// mutate가 정상적으로 실행되면, 함수를 실행합니다.
		console.log("createPost success");
    },
    onError: () => { 	// mutate가 실패하면, 함수를 실행합니다.
    	console.log("createPost error");
    }
});


const post = {
	title: 'title from 123',
    body: 'body from 123',
    userId: 123
};

// useQuery처럼 정의된 함수가 바로 실행되는 것이 아니라, mutate 함수가 실행될 때 실행합니다.
mutate(post);

queryClient.invalidQueries

queryClient 객체는 다양한 메소드들을 제공하고 있는데요.

useQueryClient hook 함수를 통해 가져올 수 있습니다.

많은 메소드 중에서, invalidQueries 메소드는 자주 쓰입니다.

invalidQueries는 전달받은 queryKey의 Query를 invalid 처리하고, 해당 Query가 active할 경우 다시 refetch 해주는데요.

특정 API 호출 후, 데이터를 갱신하고 싶을 때 사용할 수 있습니다.

const POST_KEY = ['post'];

const { data: post1 } = useQuery(POST_KEY, () => getPost(1).then((res) => res);
const { mutate } = useMutation((post: Post) => update(post));

const queryClient = useQueryClient();

mutate({
	id: 1,
	userId: 2,
    title: 'title from 2',
    body: 'body from 2',
}, {
	onSuccess: () => queryClient.invalidQueries(POST_KEY);
});

mutate 함수를 실행할 때, option에 onSuccess 함수를 전달한 코드입니다.

useMutation의 option에 onSuccess 함수를 전달할 수도 있습니다.

const POST_KEY = ['post'];

const { data: post1 } = useQuery(POST_KEY, () => getPost(1).then((res) => res);
const { mutate } = useMutation((post: Post) => update(post), {
	onSuccess: () => queryClient.invalidQueries(POST_KEY);
});

const queryClient = useQueryClient();

mutate({
	id: 1,
	userId: 2,
    title: 'title from 2',
    body: 'body from 2',
});

[React] React-Query 상태(Status) & StaleTime, CacheTime 정리

철스커 — Wed, 18 Jan 2023 23:14:02 +0900

[ 목차 ]
Query 상태 (Status)
StaleTime과 CacheTime 정리

Query 상태 (status)

아래 다섯 가지 상태로 정의되어 있습니다.

1. fetching

2. fresh

3. stale

4. paused

5. inactive

1. fetching

QueryFn을 이용해서 데이터를 요청하는 상태입니다.

2. fresh

새로운 데이터를 받은 상태입니다.

default로 staleTime이 0으로 정의되어 있는데요.

default일 때는, 순간적으로 fresh 상태로 유지됩니다.

3. stale

데이터의 상태가 최신이 아님을 뜻하는 상태입니다.

이 상태일 때는 특정 조건 (windowFocus, remount 등...) 이나 백그라운드 상황에서 QueryFn을 통해 새로운 데이터를 가져와 데이터를 업데이트 하곤 합니다.

4. paused

네트워크에 연결되어 있지 않은 상태입니다.

5. inactive

Query를 observing하지 않는 상태입니다.

Query를 사용하는 컴포넌트나 페이지가 unmount 되었다고 볼 수 있는데요.

cacheTime 만큼만 Query가 캐싱됩니다.

cacheTime (default로 5분)이 지나면, garbage collected되어 캐시에서 제거합니다.

** 처음 네트워크 요청을 했을 때 **

상태(status)가 fetching -> fresh -> stale로 변경됨

** 다른 페이지로 이동했을 때 **

이전에 참조했던 Query의 상태가 stale -> inactive로 변경됨

** 네트워크 연결이 없을 때 **

Stale Time과 Cache Time

staleTime

Query의 상태가 fresh -> stale 되는 시간(ms)을 의미합니다.

default 값은 0이며, ms단위로 시간을 지정할 수 있습니다. (1,000이면 1초, 30,000이면 5분)

staleTime은 데이터를 얼마나 자주(often) 가져올 지를 나타내는 기준값입니다.

staleTime 값이 클수록, Query는 fresh 상태로 오래 유지되어 있기에 새로운 데이터를 업데이트하는 주기가 길어집니다.

cacheTime

- Query가 inactive 상태일 때 캐시에서 garbage collected 되는 시간(ms)을 의미합니다.

default 값은 5분입니다.

참고

https://tanstack.com/query/latest/docs/react/guides/important-defaults

https://tkdodo.eu/blog/practical-react-query

[Typescript] Mapped Type (매핑된 타입)

철스커 — Sat, 7 Jan 2023 23:18:14 +0900

[ 목차 ]
Introduction
Mapped Type 사용하기
Pick 유틸타입 살펴보기

Introduction

매핑된 타입(Mapped Type)은 제네릭을 사용해서 다른 타입을 바탕으로 새로운 타입을 만드는 것을 의미합니다.

특징으로는,

1. 중복을 방지할 수 있고,

2. 다른 타입을 참조해서 사용하며,

3. 제네릭과 인덱스 시그니처를 사용한다는 것입니다.

Mapped Type 사용하기

/** 예제1 **/
type StudyRoom {
	name: string;
    cost: string;
    availablePeople: number;
    startTime: Date;
    endTime: Date;
}

// StudyRoom 타입을 바탕으로 새로운 타입을 생성
type NewStudyRoom = { [K in keyof StudyRoom]: boolean };

const newStudyRoom: NewStudyRoom = {
	name: true,
    cost: true,
    availablePeople: false,
    startTime: false,
    endTime: false
}

인덱스 시그니처를 살펴보면, in 키워드를 사용하는 것을 알 수 있습니다.

StudyRoom 타입의 key를 순회하면서, 해당 key들을 NewStudyRoom 타입에 동적으로 생성합니다.

Pick 유틸타입 살펴보기

/** 예제2 **/

// Pick 유틸타입을 구현한 코드
type Pick<T, K extends keyof T> = {
    [P in K]: T[P];
};

// Pick 사용하기
type StudyRoom {
	name: string;
    cost: string;
    availablePeople: number;
    startTime: Date;
    endTime: Date;
}

type PickedError = Pick<StudyRoom, "label">; // error!
type PickedOk = Pick<StudyRoom, "name" | "cost"; // { name: string; cost: string }

Pick 유틸타입도 Mapped Type을 바탕으로 만들어졌습니다.

구현코드를 보면 제네릭 + 인덱스 시그니처 + in 키워드를 사용했다는 것을 알 수 있습니다.

참고

https://www.typescriptlang.org/ko/docs/handbook/2/mapped-types.html

[Typescript] 생성자의 타입을 표현하기 (feat. 생성자 시그니처)

철스커 — Sat, 7 Jan 2023 22:27:49 +0900

[ 목차 ]
Introduction
먼저 간단한 클래스 작성
생성자의 타입 표현하기

Introduction

리액트를 사용하면서 클래스를 거의 사용하지 않고, 함수 위주로 사용했었는데요.

그래서인지, 생성자 함수를 타입으로 표현하는 방식이 너무 생소하게 다가왔습니다.

몇 가지 시행착오를 통해, 알아낸 바를 정리하고자 합니다.

먼저 간단한 클래스 작성

class Person {
    constructor(private name: string, private age: number) {}

    getName() {
      return this.name;
    }

    getAge() {
      return this.age;
    }
  }

const person = new Person("Rabbit", 10);

person.getName(); // "Rabbit"
person.getAge(); // 10

// person 객체의 타입은?
type personType = typeof person; // Person

간단한 클래스를 작성했습니다.

Person 클래스를 이용해서 객체를 만들면, 그 객체의 타입은 Person을 가리킵니다.

다음은 DOM에서 제공하는 내장 객체를 한번 살펴보겠습니다.

그 중에서 FormData 객체의 타입을 살펴봅시다.

// 타입 선언
declare var FormData: {
    prototype: FormData;
    new(form?: HTMLFormElement): FormData;
};

// FormData 기본 사용법
const formData = new FormData();

formData.append('name', 'Rabbit');
formData.append('age', '10');

타입 선언을 보면 함수 시그니처(Call Signature) 앞에 new 가 붙은 것을 볼 수 있습니다.

이 문법이 생성자 시그니처(Construct Signature) 입니다.

생성자 시그니처를 이용해서 생성자의 타입을 표현해보겠습니다.

생성자의 타입 표현하기

// 클래스 Person
class Person {
	constructor(private name: string, private age: number) {}
}

// 두 가지 방식으로 생성자의 타입을 표현할 수 있습니다.
type PersonConstructor1 = new (name: string, age: number) => Person;
type PersonConstructor2 = { new (name: string, age: number): Person };

const p1: PersonConstructor1 = Person; // ok
const p2: PersonConstructor2 = Person; // ok

// 정상적으로 객체가 생성됨
const person1 = new p1("사람1", 11);
const person2 = new p2("사람2", 22);

위와 같이 생성자의 타입을 표현할 수 있는 방법이 두 가지가 있다는 것을 알게 됩니다.

1. 함수의 매개변수 앞에 new를 붙이기

2. 생성자 시그니처를 사용하기

참고

https://www.typescriptlang.org/docs/handbook/2/functions.html#construct-signatures

https://www.typescriptlang.org/docs/handbook/2/generics.html#using-class-types-in-generics

[Typescript] keyof 연산자 (feat. JS에서는 없어요)

철스커 — Sat, 7 Jan 2023 18:21:40 +0900

[ 목차 ]
TS에서의 keyof 연산자

TS에서의 keyof 연산자

자바스크립트에서는 keyof 연산자가 존재하지 않습니다.

keyof 연산자는 타입의 키 값들을 유니온 타입으로 반환해줍니다.

keyof 연산자 는 객체 타입에 사용할 수 있습니다.

  interface Rabbit {
    name: string;
    age: number;
    place: string;
    move: () => void;
  }

  type KeyofRabbit = keyof Rabbit;

  // 테스트
  const rabbit1: KeyofRabbit = "age"; // ok
  const rabbit2: KeyofRabbit = "food"; // error!

[Typescript] typeof 연산자 (with. JS에서의 typeof 연산자)

철스커 — Sat, 7 Jan 2023 18:09:51 +0900

[ 목차 ]
JS에서의 typeof 연산자
TS에서의 typeof 연산자

JS에서의 typeof 연산자

자바스크립트에서도 typeof 연산자가 존재합니다.

어떤 값의 type을 string 형태로 반환하는 연산자입니다.

const a = typeof 1; // "number"
const b = typeof "str"; // "string"
const c = typeof false; // "boolean"
const d = typeof {}; // "object"
const e = typeof []; // "object"
const f = typeof function () {}; // "function"
const g = typeof null; // "object" -> 주의!
const h = typeof undefined; // "undefined"
const i = typeof Symbol(); // "symbol"

null의 타입은 object로 나오는데요.

잘 알려진 자바스크립트 오류 중 하나입니다...!

TS에서의 typeof 연산자

타입을 선언할 때 typeof 연산자를 사용하게 되면, 타입스크립트는 추론한 타입을 넣어줍니다.

const num = 777;
  const str = "str";
  const str2 = String(1);
  const obj = {
    name: "Rabbit",
    age: 10,
  };

  type Num = typeof num; // 777
  type Str = typeof str; // "str"
  type Str2 = typeof str2; // string
  type Obj = typeof obj; // { name: string, age: number }

[Typescript] 제네릭 개념 정리하기

철스커 — Sat, 7 Jan 2023 17:18:01 +0900

[ 목차 ]
Introduction
제네릭 맛보기
제네릭 종류 - 함수, 인터페이스, 클래스
제네릭 제약 조건 (constraints)
제네릭 디폴트 파라미터

Introduction

타입스크립트에서 제네릭은 빠질 수 없는 개념이 되었습니다.

유틸함수도 제네릭을 사용하고 있고, API 인터페이스를 작성하거나 함수를 사용할 때도 많이 사용하고 있습니다.

제네릭에 대해서 타입을 위한 함수와 같다는 표현을 사용하는 것도 보았는데요.

제네릭은 타입에 대한 중복을 제거해줄 수 있기 때문에 이런 표현을 사용한 것 같습니다.

제네릭 맛보기

타입스크립트에서 제네릭은 함수, 인터페이스, 클래스 등에 사용할 수 있습니다.

가장 일반적인 방법은 함수에 제네릭을 사용하는 것일 겁니다.

function age(value: number): number {
	return age;
}

function age(value: string): string {
	return age;
}

편의상, 다른 타입의 같은 이름을 가진 age 함수를 두 개 작성했습니다.

value 매개변수 타입은 위에서 number 또는 string으로 표현이 되고 있는데요.

매개변수 타입을 제외하면 함수 형태가 동일하기 때문에, 중복된 함수라고 볼 수 있습니다.

매개변수 타입이 늘어난다면 비슷한 함수를 계속 만들어야 하는 문제가 발생합니다.

function age<T>(value: T>: T {
	return value;
}

age<number>(25); // 25
age<string>('25살'); // 25살

age(30); // 30
age('30살'); // 30살

위와 같이 <>를 사용해서 제네릭을 적용할 수 있습니다.

함수를 호출할 때에 <>를 사용해서 타입을 지정해줄 수 있고, 그렇지 않아도 타입추론이 되는 경우도 있습니다.

function age<Type>(value: Type>: Type {
	return value;
}

// 타입 파라미터를 여러 개 사용할 수도 있습니다.
function age<T1, T2>(value1: T1, value2: T2): T2 {
	console.log(value1);
    
	return value2;
}

<>에 들어가는 타입을 타입 파라미터(Type Parameter) 라고 부릅니다.

일반적으로 T를 많이 사용하지만, 네이밍은 마음대로 정할 수 있습니다.

제네릭 종류

1. 제네릭 함수

// 함수 선언문
function age<T>(value: T): T {
	return value;
}

// 함수 표현식
const age2: <T>(value:T) => value = age;


// 객체 리터럴 타입의 함수 호출 시그니처
const age3: { <T>(value: T): T } = age2;

2. 제네릭 인터페이스

// 예시1
interface Age<T> {
	value: T;
}

// 예시2
interface AgeFunc {
	<T>(value: T) => T;
}

// 함수에 인터페이스를 적용
const age: AgeFunc = (value) => value;

age(11); // 11
age('11살') // '11살'

3. 제네릭 클래스

class Person {
	name: string;
    age: number;
    
    constructor(name: string, age: number) {
    	this.name = name;
        this.age = age;
    }
}

const p = new Person('Rabbit', 10);

p.name; // 'Rabbit'
p.age; // 10

위와 간단한 클래스를 만들어봤는데요.

간단하니 한번 빠르게 읽어보세요.

제네릭 클래스로 바꿔보겠습니다.

// name에 대한 타입을 N, age에 대한 타입을 A로 표현했습니다.
class Person<N, A> {
	name: N;
    age: A;
    
    constructor(name: N, age: A) {
    	this.name = name;
        this.age = age;
    }
}

const p = new Person('Rabbit', 10);

p.name; // 'Rabbit'
p.age; // 10

제네릭 제약 조건 (constraints)

제네릭 타입을 지정할 때, extends 키워드를 이용해서 제약 조건을 걸어줄 수 있습니다.

어떤 타입으로 특정할 수도 있고요.

어떤 형태를 가지고 있으면 해당 타입을 허용합니다. (덕 타이핑)

// 예시1
function age<T extends number>(value: T): T {
	return value;
}

age('10살'); // error!
age(10); // ok


// 예시2
function getPerson<T extends { name: string }>(person: T): T {
	return person
}

getPerson({ age: 10 }); // error!
getPerson({ name: 'Rabbit', age: 10}); // ok


// 예시3
function getKeyOfPerson<T, K extends keyof T>(person, key) {
	return person[key];
}

const person = { name: 'Rabbit, age: 10 };

getKeyOfPerson(person, 'work'); // error!
getKeyOfPerson(person, name); // ok

제네릭 디폴트 타입 파라미터

<> 안의 타입 파라미터에 디폴트 타입을 지정해줄 수 있습니다.

ES6에서 함수 파라미터에 디폴트 값을 지정해줄 수 있는 것과 비슷한데요.

마땅한 예제를 찾기 쉽지 않아서, axios 타입 선언 일부를 가져와 봤습니다.

// 원본 인터페이스: Axios 응답을 표현하는 인터페이스
interface AxiosResponse<T = any, D = any> {
    data: T;
    status: number;
    statusText: string;
    headers: AxiosResponseHeaders;
    config: AxiosRequestConfig<D>;
    request?: any;
  }
 

// 위의 인터페이스를 더 간단하게 수정하겠습니다.
interface AxiosResponse<T = any> {
    data: T;
    status: number;
    statusText: string;
    request?: any;
}

수정한 AxiosResponse 인터페이스를 보면, T 타입 파라미터에 any 타입이 디폴트로 지정된 것을 볼 수 있습니다.

AxiosResponse 인터페이스를 이용해서 객체를 선언할 때, 타입 추론을 못하거나 타입을 넘겨주지 않으면 any 타입이 T에 기본적으로 적용된다는 의미입니다.

interface AxiosResponse<T = any> {
    data: T;
    status: number;
    statusText: string;
    request?: any;
}

// 예시 1 - ok
const response: AxiosResponse = {
	data: 1,
    status: 200,
    statusText: 'Good',
    request: {}
}

// 예시 2 - error!
const response: AxiosResponse<string> = {
	data: 1,
    status: 200,
    statusText: 'Good',
    request: {}
}

예시1 에서는 T에 타입을 지정하지 않아서 any 타입이 data에 적용됩니다.

그래서 오류가 발생하지 않습니다.

하지만, 예시2 에서는 T에 string 타입을 지정했습니다.

data에 1을 넣어주었기 때문에, 타입이 일치하지 않아 오류가 발생합니다.

[React] React-Query를 이용해서 페이지네이션 구현하기

철스커 — Sun, 27 Nov 2022 15:35:15 +0900

React-Query는 useInfiniteQuery hook을 제공합니다.

문서에도 해당 hook에 대한 API 명세와 사용 방법이 소개되고 있는데요.

공식 문서의 설명이 조금 부족해서 그런지는 모르겠는데, 이해가 되지 않는 부분이 있었고 삽질도 하였습니다.

페이지네이션을 구현한 코드를 정리하였습니다.

비동기 통신 라이브러리로는 axios를 사용하였습니다.

// 페이징을 구현한 컴포넌트

import axios from "axios";
import { useInfiniteQuery } from "react-query";

interface PostData {
  body: string;
  id: number;
  title: string;
  userId: number;
}

function Test1() {
  const API_URL = "https://jsonplaceholder.typicode.com";

  const fetchPost = (param: any) => {
    const start = param.pageParam?.start || 0;
    const limit = param.pageParam?.limit || 5;

    return axios
      .get<PostData[]>(`${API_URL}/posts?_start=${start}&_limit=${limit}`)
      .then(({ data }) => data);
  };

  const { data, fetchNextPage } = useInfiniteQuery({
    queryKey: "getPosts",
    queryFn: fetchPost,
    getNextPageParam: (lastPage) => {
      const lastIdx = lastPage.length - 1;
      const lastPost = lastPage[lastIdx];

      return lastPost.id < 100
        ? {
            start: lastPost.id + 1,
            limit: 5,
          }
        : false;
    },
  });

  return (
    <div>
      {data?.pages.map((page) => {
        return page.map((post) => {
          const { id, title } = post;

          return (
            <div key={`post-${id}`} style={{ marginBottom: "50px" }}>
              <p>{id}</p>
              <p>{title}</p>
            </div>
          );
        });
      })}
      <div>
        <button onClick={() => fetchNextPage()}>Load More...</button>
      </div>
    </div>
  );
}

export default Test1;

// useInfiniteQuery

const { data, fetchNextPage } = useInfiniteQuery({
    queryKey: "getPosts",
    queryFn: fetchPost,
    getNextPageParam: (lastPage) => {
      const lastIdx = lastPage.length - 1;
      const lastPost = lastPage[lastIdx];

      return lastPost.id < 100
        ? {
            start: lastPost.id + 1,
            limit: 5,
          }
        : false;
    },

먼저 useInfiniteQuery를 살펴보면,

useQuery처럼 useInfiniteQuery도 queryKey, queryFn 등을 받습니다.

좀 더 나아가서, getNextPageParam을 전달해줄 수 있는데요.

getNextPageParam은 다음 페이지의 데이터를 가져올 함수에 전달할 파라미터를 결정해줄 수 있습니다.

getNextPageParam은 lastPage와 pages의 두 가지 파라미터를 전달받는데요.

lastPage는 마지막 페이지의 데이터이고, pages는 모든 페이지의 데이터를 의미합니다.

한 페이지 데이터의 형태가 PostData 객체라고 하면,

lastPage는 마지막 페이지의 PostData 객체를 가지고 있고,

pages는 PostData의 배열 형태가 됩니다. (PostData[])

getNextPageParam이 falsy 값을 리턴하면, 더이상 추가 데이터를 가져오지 않습니다.

const fetchPost = (param: any) => {
    const start = param.pageParam?.start || 0;
    const limit = param.pageParam?.limit || 5;

    return axios
      .get<PostData[]>(`${API_URL}/posts?_start=${start}&_limit=${limit}`)
      .then(({ data }) => data);
  };

fetchPost 함수는 useInfiniteQuery의 queryFn에 전달한 함수입니다.

queryFn은 QueryFunctionContext 객체를 파라미터로 전달받습니다.

Query Functions | TanStack Query Docs

A query function can be literally any function that returns a promise. The promise that is returned should either resolve the data or throw an error. All of the following are valid query function configurations:

tanstack.com

이 객체 안에 pageParam 이 존재하는데, 위의 getNextPageParam에서 리턴한 값입니다.

JSONPlaceholder API에서는 _start와 _limit URL 파라미터를 전달해줄 수 있는데요.

_start는 데이터의 id 시작값을, _limit는 가져올 데이터 갯수를 의미합니다.

_start 값이 0이고 _limit이 5이면,

5개의 포스트 id값은 순차적으로 0, 1, 2, 3, 4 입니다.

JSONPlaceholder API는 포스트의 id값 이 오름차순 형태로 데이터를 가져올 수 있기 때문에, 페이지네이션을 구현할 수 있습니다.

다음에 불러올 id값만 넘겨주면 되는 것입니다.

return (
    <div>
      {data?.pages.map((page) => {
        return page.map((post) => {
          const { id, title } = post;

          return (
            <div key={`post-${id}`} style={{ marginBottom: "50px" }}>
              <p>{id}</p>
              <p>{title}</p>
            </div>
          );
        });
      })}
      <div>
        <button onClick={() => fetchNextPage()}>Load More...</button>
      </div>
    </div>
  );

모든 페이지의 데이터를 불러와서 UI를 렌더링해주는 코드입니다.

useInfiniteQuery의 리턴값으로 가져온 data.pages를 이용해주면 되는데요.

pages는 모든 페이지 데이터를 배열형태로 가지고 있습니다.

적절하게 map을 사용해서 화면에 렌더링해주면 되겠습니다.

// pseudo 코드

// 1페이지 데이터 (PostData[])
[ PostData, PostData, PostData, ... ]

// 2페이지 데이터 (PostData[])
[ PostData, PostData, PostData, ... ]

...

// pages (PostData[][])
[ PostData[], PostData[], PostData[], ... ]

return (
    <div>
      {data?.pages.map((page) => {
        return page.map((post) => {
          const { id, title } = post;

          return (
            <div key={`post-${id}`} style={{ marginBottom: "50px" }}>
              <p>{id}</p>
              <p>{title}</p>
            </div>
          );
        });
      })}
      <div>
        <button onClick={() => fetchNextPage()}>Load More...</button>
      </div>
    </div>
  );

UI 하단을 보시면, Load More... 이라는 텍스트를 가진 버튼이 존재하는데요.

버튼에 클릭 이벤트로 fetchNextPage를 호출하도록 하였습니다.

fetchNextPage도 useInfiniteQuery의 리턴값으로 가져올 수 있는데요.

fetchNextPage 함수를 이용해서, 다음 페이지를 가져올 수 있을 때, 다음 페이지 데이터를 가져올 수 있습니다.

샘플

참고

https://tanstack.com/query/v4/docs/guides/infinite-queries

https://tanstack.com/query/v4/docs/examples/react/load-more-infinite-scroll

[Next.js] Recoil, Expectation Violation: Duplicate atom key 이슈

철스커 — Sun, 13 Nov 2022 14:08:50 +0900

( 23. 07. 04 추가 수정 )

Recoil 0.7.6 버전 이후로 환경변수를 추가하면, Duplicate atom key 이슈를 해결할 수 있습니다.

.env* 파일에 아래 환경 변수를 추가해주시면 해결됩니다 !

RECOIL_DUPLICATE_ATOM_KEY_CHECKING_ENABLED=false

(아래 부분으로도 해결가능하겠지만, Deprecated된 해결방법이라고 보시면 됩니다.)

Next.js 개발환경에서 Recoil을 사용하다 보면 Next.js 서버에 다음과 같은 에러가 콘솔로 찍히는 것을 볼 수 있습니다.

Duplicate atom key "KEY 이름". This is a FATAL ERROR in production. 
But it is safe to ignore this warning if it occurred because of hot module replacement.

해결 방법을 서치해보면, 크게 두 가지로 나뉩니다.

1. atom key에 난수 넣기

2. node_modules 하위의 recoil 폴더에서 로그를 주석처리하기

개발이 어느 정도 이뤄진 상황에서는 모든 atom의 key 값에 난수를 넣는 건 어렵다는 판단이 들었습니다.

다른 레퍼런스를 찾아보면 registerNode 함수 console.warn만 주석처리하라고 했는데,

제가 설치한 recoil 버전 (v0.7.6)에서는 조금 다르게 구현이 되어 있었습니다.

저는 recoil 하위의 cjs, es, native, umd 폴더의 index.js 파일에서

checkForDuplicateAtomKey(node.key); 함수 호출을 주석처리해서 문제를 해결했습니다.

[Next.js] Next.js 프로젝트 폴더 구조 잡기

철스커 — Sun, 6 Nov 2022 18:24:31 +0900

프로젝트를 만들고 개발을 진행하다 보면, 파일이 점진적으로 늘어나면서, 폴더 구조를 어떻게 잡아야 하는 지에 대한 고민이 생기곤 합니다. 작은 프로젝트면 폴더 구조를 바로바로 바꿀 수도 있지만, 규모가 어느 정도 커지면 폴더 구조를 변경하기 어렵게 됩니다.

여러 프로젝트를 진행하면서, 저 는 나름대로 폴더 구조를 다음과 같이 구성해야 겠다고 결정을 했습니다.

아래는 VSCODE 에디터에 캡쳐한 사진입니다.

Next.js 폴더 구조

- apis

- components

- constants

- containers

- fixtures

- hooks

- interfaces

- pages

- public

- slices

- styles

- utils

apis

API 들을 모아 놓은 폴더입니다.

타입스크립트를 사용한다면, *.ts 형태의 파일들이 폴더 안에 들어 있게 됩니다.

페이지 또는 도메인 별로 ts 파일들을 관리할 수 있습니다.

apis
- main.ts
- auth.ts
...

components

컴포넌트들을 관리하는 폴더입니다.

하위 구조도 개인 or 회사의 규칙에 따라 다양하게 적용될 수 있습니다.

Atomic 디자인 패턴을 적용하는 곳도 있고요.

components
- common
	- Alert
    	- index.tsx
        - styles.tsx
- main
	- Acomponent
    	- index.tsx
        - styles.tsx
- auth
	- Bcomponent
    	- index.tsx
        - styles.tsx

// pages 폴더를 추가해서 페이지별 컴포넌트를 관리하는 방법

components
- common
	- Alert
    	- index.tsx
        - styles.tsx
        
- pages
	- main
        - Acomponent
            - index.tsx
            - styles.tsx
    - auth
        - Bcomponent
            - index.tsx
            - styles.tsx

constants

상수값을 관리하는 폴더입니다.

- API 도메인 주소라던가

- 기본 이미지 URL

- 스토리지 Key 값

... 등을 관리할 수 있습니다.

containers

컨테이너 파일들을 관리하는 폴더입니다.

컨테이너 패턴을 사용한다면 필수적으로 사용할 것입니다.

components 폴더와 구조가 비슷합니다.

fixtures (optional)

상태의 초기값이나 Mock 데이터를 관리하는 데 사용합니다.

hooks

hooks 함수를 관리하는 폴더입니다.

use~.ts 형태의 파일들이 들어 있는데요.

hooks 함수도 공통적으로 사용하는 것들이 있어서 폴더를 따로 구분해줄 수 있습니다.

hooks
- common
	- useAlert.ts
    - useAuth.ts
    
- useName1.ts
- useName2.ts

interfaces

인터페이스 및 타입을 관리하는 폴더입니다.

페이지 또는 도메인 별로 *.ts 파일들을 관리합니다.

pages

Next.js에서 필수적으로 사용되는 폴더입니다.

하위 폴더 & 파일들은 페이지를 가리키는 데요.

저의 경우에는 페이지 파일은 *.page.tsx 형태로 관리하고 있습니다.

pages
- main
	- index.page.tsx
    - styles.tsx
- auth
	- index.page.tsx
    - styles.tsx

그 이유는 페이지 폴더 안에 페이지에 사용할 스타일들을 관리하기 위해서인데요.

만약, 페이지 파일을 *.page.tsx 형태로 설정하지 않으면, styles.tsx를 페이지로 인식합니다.

보통 styles.tsx 파일 안에서 스타일 컴포넌트를 사용하는 데요.

페이지 파일명이 *.tsx로 설정되어 있으면, 스타일 컴포넌트를 export 하는 과정에서도 에러가 발생합니다.

next.config.js: Custom Page Extensions | Next.js

Extend the default page extensions used by Next.js when resolving pages in the pages directory.

nextjs.org

페이지 파일 형태를 설정하는 것은 위의 링크에서 확인하실 수 있습니다.

*.page.tsx 형태말고, 본인이 원하는 형태로 커스터마이징 하실 수 있습니다.

public

정적 파일들을 관리하는 폴더입니다.

css 파일, font 파일, 이미지 파일을 관리할 수 있습니다.

public
- normalize.css
- images
	- image1.png
    - image2.png

// page별로 관리할 수도 있습니다.

public
- pages
	- main
    	- image1.png
        - image2.png
    - auth
    	- image1.png
        - image2.png

slices (optional)

Redux-Toolkit의 slice를 관리하는 폴더인데요.

recoil을 사용한다면 폴더명이 바뀌겠죠?

사용하시는 상태 라이브러리에 맞게 폴더명 & 구조가 바뀔 것입니다.

styles

스타일 파일을 관리하는 폴더입니다.

공통적으로 사용되는 스타일을 관리할 수 있습니다.

utils

유틸들을 모아놓은 폴더입니다.

예를 들어,

- 스토리지 관련 함수

- 날짜 변환 함수

등... 의 것들이 있습니다.

제가 자주 사용하는 프로젝트 폴더 구조를 설명해드렸는데요.

다른 분들은 어떻게 폴더 구조를 설계하시는 지도 궁금하네요.

더 좋은 구조가 있으시면 댓글로 알려주세요~!

Next.js 보일러 플레이트도 만들었는데, 필요하신 분들 사용하세요 ㅎㅎ

GitHub - CheolWoongChoi/Next_Starter: Next.js Starter-kit

Next.js Starter-kit. Contribute to CheolWoongChoi/Next_Starter development by creating an account on GitHub.

github.com