프로젝트 데이터 관리할 때 GitHub에서 관리했었는데, GitHub가 정적 리소스를 서빙하는 용도가 아니라서 새로운 데이터 추가/수정 할 때 레포 로딩 지옥이 열리고, 또 데이터 추가할 때 용량 제한같은 문제 사항이 있어서 AWS S3로 관리하기로 함.

문제 사항 정리

• GitHub에 JSON 형식의 프로젝트 데이터 저장하고 프론트엔드에서 직접 요청하여 로딩
• GitHub의 정적 파일 로딩 속도가 느려서 사용자 경험 저하
• 데이터 추가/수정 작업 위해 레포 여는 경우, 레포 로딩 지옥 발생
• GitHub 개별 파일 용량 제한으로 인한 푸시 거부

해결

• JSON 데이터를 AWS S3 버킷으로 이전
• 각 데이터를 S3에 폴더별로 분리하여 정적 객체 업로드하고, 퍼블릭 읽기 권한 설정
• 프론트엔드에서 Axios로 동적 패칭하여 콘텐츠 로딩

효과

• 응답 속도 향상
• 비용 효율적
• 확장성 확보
• GitHub 레포 부담 해소

기타

• Portfolio 프로젝트 리뷰
• AWS S3 버킷 생성

Rendered fewer hooks than expected. This may be caused by an accidental early return statement.

React에서 훅(Hooks) 을 사용하는 컴포넌트가 렌더링 흐름 중에 조건문 등으로 인해 일부 훅이 실행되지 않았을 때 발생.

주요 원인

1. 훅이 조건문 안에 들어가 있는 경우

• if, else, switch, while, for, 삼항연산자(? :), 논리연산자(&&) 등 → 훅이 실행될 수도 있고, 안 될 수도 있기 때문에 순서가 꼬임

  if (someCondition) {
  const [x, setX] = useState(0); // ❌ 에러 발생
  }

2. 조기 return 이후 훅 사용

   if (!data) return null;
   const [value, setValue] = useState(); // ❌ 실행되지 않을 수 있음

3. useX() 형태의 커스텀 훅 내부에 조건문이 있을 경우

   function useSomething(enabled: boolean) {
   if (!enabled) return;
   
   const [val, setVal] = useState(0); // ❌ 조건문 안에 있음
   }

나의 경우 조기 return 이후 훅 사용이었음.

에러

const { data, isLoading } = useGetServeralCategories({ limit: 20, offset: 0 });
const { ref, inView } = useInView();

if (isLoading) return <LoadingSpinner />;

useEffect(() => {}, []); // 에러 발생

수정

const { data, isLoading } = useGetServeralCategories({ limit: 20, offset: 0 });
const { ref, inView } = useInView();

useEffect(() => {}, []);

if (isLoading) return <LoadingSpinner />;

또 Axios로 받아올 때도 속도가 느렸었음.

그래서 이러한 문제로 GitHub에서 AWS S3로 변경하여 프로젝트 데이터들을 관리하기로 함.

AWS S3 버킷 생성

1. AWS에서 S3 버킷 검색하고, 버킷 생성 누르고 버킷 이름까지 지정
2. 
3. 퍼블릭 설정 모든 퍼블릭 액세스를 차단하면 모든 접근을 차단하기 때문에, 일단 나는 모두 허용으로 변경함. (세부 사항을 체크하면서 설정하는게 좋음)
4. 그리고 나머지들은 손 안대고 버킷 생성

나는 이미 만들어둔 버킷이 있어서 그런지 지역 설정이 없는데, 지역 설정은 버킷이 많이 사용 될 지역을 설정하는게 좋음

파일 올리기

버킷이 생성되었으면, 필요한 파일들을 올려줌 나는 각 프로젝트명으로 폴더를 분리해서 올려줬음.

여기까지 아무 설정없이 버킷을 생성하고 axios로 데이터 불러오려고 하면, access Denied임. 이제 퍼블릭 액세스 차단을 해제하기 위해 권한 설정에 들어가야함.

퍼블릭 액세스 차단

이건 처음에 버킷 만들 때, 퍼블릭 액세스 차단 설정을 모두 해제했기 때문에 비활성으로 표시되어 있음.

버킷 정책

편집 누르면 버킷 정책 편집기 화면이 나옴

정책 편집기

그리고 정책 생성기로 이동

정책 생성기

• Select policy type : S3 Bucket Policy
• Effect : Allow
• Principal : *
• Actions: GetObject
• ARN : 정책 편집기에 있음

그리고 생성하기 누르면 JSON 형태 문서가 나오는데 Resource의 맨 마지막에 /* 추가하고 정책 편집기에 해당 JSON 붙여넣기

그리고 나는 CORS 에러도 떴었는데, 버킷 권한 설정 맨 마지막 CORS에 해당 내용 추가함

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "HEAD"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": [
            "x-amz-server-side-encryption",
            "x-amz-request-id",
            "x-amz-id-2"
        ],
        "MaxAgeSeconds": 3000
    }
]

결과

이렇게 버킷 설정하고 나면, 해당 S3에 있는 데이터들을 불러올 수 있음.

cloudFront cloudFront는 아마존에서 제공하는 CDN 서비스인데, 이걸 해주면 훨씬 더 빠르게 글로벌 서빙이 가능함. 그리고 정적 리소스 캐싱도 가능하고, 커스텀 도메인 연결도 가능, 보안에도 좋음

🚀 어떤 경우 CloudFront를 쓰는가:

서비스 / 배포용 / 속도 중요 → S3 + CloudFront 추천

• 전 세계 사용자 대상이면 (지리적 거리 단축)
• 같은 이미지 요청이 반복돼서 캐싱 이점이 큰 경우
• 커스텀 CDN 도메인 (cdn.내도메인.com)을 쓰고 싶을 때
• S3 접근을 CloudFront로만 허용하고, S3는 비공개로 만들고 싶을 때

  그런데 지금 내 포트폴리오 같은 경우에는, 나 혼자 쓰는 소규모 프로젝트라 S3만으로도 충분해서 CloudFront는 안쓰기로 함.

Tanstack Query의 에러 핸들링을 위해 블로그들을 찾아보면 useCallback을 사용하여 핸들러 훅을 만드는 것을 찾아볼 수 있음.

훅을 만들어서 사용하는 방법과 이전에 작성한 에러 핸들링 with Tanstack Query #1의 방식을 비교하고자 함.

일단,

1. React 훅을 사용하려면 컴포넌트 함수나 커스텀 훅 내부에서만 사용할 수 있다 → index.tsx에서 사용 불가
2. 그래서 훅을 이용한 핸들러를 적용하고 싶다면? → App.tsx에서 사용해야한다

핸들러 훅(useCallback) 사용하기

// utils
export const useApiError = () => {
  const handleError = useCallback((error: unknown) => {
    // 에러 핸들링 with Tanstack Query #1 코드 참고
  }, []);

  return { handleError };
};

// App.tsx

function App() {

const { handleError } = useApiError();

const [queryClient] = useState(() => new QueryClient({
  queryCache: new QueryCache({
    onError: (error, query) => handleApiError(error),
   }),
   mutationCache: new MutationCache({
    onError: (error, _variables, _context, mutation) => handleApiError(error),
  }),
}));

return (
  <QueryClientProvider client={queryClient}>
      {/* ... */}
  </QueryClientProvider>
  );
}

handleError를 왜 useCallback으로 썼는지

1. 일단 컴포넌트 내부에서 부름 → 이 말은, 컴포넌트가 리렌더링 할 때마다 함수가 새로 만들어진다는 의미 이를 방지하기 위해 useCallback으로 만들어짐
2. React Query 훅의 onError로 넘김 참조 동일성 유지가 중요한데, useCallback으로 안하면 함수가 새로 만들어져서 React Query 내에서 불필요한 리패칭이나 리렌더링이 생길 수 있음

QueryClient에 useState 사용 이유

목적 : 컴포넌트 리렌더링 시 QueryClient 재생성되는거 방지하기 위해

• new QueryClient도 객체임 → 렌더링시마다 새로운 인스턴스가 계속 생성됨 → 참조값이 다르니까 React는 새로운 값으로 인식해서 리렌더링함 → 같은 인스턴스를 계속 써야 캐시/쿼리 상태가 유지가 정상적으로 되는데, 새로운거를 만드니까 문제 : 이전 캐시 날아감, 상태 리셋, 전역 에러 핸들링도 리셋, refetch도 꼬임 등
• useState(() => ...)로 첫 렌더링 시 한 번만 실행되고 값 유지 → 객체 재생성 방지

✅ 전역 QueryClientProvider vs 컴포넌트 내부 QueryClientProvider 차이

• 전역 QueryClientProvider에서는
  • index.tsx나 앱 최상단에 한 번만 QueryClient 인스턴스 생성하고, QueryClientProvider로 감쌈
  • 이 경우 queryClient 객체는 앱 라이프사이클 내내 한 번만 생성되고 재사용됨
  • 그래서 전역 onError 핸들러도 한 번만 등록되고 함수 참조가 계속 동일하니까 useCallback 필요없음
• 컴포넌트 내부 QueryClientProvider에서는
  • App.tsx 같은 컴포넌트 내부에서 QueryClientProvider와 QueryClient를 생성하면
  • 컴포넌트가 리렌더링 될 때마다 새로운 인스턴스 생성하니까 훅을 useCallback으로 감쌌고,
  • queryClient도 객체니까 useState로 한 번만 생성하도록 해서 재사용

    결론 : 전역은 앱 시작 시 1회 queryClient 생성하고, 컴포넌트 내부는 매 렌더 시마다 생성하니까 useCallback이나 useState가 필수

Tanstack Query는 API 호출에서 발생할 수 있는 에러도 강력하게 핸들링할 수 있는 기능을 제공함.

전역 에러 핸들링이 필요한 이유

• 중복된 에러 로직 처리
• 사용자에게 일관된 UX 제공 가능(예: toast 알림)
• 인증 실패, 서버 오류, 네트워크 오류 등의 케이스에 공통 대응 가능

핸들링 적용

// index.tsx

const queryClient = new QueryClient({
  queryCache: new QueryCache({
    onError: (error, query) => handleApiError(error),
  }),
  mutationCache: new MutationCache({
    onError: (error, _variables, _context, mutation) => handleApiError(error),
  }),
});

root.render (
  <React.StrictMode>
    ...
      <QueryClientProvider client={queryClient}>
          <App />
      </QueryClientProvider>
    ...
  </React.StrictMode>
)

V5 이전

• 이전에는 defaultOptions로 에러를 제어했는데, v5로 업데이트된 이후에는 onError와 같은 리스너 함수가 기본 옵션에 직접 설정할 수 없도록 제한됨.
• 즉, onError, onSuccess, onSettled 등이 기본 옵션으로 허용 안함.

v5 이후

• QueryCache로 관리하는게 공식적인 방법

• queryCache: 전역 쿼리 에러

  • 읽기 쿼리(fetch)에 적용
  • useQuery, useInfiniteQuery

• mutationCache: 전역 뮤테이션 에러

  • 쓰기 작업(post, put, delete등)에 적용
  • useMutation

핸들러 유틸 함수

import axios from "axios";
import { toast } from "react-toastify";

const statusHandlers: {
  [key: number]: (msg: string, status: number | null) => void;
  default: (msg: string) => void;
} = {
  400: (msg: string) =>
    toast.error("잘못된 요청입니다. 다시 시도해 주세요.", {
      toastId: "fetch-400-error",
    }),
  401: (msg: string, status) => {
    toast.error("로그인 정보가 유효하지 않거나 세션이 만료되었습니다.", {
      toastId: "fetch-401-error",
    });
  },
  ...,

  500: () =>
    toast.error("서버 오류가 발생했습니다. 잠시 후 다시 시도해 주세요.", {
      toastId: "fetch-500-error",
    }),
  default: () =>
    toast.error("예기치 못한 오류가 발생했습니다. 다시 시도해 주세요.", {
      toastId: "fetch-unknown-error",
    }),
};

interface ErrorResponse {
  message: string;
  status?: number;
}
export const handleApiError = (error: unknown) => {
  if (axios.isAxiosError(error)) {
    if (error.response) {
      const httpStatus = error.response?.status;
      const errorResponse = error.response?.data?.error as ErrorResponse;
      const httpMessage = errorResponse.message;
      const httpErrorCode = errorResponse?.status || null;

      const handle =
        httpStatus !== undefined && statusHandlers[httpStatus] ? statusHandlers[httpStatus] : statusHandlers.default;
      handle(httpMessage, httpErrorCode);
    } else {
      toast.error("서버 연결이 원활하지 않습니다.");
      toast.clearWaitingQueue();
      return;
    }
  } else {
    toast.error("네트워크 연결 오류 또는 기타 오류가 발생했습니다.");
    toast.clearWaitingQueue();
    return;
  }
};

이 유틸 함수는 이 블로그에서 도움을 받은 글임.

• API status는 현재 내가 사용하고 있는 API 응답값을 기반으로 만들었음.

적용하기

모든 API는 try ~ catch(error) { throw new Error(error) }문으로 에러를 잡아냈었음.

전역 쿼리로 에러를 핸들러 하려면, catch(error) { throw error } 로 해야 잡힘.

useCallback

const memoizedFn = useCallback(() => {
  // some logic
}, [deps]);

• React 16.8에서 도입된 기본 Hook
• 함수 자체를 메모이제이션해서, 동일한 함수를 재사용하도록 하는 Hook
• 재렌더링 시 불필요한 함수가 재생성되는 것을 방지함
• 그로인해, 성능 최적화에 도움을 줌

동일한 함수 재사용?

동일한 함수라고 하면 내가 선언한 함수라고 생각할 수 있음. 뭐 이것도 어떻게 보면 맞는 말이긴 함. 그런데 여기서 말하고자 하는 바는, 참조값임.

자바스크립트 함수는 객체로 취급되기 때문에, 변수에 값(value)가 아니라 메모리 주소(참조값)를 저장함.

그래서 useCallback 없이 함수를 불러올 때, 눈에 보이는 건 동일한 함수를 불러오는 것 같지만? 까보면 참조값이 다르기 때문에 React에서는 다른 함수로 간주함.

그래서 리렌더링 할 때마다 새로운 함수가 다시 정의되면서(새로운 참조값), React는 props가 변경된 것으로 판단해 의도치 않은 리렌더링이 발생하는거.

그래서 이런걸 방지하고자

useCallback을 사용함.

useCallback은 함수의 참조값을 고정해줘서 리렌더링이 되어도 의존성 배열이 바뀌지 않는 한 같은 함수를 유지함

그럼 이걸 언제 사용?

1) 자식 컴포넌트에 props로 함수를 전달하는 경우

고유 함수를 생성하고 이걸 부모를 통해 자식에게 전달되면, props를 통해 함수를 전달받은 자식 컴포넌트는 props가 변경되었다고 인식해서 리렌더링을 발생시킴.

이런걸 방지하고자 useCallback으로 함수를 만들어 자식 컴포넌트에게 전달하고, 자식컴포넌트는 함수 재사용하는 것으로 인식해 리렌더링을 방지

const Parent = () => {
  const handleClick = () => {
    console.log("Clicked");
  };

  return <Child onClick={handleClick} />;
};

• 이렇게 하면, Parent가 리렌더링 될 때마다 handleClick도 새로 만들어지고, Child는 매번 리렌더링 됨.

const handleClick = useCallback(() => {
  console.log("Clicked");
}, []);

그래서 이렇게 useCallback으로 리렌더링을 방지

2) useEffect, useMemo, useRef 등 deps에 함수가 들어가는 경우

무슨 말이냐면, 각 Hooks의 의존성 배열에 함수가 들어가는 경우를 말함.

function App() {
  const [count, setCount] = useState(0);

  const doSomething = () => {
    console.log("doing something");
  };

  useEffect(() => {
    doSomething(); // 매번 실행됨
  }, [doSomething]); // 함수가 의존성 배열에 들어감
}

예를 들어 이런 상황이다?

• doSomething 함수는 컴포넌트가 리렌더링 될 때마다 새로 생성됨
• 그래서 useEffect는 doSomething의 참조값이 매번 달라진다고 판단
• 결론 : useEffect는 의미 없이 매번 실행됨

이러한 불필요 리렌더링 방지하기 위해 useCallback을 사용한다면?

const doSomething = useCallback(() => {
  console.log("doing something");
}, []);

• doSomething은 리렌더링돼도 같은 참조값 유지
• 의존성 배열에 넣어도 useEffect가 실행되지 않음

이건 useMemo나 useRef도 마찬가지임.

• useMemo(() => doHeavyThing(fn), [fn])
• useRef(fn)에서 fn이 리렌더링마다 바뀌면 ref.current도 바뀜

3) 외부 의존성인 경우(외부에서 값을 가져오는 api 호출)

const [userId, setUserId] = useState("123");

const fetchUserData = () => {
     const res = await axios.get(`/api/users/${userId}`);
}

useEffect(() => {
    ...
}, [fetchUserData])

이렇게 되면,

1. fetchUserData에 새로운 함수(참조값) 할당
2. useEffect 함수가 호출
3. 의존성 배열에 의해 새로운 fetchUserData 계속 생성
4. 무한루프 발생

그래서 이런걸 방지하고자

const [userId, setUserId] = useState("123");

const fetchUserData = useCallback(async () => {
  const res = await axios.get(`/api/users/${userId}`);
  console.log(res.data);
}, [userId]);

useEffect(() => {
    ...
}, [fetchUserData])

• useCallback에서 userId가 변경될 때만 새로운 fetchUserData가 할당되고
• 새로운 fetchUserData가 할당될 때 useEffect 실행되게 해서 무한루프 방지

그럼 이거 사용하면 무조건 성능 좋아짐?

그렇지는 않음. 모든 함수를 useCallback으로 감싸면 오히려 코드 복잡도만 높이고 성능 이점은 거의 없음

그래서 꼭 필요한 경우에만 사용!

번외 : Tanstack Query와는?

✅ 같이 써도는 됨. 근데 이것도 필요한 경우에만!

일반적으로는 굳이 useCallback을 같이 쓸 필요는 없음

왜냐면,

1. queryFn은 대부분 컴포넌트 밖에서 정의함
   • 일반적으로 useQuery의 queryFn은 외부에서 한 번 정의하고 그대로 사용함 → 렌더링마다 함수가 새로 만들어지는 문제가 애초에 없음
2. React Query는 함수 참조가 바뀌어도 무조건 refetch하지 않음
   • queryKey가 바뀌지 않는 한, 함수 참조값이 바뀌었다고 해서 자동 refetch 안 함
   • 내부적으로 캐시와 queryKey를 기준으로 동작하기 때문에
3. 리렌더링을 유발하지 않음
   • useQuery, useMutation 등은 내부 상태를 자체적으로 관리해서
   • queryFn이 새로 만들어져도 React의 일반적인 props처럼 리렌더링 트리거로 작용하지 않음

✅ useCallback을 굳이 함께 쓰지 않아도 되는 이유

TanStack Query에서는 queryFn을 컴포넌트 외부에서 정의하거나, 함수가 새로 생성되어도 내부 캐시 전략으로 인해 불필요한 refetch나 리렌더링이 발생하지 않기 때문에, 일반적으로 useCallback을 굳이 함께 쓸 필요는 없다.

그럼에도 같이 써야하는 경우는?

1. queryFn이 외부 의존성을 가지고, 컴포넌트 내부에서 정의 될 때

   const fetchData = useCallback(() => {
    return axios.get(`/api/data?filter=${filter}`);
   }, [filter]);
   
   const { data } = useQuery(['data', filter], fetchData);

   • fetchData가 매번 바뀌면 queryKey는 같아도 queryFn이 달라져서 useQuery가 새로 실행될 수 있음 → useCallback으로 fetchData를 정의하는게 좋음

2. useEffect 등에 deps로 넣고 쓰는 경우, 자식 컴포넌트에 refetch 같은 함수를 props로 넘겨야하는 경우

   const { refetch } = useQuery(...);
   
   const handleRefresh = useCallback(() => {
    refetch();
   }, [refetch]);
   
   <Child onRefresh={handleRefresh} />

이번 프로젝트에서는 폴더 구조 변경을 진짜 많이 했었음.

처음에는 기존에 사용하던 폴더 구조 방식으로 만들었음.

// 기존 폴더 구조

src/
 ├── components/ # 재사용 컴포넌트
 │        ├── global/ # 공통 컴포넌트
 │        │        ├── ErrorMessage.tsx
 │        │        ├── LoadingSpinner.tsx
 │        │        ├── LoginButton.tsx
 │        │        ├── PlayButton.tsx
 │        │        └── 등...
 │        │
 │        ├── home/ # homepage에서 사용되는 컴포넌트
 │        ├── playlist/ # playlist에서 사용되는 컴포넌트
 │        ├── search/ # search에서 사용되는 컴포넌트
 │        └── side-bar/ # side-bar에서 사용되는 컴포넌트
 │
 ├── hooks/ # 커스텀 훅
 │
 ├── layout/ # 레이아웃 컴포넌트
 │        ├── homepage/ # home에서 사용되는 레이아웃
 │        ├── playlist/ # playlist에서 사용되는 레이아웃
 │        ├── searchpage/ # search에서 사용되는 레이아웃
 │        ├── AppLayout.tsx # AppLayout
 │        └── 등...
 │
 ├── models/ # 타입 정의 폴더
 │
 ├── pages/ # 페이지 컴포넌트(라우팅되는 각 페이지들)
 │
 ├── ...
 │
 ├── ...

그런데 페이지가 많아지고, 컴포넌트들을 계속 만들게 되면서 이 폴더 구조를 좀 더 명확히 해야겠다(?)라는 생각을 가졌음.

이 생각을 가지게 된 이유는 바로 components 폴더 구조 때문임. 기존에는 라우팅을 기준으로 나누었는데, 이게 components에 대한 명확한 역할이 사라진 것 같다는 느낌이 들었음.

왜냐면 global한 컴포넌트와 각 page에서만 사용되는 컴포넌트가 동일한 components 폴더에 있어, 각 page에 사용되는 컴포넌트들도 모든 페이지에 재사용이 가능한 컴포넌트다라는 인식을 줄 수 있을 것 같았기 때문임.

그래서, 모든 페이지에 재사용이 가능한 컴포넌트들만 두기 위해 폴더 구조 변경에 들어갔음.

상위 components 폴더 구조 변경

1. global/ → common/

모든 페이지 재사용 가능한 컴포넌트들이다라는 의미를 주기 위해 폴더명 이름을 변경했음. 그리고 그 폴더 안에는 components라는 폴더를 만들어 그 안에 재사용이 가능한 컴포넌트들을 두었음. components 폴더를 생성한 이유는, 이 common이라는 폴더 안에 ContextAPI 컴포넌트도 있었기 때문에 이것을 구분하기 위해 components 폴더를 생성함. 그리고 그 후에는 공통으로 사용되는 style 폴더도 생성함.

src/
 ├── common/ # 재사용 컴포넌트
 │        ├── components/ # 공통 컴포넌트
 │        │        ├── ErrorMessage.tsx
 │        │        ├── LoadingSpinner.tsx
 │        │        ├── LoginButton.tsx
 │        │        ├── PlayButton.tsx
 │        │        └── 등...
 │        │
 │        ├── style/ # 공통으로 사용되는 style
 │        │        ├── ListContainer.tsx
 │        │        └── SearchStyle.tsx
 │        │
 │        └── ContextProvider.tsx
 │

2. side-bar/

side-bar 관련 컴포넌트들은 원래 src/components/side-bar 폴더에 있었음.(Side-bar 레이아웃 제외) 그리고 이 관련 컴포넌트들은 src/common/components/side-bar/ 폴더를 생성해 그 안에 관련 컴포넌트들을 두었음. 하지만, 다른 common 컴포넌트들과는 다르게 별도의 side-bar 폴더를 생성하여 구분을 지었음. 그리고 그 side-bar/ 안에는 library-body/ 폴더를 생성해, side-bar에서 사용되는 컴포넌트를 두었음.

src/
 ├── common/ # 재사용 컴포넌트
 │        ├── components/ # 공통 컴포넌트
 │        │        ├── ErrorMessage.tsx
 │        │        ├── LoadingSpinner.tsx
 │        │        ├── LoginButton.tsx
 │        │        ├── PlayButton.tsx
 │        │        ├── side-bar/
 │        │        │        ├── library-body/
 │        │        │        ├── Library.tsx
 │        │        │        └── LibraryHead.tsx
 │        │        └── 등...
 │        │
 │        ├── style/ # 공통으로 사용되는 style
 │        │        ├── ListContainer.tsx
 │        │        └── SearchStyle.tsx
 │        │
 │        └── ContextProvider.tsx
 │

추가 근데 이 포스팅 쓰면서 폴더 구조를 common에서 layout으로 옮김. 아무리 생각해도 현재 프로젝트에서는 재사용 컴포넌트는 아니어서...

src/
 ├── common/ # 재사용 컴포넌트
 │        ├── components/ # 공통 컴포넌트
 │        │        ├── ErrorMessage.tsx
 │        │        ├── LoadingSpinner.tsx
 │        │        ├── LoginButton.tsx
 │        │        ├── PlayButton.tsx
 │        │        └── 등...
 │        │
 │        ├── style/ # 공통으로 사용되는 style
 │        │        ├── ListContainer.tsx
 │        │        └── SearchStyle.tsx
 │        │
 │        └── ContextProvider.tsx
 │
 ├── ...
 ├── ...
 ├── layout
 │        ├── side-bar
 │        │        ├── library-body/
 │        │        ├── Library.tsx
 │        │        └── LibraryHead.tsx
 │        │
 │        ├── AppLayout.tsx
 │        ├── Side-bar.tsx
 │        ├── 등...

참고 common/style/도 별도 src/style로 폴더 분리함.

3. 상위 components의 pages 컴포넌트 폴더 위치 변경

폴더 변경의 가장 큰 이유였던, 상위 컴포넌트 폴더에 있던 각 pages의 컴포넌트들의 폴더 위치를 변경함.

일단, 위에서도 썼다시피, 상위 컴포넌트에 있어 모든 페이지에서 재사용이 가능한 컴포넌트라고 오해를 불러 일으킬 수 있어서 각 해당pages에 컴포넌트 폴더를 생성해서 위치를 이동시켰다. 이렇게 하니, 확실히 컴포넌트 관리도 쉬워지고 common이라는 폴더의 역할이 명확해져서 앞으로는 이 폴더 구조 형태를 유지할 것 같음.

src/
 ├── common/ # 재사용 컴포넌트
 ├── layout/
 ├── ...
 ├── ...
 ├── pages
 │        ├── homePage/
 │        │        ├── components/
 │        │        └── HomePage.tsx
 │        │
 │        ├── playlistPage/
 │        │
 │        ├── searchPage/

마무리

폴더 구조 변경은 일단 이렇게 마무리가 되었음.

그리고 이 작업을 하면서 기존에 만들었던 컴포넌트 파일 위치 변경도 많이 이루어졌고, layout도 많이 만들었음. 확실히 컴포넌트들이 많아지니, 폴더 구조 변경 리팩토링은 내가 기존에 했던 폴더 구조 방식에서는 필수적으로 해야했던 부분이었던 것 같음. 이 작업을 하면서 좀 더 효율적인 구조 방식과 폴더마다의 명확한 역할에 대해 좀 더 알게 되었음.

다음 프로젝트에서는 이번 폴더 리팩토링 기억을 되짚어보며 의미가 명확한 구조를 짤거같음.

드디어 홈 데이터 패칭

한동안 홈 화면은 휑~했었음 새 앨범 발매 섹션만 있었고, 나머지는 없었음.

왜냐, 이 때 플레이리스트 부분의 작업을 하고 있었기 때문.

그래서 npm start하고 화면이 켜졌을 때, 내가 계속 작업은 하고 있지만 뭔가 비었다(?), 볼게 없다(?)라고 느꼈었음. 그때마다 재빠르게 로그인하고 플레이리스트로 이동을 했지만ㅋ 계속 이렇게 둘 수는 없다 싶어서 드디어 홈 작업에 돌입!

섹션에 대한 API를 제공하지 않는다고?

드디어 홈 작업한다고 어떤 데이터들을 보일까 타이틀을 정했었음.

1. 새 앨범 발매(Release Album) → 이건 이미 했으니까
2. 인기 아티스트(Top Artists)
3. 인기 앨범(Popular Albums)
4. 추천 차트(Recommended / Charts)

그래서 API Document에서 해당 API들을 제공해주는지 찾아봤는데 제공해주지 않았음. 근데 아니, 이건 좀 기본적으로 제공해주는 API이지않나?, 이걸 제공안한다고?라는 생각으로 ChatGPT한테 물어봄.

?? 근데 알려주는거임. 그래서 그래, 이게 없을리가 없지라고 생각하고 api를 만들었음.

그리고 해당 API들은 Token을 꼭 필요로 했기 때문에, clientCredentialToken을 사용함. 홈 화면에서 로그인을 하지 않아도 데이터를 보여야하니까

clientCredentialToken 로그인을 하지 않고, Spotify의 CLIENT_ID와 CLIENT_SECRET을 기반으로 만든 토큰임.

만들고 호출했는데 ???? 왜 안줘?? 왜 404??? 왜 Resource not found???

일단, 나는 여기서 ChatGPT가 준 api 자체는 문제가 없다고 생각했음. 그럼 Token이 제대로 안들어갔나? Network 탭 바로 들어가서 Token 상태 확인함. undefined인가?? NO!! 제대로 들어감.

하지만 결과는 계속 404 Resource not found 그럼 clientCredentialToken으로 안되는건가? 싶어서 로그인한 Token으로 테스트를 했는데도 계속 404

아니, gpt가 이 api 맞다고 했는데??? 그래서 curl로 직접 테스트를 진행해봄.

??? 근데 여기서도 안나오는거임. api 문제라는 생각은 또 안하고, 토큰 때문인가 싶어서 이미 만들어 둔 새 앨범 발매 api를 curl로 테스트해봄. 정상적으로 호출되고 결과도 나옴.

아 이거 api 문제 있구나, 그래서 gpt한테 물어보니 지역 제한 때문에 발생할 수도 있다고 해서 쿼리 스트링으로 지역 설정까지 해줘봤음.(?market=US) → 안됨.

그래서 이 문제의 전체적인 맥락을 분석하면,

1. 일단 공식 API로 제공하지 않음
2. 인기 차트 관련(트랙/아티스트/앨범 순위 등)은 Spotify에서 만든 내부 차트로 API 제공하지 않음
3. 일부 가능한 API 등도 기능 제한이 있거나, 접근 제한(지역, 토큰 등)이 있음

그래서? 차트 관련 API를 사용하지 못했다.

결론 : 섹션 변경

저러한 문제들 때문에, 결론적으로 섹션을 변경하기로 했음.

1. 새 앨범 발매(Release Album) → 이건 이미 했으니까
2. 아티스트(Artists)
3. 앨범(Albums)
4. 플레이리스트(Playlists)
5. 카테고리(Categories)

일단, 이 섹션들에 대해서는 공식 API들은 제공을 했음. 하지만 문제가 뭐냐, 카테고리 제외 나머지 API들은 특정 id가 필요했음. 즉, 아티스트가 랜덤으로 뽑히는게 아니라 특정 아티스트의 id가 필요로 했음.

어떻게 해결? 특정 키워드로 검색하기

카테고리는 여러 카테고리를 제공해주는 공식 API가 있기 때문에 카테고리 제외한 나머지 섹션들은 검색 API를 사용해 작업을 진행했음.

검색 API는 특정 키워트를 기준으로 결과를 제공해주기 때문에, {q: 'k-pop', limit: 10, type: '섹션별'}을 기준으로 결과를 출력했고

 const { data, isLoading } = useSearchCategory({
    q: "k-pop",
    type: [SEARCH_TYPE.Album],
    limit: 10,
  });

카테고리는 여러 카테고리를 제공해주는 공식 API가 있어 해당 API를 사용함.

const { data, isLoading } = useGetServeralCategories({ limit: 10, offset: 0 });

두 API 모두 Token을 필요로 하기에 로그인 없이도 API 호출이 가능한 clientCredentialToken을 사용했음.

스타일 지정

결과는 모두 정상적으로 출력됨. 그리고 10개씩 limit을 해두었기 때문에 가로 스크롤을 적용하는 것으로 일단 마무리함.

홈 화면 데이터 패칭 끝!

홈 화면 남은 작업

일단, 홈 화면을 채워서 휑~한 화면은 없지만, 각 이미지를 클릭했을 때의 라우터와 해당 페이지를 만들어야 함. 이 작업은 검색 페이지 완료하고 만들까 생각 중임. 왜냐면, 검색 페이지에도 해당 페이지로 이동하는 기능이 필요하기 때문.

작업 후기

이번 홈 화면을 작업하면서 공식적으로 제공하지 않는 API는 다 이유가 있기 때문에 제공하지 않음을 알게됨. 하지만, curl을 통해서 직접 호출하고 했던 경험은 재밌었음. 전에 회사에서도 해봤지만, 다시 해보니 재밌었고 api 응답 확인할 때 웹 사이트에서 Network 체크 뿐만 아니라, 직접 호출하는 방식으로 확인해보는 것도 괜찮다고 생각함. 그래서 나중에는 이런 방식으로도 체크를 많이 해볼 것 같음.

 return (
    <Container className="container">
      {data && data?.pages[0]?.categories?.items.length > 0 ? (
        <Grid container spacing={2}>
          {data?.pages[0]?.categories?.items.map((category: any, idx: number) => (
            <Content key={category.id} size={{ xs: 12, sm: 6, md: 4 }}>
              <Contentbox>
                <CategoryName variant="h1">{category.name}</CategoryName>
                <CategoryImg src={category.icons[0].url} />
              </Contentbox>
            </Content>
          ))}
        </Grid>
      ) : (
        <Typography variant="h2">No data</Typography>
      )}
    </Container>
  );

const Container = styled("div")({});
const Content = styled(Grid)({});
const Contentbox = styled(Box)({
  position: "relative",
  backgroundColor: "#D3ECCD",
  borderRadius: "10px",
  overflow: "hidden",
  aspectRatio: "2 / 1",
});
const CategoryName = styled(Typography)({
  padding: "1rem",
});
const CategoryImg = styled("img")({
  position: "absolute",
  width: "45%",
  bottom: "-10%",
  right: "-8%",
  transform: `rotate(25deg)`,
});

• ContentBox: { position: "relative" }, CategoryImg: { position: "absolute" } ContentBox 안 이미지 위치 조정 위해 사용
• ContentBox: { aspectRatio: "2 / 1" } ContentBox 반응형 비율 유지
• CategoryImg: { width: "45%" } 이미지 너비를 부모 요소 너비에 대해 45% 차지
• CategoryImg: { bottom: "-10%", right: "-8%" } 부모 ContentBox의 높이/너비에 비례해 위치 설정 → 화면이 작아지면서 위치도 함께 비율로 줄어듬 → 부모 높이의 10%만큼 아래로(밖으로) 내림, 부모 너비의 8%만큼 오른쪽으로(밖으로) 밀어냄

CategoryImg: { bottom: "-10%" } → 이거 안해주면 이미지 반응형 안됨, 그리고 px로 고정하면 절대 위치이기 때문에 반응형 안됨 → 결론 : 화면이 작아져도 위치는 그대로고, 이미지가 작아지면서 부모 영역 밖으로 밀려나거나 잘림

aspectRatio 비율

퍼센트 위치 계산

aspectRatio: "2 / 1" // 예를 들어 width: 400px, height: 200px

• bottom: -10% → 200px * 0.10 = 20px 아래로
• right: -8% → 400px * 0.08 = 32px 오른쪽으로
• width: 45% → 400px * 0.45 = 180px

• 그리드는 항상 플렉스 아이템 → 플렉스 컨테이너 추가하려면 container props를 추가해야함
• 기본적으로 12개의 컬럼으로 구성됨
• 기본 그리드 중단점은 xs, sm, md, lg, xl

  // 중단점 예시
  <Grid size={{ xs: 6, sm: 4, md: 2 }}/>
  

xs:6 → 6/12 → 화면이 작을 때 2개씩 한 줄에 sm:4 → 4/12 → 화면이 조금 넓을 때 3개씩 한 줄 md:2 → 2/12 → 화면이 더 넓을 때 6개씩 한 줄

### 기본 그리드
- 그리드 레이아웃 그리려면 일단, `container` prop을 사용해서 그리드 항목을 감싸야함.

이전에 만들었던 TypeScript 프로젝트나 Tanstack Query는 어떻게 보면 내가 원하는 값, 구조로 만들었기 때문에 실제 현업에 가서 이 스택들을 빠르게 적응하기 어려울 것 같았음.

그래서 실제로 사용되는 OPEN API를 가져와서 이 스택들을 적용해봤는데 내가 너무 간단한 구조들만 지금까지 만들었었구나라고 생각하게 됨.

TypeScript

일단 TypeScript는 to.do.focus에서만 사용해봤고, 그 프로젝트는 api 연동이 필요가 없었고, TypeScript의 고급 기능 등을 사용해보지 않았었음. 또한, 프로젝트 자체가 내가 원하는 데이터 형식을 만드는 것이었기 때문에 실상 모델이 복잡하지도 않았었음.

그리고나서 이번 프로젝트를 진행하며

1. 타입을 만드는게 정말 쉽지 않구나

2. 모델을 정말 많이 만들어야하는구나

3. 모델 만들다가 지칠 수가 있구나

4. 제네릭은 미쳤구나

진정 왜 개발자들이 TypeScript를 한 번 쓰면 다시 JavaScript로 못돌아간다고 하는지 알게되었음. 그리고 와 진짜 타입 모델 만드는게 쉽지 않고, 너무 너무 많이 만들어야한다. 그래서 공통적인 타입 구조는 반드시 재사용 가능하도록 제네릭으로 만들어야하겠구나라고 생각함.

// 제네릭은 미쳤어요!!
export interface ApiResponse<T> {
  href: string;
  limit: number;
  next: string | null;
  offset: number;
  previous: string | null;
  total: number;
  items: T[];
}

그리고 실제로 사용되는 API를 활용하다 보니까 뭔가 좀 더 재밌었던 것 같다. 모르는게 막 나오니까 찾아보는 맛도 좀 있었고, 에러난 걸 해결하면 또 오 이것때문이었음? 이러면서 나름 재밌게 작업을 해나간 프로젝트였음.

Tanstack Query

그리고 Tanstack Query는 day6_Fanground에서 사용해봤는데 분명 이 때는 재밌게 했던 것으로 기억함. 근데 이번에는 로그인에, 데이터 패칭에... 전반적인 부분에 사용하다 보니까 이래저래 에러가 참 많이 발생했었다. 아마 그 전에는 데이터 호출만 했기 때문에 재밌게 했었던 듯...ㅎ

아직 프로젝트 마무리가 된 건 아니지만, 지금까지 진행했던 호출 중에서 제일 골치가 아팠던 부분은 플레이리스트 이름 변경이었음. 아니 분명, 데이터 호출도, query key도, refetch도 되었는데 왜 UI에는 렌더링이 안되는가...? 이 문제는 블로그로 따로 작성도 했음.[ QueryClient - setQueryData ]

아무튼 이런 경험을 겪으면서 Tanstack Query에 대해 좀 더 깊이 알게 된 계기가 되긴 했음. 그리고 역시 데이터 패칭은 Tanstack Query가 확실히 좋구나, 관리하기가 참 편하구나, 라고 다시 한 번 더 느낌.

그리고 여기서도 타입을 맞추는게 쉽지 않구나를 느낌.

api를 따로 만들고, Tanstack Query로 hook을 만들어서 사용했는데 api와 hook의 request/response 타입을 맞추는게 쉽지 않음을 느꼈음. 그리고 웬만하면 다 undefined에 대한 검증을 했는데, 이 부분은 공통 모듈로 하나 만들어야 할 지 아직도 고민하는 부분임. 직접적으로 if()로 체크하는게 안정적이긴 하지만, 뭐 할때마다 undefine 검증을 하라고해서 이럴거면 공통으로 빼는게 낫지 않을까 생각하게 된 부분임. 하지만, 아직 확정은 못하고 고민만 진행 중임. 앞으로 작업을 더 이어나가면서 어떻게 해야할지 봐야겠음.

어쨌든, 이 프로젝트를 시작하게 된 이유는 기술 사용에 대한 부족감을 느꼈기 때문임. 남은 작업 진행하면서 앞으로 기술들을 더 갈고 닦으면서 프로젝트에 대한 DR/TR과 문제 해결 블로깅을 이어나갈 계획임.

남은 작업들이 많아서 에러를 많이 만나게 되겠지만, 힘내자!

로그인을 하려는데, 로그인에 필요한 정보는 다 저장이 되었지만 로그인이 되지 않는 문제가 발생함. 이를 해결하기 위해 refreshToken을 적용

일단, 문제사항이 뭐냐

1. 로그인 → 사용자 권한까지는 문제 없었음
2. 사용자 권한 → 필요한 정보들 받아오기까지는 문제 없었음
3. 정보들 다 받아왔는데 결론: 로그인 안됨 → ❗️ 문제사항 발생

문제사항 발생 이유가 뭐였느냐,

1. 일단 필요한 정보를 받아오는 부분은 비동기로 실행되는데 렌더가 먼저 되면서 로그인 상태 변경이 반영되지 않았음.
2. 필요한 정보들은 이미 받아왔는데, useEffect의 조건으로 인해 액세스 토큰을 받아오는 부분을 계속 실행하면서 서버에서는 이미 한 번 사용된 정보로 계속 요청하니까 에러 발생 처리(Invalid authorization code)

그래서 refresh Token 적용함

일단, 필요한 정보들이 뭐냐면

• ?code
• access_token

refreshToken을 적용하면서 기존 문제들을 어떻게 해결했느냐

1. ?code를 한 번 쓰고 다시 못씀 → 로그인 재시도 에러 해결 : 한 번만 쓰고 나머지는 refresh로 해결
2. 로그인 상태 유지 어려움(token만료) : 자동 갱신
3. API 요청 전마다 access token 유효성 체크 어려움 : Axios 인터셉터에서 자동 처리

처리 과정

로그인 버튼 → 사용자 권한 → 권한 승인 후 인증 코드 발급 → 코드로 액세스 및 리프레시 토큰 발급 → 액세스 토큰으로 사용자 정보 받아와 로그인 처리 → 액세스 토큰 만료 시 리프레시 토큰 자동 갱신해서 로그인 유지

토큰 관련 로직 처리

// 액세스 및 리프레시 토큰 발급
const getAccessToken = asyc () => { ... }
const getRefreshToken = asyc () => { ... }

// 액세스 토큰 만료 체크 & 리프레시 로직
export const getValidAccessToken = async () => {
  const accessToken = localStorage.getItem("access_token");
  const refreshToken = localStorage.getItem("refresh_token");
  const expiresAt = parseInt(localStorage.getItem("expires_at") || "0");

  if (Date.now() < expiresAt) {
    return accessToken;
  }

  const refreshed = await getRefreshToken(refreshToken!);
  localStorage.setItem("access_token", refreshed.access_token);
  localStorage.setItem("expires_at", (Date.now() + refreshed.expires_in * 1000).toString());

  return refreshed.access_token;
};

// api.ts
export const api = axios.create({
  baseURL: `${BASE_URL}`,
  timeout: 1000,
  headers: {
    "Content-Type": "application/json",
  },
});

// 요청 인터셉터 추가하기
api.interceptors.request.use(async (request) => {
  const token = await getValidAccessToken();
  request.headers.Authorization = `Bearer ${token}`;

  return request;
});

• 요청 인터셉터에서 액세스 토큰 만료 여부를 체크하고, 만약 만료되었으면 리프레시 토큰으로 새 액세스 토큰을 받아와서 자동으로 토큰 갱신하도록 함

➕추가 localStorage → sessionStorage로 변경하여 토큰 관리

기존에는 Spotify에서 나온대로 localStorage에 토큰을 저장하였다. 그런데 아무리 사이드 프로젝트라지만 이렇게 두면 안될 것 같아서 sessionStorage에 토큰을 저장하여 관리하는 방식으로 변경했다.

사실 토큰은 쿠키로 관리하는게 제일 안전한데 이 프로젝트는 프론트엔드 only라서 쿠키로는 관리하지 못해 차선책인 sessionStorage로 변경함.

변경 후, 로그인 & 로그아웃 모두 테스트 해본 결과 정상적으로 동작 됨까지 확인함.

개발할 때는 내 개인 계정으로 계속 했어서 포트폴리오에는 테스트용 계정을 만들어야한다는 점을 잊고있었다...ㅠ

아 진짜 이미 이력서 열람한 회사들은 아무 기능이 없는 사이트를 본건데.. 나 참 진짜 어이가 없네ㅠㅠ

일단 뒤늦게라도 테스트 계정 추가해두긴 했는데 아 이력서 열람한 회사가 다시 한번 봐줬으면ㅠㅠㅠ

자나깨나 포트폴리오 재검토! 올린 포트폴리오도 다시 보자!

웹팩을 설정하고 Netlify에 배포를 진행했는데 에러가 발생함.

이유는??

Deploy did not succeed: Deploy directory 'build' does not exist build 폴더를 찾지 못했다는 에러

웹팩에서 번들링될 파일이 저장될 폴더 이름을 변경했는데 이걸 Netlify에 적용하지 않았음.

대부분은 번들링 파일은 build/에 저장되고, Netlify도 기본적으로 build/로 되어있음. 그런데 내가 저장될 폴더를 dist/라고 웹팩에 지정했는데 Netlify에 dist/로 수정하지 않아 에러를 발생

해결

Netlify의 Build Setting의 Publish directory에서 build -> dist로 변경!

참고!! 이거 이름 제대로 써야함! 나는 제대로 썼다고 했는데 빌드 에러 발생

마지막 보면 \bdist로 되어있는거 보임? dist가 아니라 b가 붙어서 에러... => 결국, 오타였음 ㅂ.ㅂ

queryClient.setQueryData

쿼리의 캐시된 데이터를 즉시 업데이트하는데 사용할 수 있는 동기 함수

queryClient.setQueryData(queryKey, updater)

플레이리스트의 이름을 변경하는 작업에서 처음에는 invalidateQueries를 사용했음. 그런데 이름이 변경되지 않는 거임.

1. 그래서 api 호출이 잘못되었나?싶어 확인해보니 → 이것의 문제는 아니었음.
2. 그럼 invalidateQueries의 qeuryKey가 잘못되었나? → 아님.
3. 그럼 queryKey 선택을 잘못했나? → 아님.
4. 그럼 invalidateQueries으로 refetch가 안되나? → 이것도 아니었음.

왜 위 문제들이 다 아니냐?

1. Network 탭에서 확인한 결과, api 요청들은 제대로 이루어지고 있음.
2. 새로 받아온 데이터들이 바로는 적용이 안되지만, 시간이 좀 지나면 새로운 데이터로 패칭되어있음.

그럼 문제는 비동기. UI에서 보고 있는 시점은 아직 이전 캐시 데이터가 그대로였기 때문에 fetch가 끝나기 전까지 이름이 안바뀌었던거.

그래서 이 문제를 해결하기 위해 setQueryData를 사용해서 즉시 캐시 업데이트했음.

export const useChangePlaylistDetail = () => {
     ...,
    onSuccess: async (data, variables) => {
      queryClient.setQueryData(["playlist-detail", variables.playlist_id], (old: any) => ({
        ...old,
        name: variables.name,
      }));
      ...
    },
  });
};

ㅇㅇ refetch 되었다ㅜ

queryClient

QueryClient

서버 데이터를 효율적으로 캐시하고, 공유하고, 갱신할 수 있도록 도와줌

역할

• 캐시 저장소 : 서버에서 가져온 데이터를 메모리에 저장하고, 여러 컴포넌트 간에 공유
• 요청 중복 제거 : 같은 데이터를 여러 컴포넌트에서 요청해도 하나의 요청으로 처리
• 자동 리패치 : 포커스 전환 시나 데이터 변경 시 자동으로 데이터를 새로 가져옴

예시

// index.tsx

import { QueryClient, QueryClientProvider } from "@tanstack/react-query";

const queryClient = new QueryClient();

root.render (
  <React.StrictMode>
    <QueryClientProvider client={queryClient}>
        <App />
    </QueryClientProvider>
  </React.StrictMode>
)

// 사용 예시
import { useMutation, useQueryClient } from "@tanstack/react-query";

export const useUnfollowPlaylist = () => {
  const queryClient = useQueryClient();
  return useMutation({
    mutationFn: (params: UnfollowPlaylistRequest) => {
      return UnfollowPlaylist(params);
     },
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ["current-user-playlists"] });
      window.location.replace("/");
    },
  });
};

queryClient.invalidateQueries

await queryClient.invalidateQueries(
  {
    queryKey: ['posts'],
    exact,
    refetchType: 'active',
  },
  { throwOnError, cancelRefetch },
)

• 캐시에 있는 하나 또는 여러 쿼리를 무효화하고 다시 가져오는데 사용

  queryClient.invalidateQueries({ queryKey: ["current-user-playlists"] });

• current-user-playlists의 queryKey를 가지고 있는 쿼리를 무효화 시키고 캐싱되어 있던 데이터 대신 새로운 데이터를 서버에 요청

Netlify에서 배포 후 페이지 새로고침을 하면 해당 에러가 발생했다. 처음에는 Tanstack Query의 Mutation 후 refetching 때문인 줄 알고 새로운 데이터를 받아오는 부분을 수정하였다.

하지만, 해당 부분 수정 후에도 Page not found 에러가 계속 발생ㅎ

원인

정적 파일 호스팅(Netlify)에서 동적 라우팅 경로를 직접 새로고침해서 생기는 문제임. Netlify는 경로에 대한 실제 HTML 파일을 서버에서 찾으려고 하고, 없으니 404 에러

예시 : https://example.netlify.app/playlist/12345 경로를 찾으려고 함 → 없어서 에러

해결

Netlify에서는 동적 라우팅을 SPA처럼 작동하게 하려면 _redirects 파일이 필요함

1. public에 _redirects 파일 생성
2. 그 안에 /* /index.html 200 작성 : 모든 경로를 index.html로 리디렉션 해라
3. webpack 설정

   new CopyWebpackPlugin({
          patterns: [
            { from: "public/manifest.json", to: "manifest.json" },
            { from: "public/favicon.ico", to: "favicon.ico" },
            { from: "public/_redirects", to: "" }, // dist/_redirect로 복사
          ],
        }),

내 프로젝트에서는 src/index.html을 사용하는데 _redirects의 index.html은 public이던 src던 상관없이 빌드 산출물인 dist에 _redirects가 있어야 한다는 점임 어차피 Netlify는 dist/_redirects만 인식 (그리고 webpack에서 이미 index.html을 설정함)

webpack에서 from의 _redirect경로는 확인해야함. 내가 어디에 넣었는지

참고 - _redirects 파일 형식과 규칙

<source path> <destination path> [status code]

/* /index.html 200

• 모든 경로(/*)를
• /index.html로 리다이렉트
• 200은 성공적으로 리턴한다는 의미

  /blog /new-blog 301
  /docs/* /documentation/:splat 302

• /blog → /new-blog (영구 리디렉트)
• /docs/abc → /documentation/abc (임시 리디렉트)

ContextAPI

• Context API는 React 16에서 부터 나온 리액트 내장 API
• props를 사용하지 않고 필요한 데이터(state)를 전달 할 수 있음
• 전역 상태를 컴포넌트 트리 전체에 props 없이 공유할 수 있음

언제 사용?

단순한 전역 상태에 사용하기 적합 테마, 로그인 정보, 모달 open/close, 언어 설정 등

전역 상태 라이브러리가 있는데 Context API 사용 이유?

• 가볍고 내장 되어 있음 -> 별도 설치 필요 없음, 외부 의존성 없이도 간단한 전역 상태 관리 가능
• 단순한 상태 공유에 충분 -> 테마, 로그인 정보, 모달, 언어 설정 등
• 코드가 직관적이고 추적하기 쉬움

하지만, 한계는 있지

• 비동기 로직 처리가 어려움
• 상태가 복잡해질수록 관리 어려움 -> 깊은 nesting, 복잡한 업데이트 로직은 한계

그래서

Context API는 단순한 전역 상태 관리에는 적합하지만, 비동기 로직, 캐시, 전역 상태가 많고 연관 관계가 많을 때, 성능(렌더 최적화) 문제 생길 때는 전역 상태 라이브러리 사용하는게 적합

어떻게 사용?

1. Context 생성

   import { createContext } from "react";
   

export const MyContext = createContext<타입>(전달할 데이터 초기값);

// 초기값 null이 권장 export const MyContext = createContext<타입 | null>(null);

> **초기값을 `null`로 권장하는 이유**
> 
>1. 실수 방지
→ 초기값을 넣으면 실수로 `Provider` 없이 사용해도 에러는 안남, 하지만 내부 동작은 꼬일 수 있음
2. Provider 필수 사용을 강제할 수 있음
→ `Provider` 안에서 동작되도록 강제 → 그래서 Context 설정을 잘못해도 에러를 내뱉어서 빠른 디버깅 가능
3. 초기값 없이 동작하게 하고 싶을 때
→ 실제 상태나 함수는 `Provider`에서만 만들어지고 전달됨

2. Provider 컴포넌트 생성

import { useState } from "react"; import { MyContext } from "./MyContext";

export const MyProvider = ({ children }: { children: React.ReactNode }) => { const [value, setValue] = useState("Hello Context");

return ( <MyContext.Provider value={value}> {children} </MyContext.Provider> ); };

3. Provider로 감싸기

import { MyProvider } from "./MyProvider"; import App from "./App";

const Root = () => ( );

4. Context 사용하기

import { useContext } from "react"; import { MyContext } from "./MyContext";

const MyComponent = () => { const value = useContext(MyContext); return

CopyWebpackPlugin 모듈은 프로젝트를 빌드할 때 정적 파일을 복사하고 디렉토리를 만들기 위한 도구

왜 사용했느냐..?

프로젝트 진행 중 메타 태그를 설정해야하는데, 나는 빌드 결과물이 dist에 되는 상황

그래서 public에 있는 메타 태그 관련된 것들을 dist 폴더에 복사해줘야 동작하기 때문에 해당 플러그인을 설치하고 진행

진행

npm i copy-webpack-plugin --save-dev

// webpack.config.js

module.exports = (env, argv) => {
    const isProduction = argv.mode === "production";

    return {
        mode: isProduction ? "production" : "development";
        ...code,
        plugins: [
            new CleanWebpackPlugin(),
            new HtmlWebpackPlugin({
                template: path.resolve(__dirname, "src", "index.html"),
            }),
            new Dotenv({
                ...code
            }),
            new CopyWebpackPlugin({
                   patterns: [
                      { from: "public/manifest.json", to: "manifest.json" },
                      { from: "public/favicon.ico", to: "favicon.ico" },
                ],
              }),
        ]
    }
}

webpack에서 해당 설정 해줌으로 인해서 public -> dist로 복사되고, HtmlWebpackPlugin에서 설정한 index.html로 이동하여 <link />태그 작성해야함.(/favicon.ico, /manifest.json)

파일 복사해도 브라우저가 읽으려면 HTML의 <link /> 같은 태그가 있어야 함.

결론

webpack은 파일을 복사해주는 역할 HTML은 브라우저에서 이 파일을 어디서 읽을지 알려주는 역할

• MUI에서 제공하는 스타일 넣는 props임
• sx는 style={{ }}랑 같은 개념임
• 근데 MUI 전용인것 뿐

<Box sx={{ padding: "0 2rem" }}/>

style과 sx 차이

중첩 스타일 예시

<Box sx={{ padding: 2, color: "red", "&:hover": { color: "blue" } }}>Hello</Box>