첫 번째 시도

FlashList에서 제공하는 stickyHeaderIndices 옵션을 활용해 Sticky Header를 구현해보았다.
하지만 예상과는 다른 문제가 발생했다.

문제점

stickyHeaderIndices는 renderItem으로 렌더링되는 항목에만 적용되며
ListHeaderComponent에는 사용할 수 없었다.

그 결과 리스트의 첫 번째 상품 아이템이 고정되는 현상이 발생했고
의도했던 Sticky Header와는 전혀 다른 어색한 UI가 만들어졌다.

두번째 시도

ListHeaderComponent를 쓰지 말고 아예 Header를 renderItem 안으로 넣어버리자.

이를 위해 리스트 데이터에 타입을 부여해 각 아이템이 어떤 역할을 하는지 구분하도록 설계했다.

• type: 'header' → Sticky Header로 사용될 영역
• type: 'item' → 일반 상품 아이템

이렇게 하면 stickyHeaderIndices를 적용할 수 있고 Header 역시 리스트 아이템처럼 다룰 수 있을 것이라 기대했다.

하지만 이 방식은 FlashList의 구조적 특성과 잘 맞지 않았다.

FlashList 입장에서는 Header 역시 일반 아이템과 동일하게 취급되기 때문에

• 재사용 대상이 되고
• 스크롤에 따라 unmount/mount가 발생할 수 있으며
• Sticky 상태에서 불필요한 re-render가 발생

결과적으로 FlashList의 가상화 장점을 일부 깨는 구조였다.

또한 성능 관점에서 보았을 때 이 방식이 최적은 아니라는 판단이 들었다. FlashList는 기본적으로 아이템 가상화에 최적화된 리스트인데 stickyHeaderIndices는 레이아웃 계산, 오프스크린 아이템 유지, 스크롤 중 위치 보정 과정을 거치며 이로 인해 레이아웃 비용이 증가하기 때문이다.

세번째 시도

최종 구현 방식

FlashList에서 제공하는 스크롤 감지 옵션을 활용해 현재 스크롤 위치를 추적하도록 구현했다.

스크롤이 진행되면서 얻은 현재 Y축 위치를 기준으로 Header의 기준 위치와 비교하고
show / hide 여부에 따라 Header의 opacity를 조정하는 방식이다.

이를 통해 Sticky Header를 실제로 고정시키는 대신
스크롤 위치에 따라 자연스럽게 나타나고 사라지는 UI를 구현할 수 있었다.

결과적으로 레이아웃 재계산을 발생시키지 않으면서 JS → UI 변경 비용을 최소화해 성능과 UX를 모두 만족시키는 구현이 가능했다.

• 캐싱은 자주 사용되는 데이터를 한 번 받아온 후에 그 데이터를 임시 저장소에 저장하여 동일한 데이터를 빠르게 불러와서 사용하는 기법을 말한다.
• 메모리 계층 구조에서 캐시는 디스크나 메인 메모리보다 더 빠르게 데이터를 불러와 사용해야 할 때 쓰인다.

캐싱의 종류?

• 캐싱에는 여러 종류가 존재한다.

1) 브라우저 캐시

• 변화가 적은 데이터라면 캐싱을 적용해 볼 수 있다. HTML, CSS, JavaScript, 이미지 등 웹 자원을 로컬 디스크에 저장해둔다. 이는 로컬 저장소에 캐시되기 때문에 단일 사용자를 대상으로 하며, 해당 사용자의 정보만을 저장한다. ex) Etag와 Cache-Control은 브라우저 캐시와 관련된 HTTP 헤더로, 웹 브라우저가 서버에서 자원을 어떻게 캐시할지를 결정하는 데 사용된다.

• HTTP 헤더의 ETag는 특정 버전의 리소스를 식별한다. 클라이언트는 데이터를 최초로 받은 이후 동일한 리소스를 요청할 때, 이전에 받은 Etag 값을 If-None-Match 헤더에 포함하여 요청을 보낸다.

• If-Modified-Since* 캐시된 리소스의 Last-Modified 값 이후에 서버 리소스가 수정되었는지 확인합니다. 서버는 이 Etag와 리소스의 현재 Etag를 비교하여, 리소스가 변경되지 않았다면 304 Not Modified 상태 코드와 함께 빈 응답을 보내고, 리소스가 변경되었으면 새로운 리소스를 반환한다.

• HTTP 헤더의 Cache-Control은 클라이언트(브라우저)와 서버 간의 캐시 동작을 제어한다.

  no-cache: 서버에서 데이터를 확인해야 하며, 이전에 캐시된 데이터를 사용하지 않도록 합니다.

• no-store*: 데이터가 캐시되지 않도록 합니다.

• max-age*: 리소스가 캐시된 후 최대 몇 초 동안 유효한지 지정합니다.

• public*: 리소스가 모든 캐시에 저장될 수 있음을 의미합니다.

• private*: 리소스는 사용자별로 개인적인 캐시에 저장됩니다.

• must-revalidate*: 캐시된 리소스가 만료되었을 경우, 서버에서 리소스를 다시 확인해야 함을 의미합니다.

• s-maxage*: 중간 서버에서만 적용되는 max-age 값을 설정하기 위해 사용합니다. 예를 들어, Cache-Control 값을 s-maxage=31536000, max-age=0 과 같이 설정하면 CDN에서는 1년동안 캐시되지만 브라우저에서는 매번 재검증 요청을 보내도록 설정할 수 있습니다.

no-cache 속성은 캐시를 먼저 사용하기 이전에 서버에 해당 캐시를 사용해도 되는지에 관해 검증 요청을 보내는 속성이다. 
no-cache 속성이 없는 경우 캐시가 있다면 바로 캐시를 쓰지만(max-age=0), no-cache 속성이 있는 경우 캐시를 바로 쓰지 않고 서버에 이 캐시를 사용해도 되는지에 대한 허락을 맡기 때문에 요청에 대한 시간이 소요될 수 있다.

no-store는 개인정보 등 private 한 데이터가 있는 경우 이 속성을 사용할 수 있다. (캐시를 만들어서 저장조차 하지 않는다.)
private cache에 반대되는 shared cache 가 존재한다.

Cache-Control max-age 값 대신 Expires 헤더로 캐시 만료 시간을 정확히 지정할 수도 있습니다.

• Cache-Control은 리소스를 어떻게 캐시할지에 대한 지침을 제공하며, Etag는 리소스의 변경 여부를 확인하는 데 사용된다.

2) 프록시 캐시

• 공유 캐시(shared cache)로 한 명 이상의 사용자에 의해 재사용되는 응답을 저장한다. no-cache는 최신화가 필요한 stale 데이터를 사용하고 싶을 때 사용하고, 이러한 데이터를 사용해서 문제가 발생한다면 504 에러를 반환하는 must-revalidate를 사용하면 된다.

3) CDN 캐시

• CDN은 성능 향상을 위해 클라이언트의 요청이 같은 서버로 가는 것을 막는다. CDN 캐시는 웹 자원의 정적 파일을 캐시하여 빠른 응답을 제공한다.

  일반적으로 캐시를 없애기 위해서 CDN Invalidation을 수행한다고 한다. CDN에 저장되어 있는 캐시를 삭제한다는 뜻이다. 브라우저의 캐시는 다른 곳에 위치하기 때문에 CDN 캐시를 삭제한다고 해서 브라우저 캐시가 삭제되지는 않는다.

데이터 페칭 라이브러리에서는 캐싱을 어떻게 처리할까?

React Query

• 서버에서 받은 데이터를 클라이언트의 로컬 메모리나 로컬 스토리지, 또는 IndexedDB에 저장하여 다음에 동일한 요청이 있을 경우 네트워크 요청을 생략하고 캐시된 데이터를 반환할 수 있습니다.
• staleTime을 설정하여 데이터가 "stale" 상태(즉, 오래된 상태)가 되기까지의 시간을 지정할 수 있고, cacheTime을 통해 캐시된 데이터를 얼마나 오래 보존할지 설정할 수 있습니다.

staleTime: 데이터를 얼마나 오래 캐시할지 지정합니다. 이 시간이 지나면 데이터는 "stale" 상태가 됩니다. cacheTime: 캐시된 데이터를 언제까지 저장할지 지정합니다. 이 시간이 지나면 캐시된 데이터는 삭제됩니다. refetchOnWindowFocus: 브라우저 창이 포커스를 받을 때 데이터를 자동으로 재페칭할지 여부를 설정합니다.

ref) https://yozm.wishket.com/magazine/detail/2341/ ref) https://toss.tech/article/smart-web-service-cache

* useImperativeHandle

• 부모 컴포넌트가 자식 컴포넌트의 특정 기능에 접근하도록 허용. 일반적으로 ref와 함께 사용되며, forwardRef가 필요함. 부모가 자식 컴포넌트의 특정 기능(예: focus, scroll)을 직접 호출.

[사용 예시]

const FancyInput = React.forwardRef((props, ref) => {
  const inputRef = React.useRef();
  React.useImperativeHandle(ref, () => ({
    focus: () => {
      inputRef.current.focus();
    },
  }));
  return <input ref={inputRef} />;
});

function Parent() {
  const ref = React.useRef();

  return (
    <div>
      <FancyInput ref={ref} />
      <button onClick={() => ref.current.focus()}>포커스</button>
    </div>
  );
}

* useLayoutEffect

• DOM이 렌더링된 직후, 브라우저가 그리기 전에 동기적으로 실행. DOM 변경 후 바로 실행이 필요한 경우에 적합하다. useEffect와 비슷하지만 실행 시점이 다르다.

[사용 시기]

DOM 요소의 위치, 크기 조정이 필요할 때. 애니메이션 효과나 스크롤 위치 설정.

[차이점]

useEffect: 렌더링 이후 실행 (비동기). useLayoutEffect: 렌더링 직전에 실행 (동기).

function LayoutEffectExample() {
  const divRef = React.useRef();

  React.useLayoutEffect(() => {
    console.log(divRef.current.offsetHeight);
  }, []);

  return <div ref={divRef}>레이아웃 확인</div>;
}

* useTransition

• 상태 업데이트를 긴급/비긴급으로 나누어 처리한다. 사용자 인터페이스가 부드럽게 유지. React 18의 Concurrent Mode에서 유용.

  function App() {
  const [isPending, startTransition] = React.useTransition();
  const [count, setCount] = React.useState(0);
  
  const handleClick = () => {
    startTransition(() => {
      setCount((c) => c + 1);
    });
  };
  
  return (
    <div>
      <button onClick={handleClick}>클릭</button>
      {isPending ? <p>로딩 중...</p> : <p>결과: {count}</p>}
    </div>
  );
  }
  

#### * useId
- 고유한 ID를 생성해서 HTML에 사용한다. 나는 폼에 적용했었다. 컴포넌트간 충돌이 없어 유용하다.

function Component() { const id = React.useId();

return ( 입력창 ); }

#### * useDefferedValue
- 부하가 큰 연산의 업데이트를 지연시켜 UI 성능 개선. UI가 느려지지 않도록 함.

function App({ value }) { const deferredValue = React.useDeferredValue(value);

return

#### * useActionState
- 비동기 액션의 상태를 더 명확하고 직관적으로 관리할 수 있다. (기존 useFormState 훅을 개선했다.)

"use client";

function App() { const [state, submitAction, isPending] = useActionState(customAction, initialState); // initialState like {error: null}

return (
    <form action={submitAction}>
    <button disabled={isPending}></button>
    {state.error && <span>error</span>}
    </form>
)

}

``` 리액트 훅이므로 클라이언트 컴포넌트에서 사용해야 한다. pending 상태와 useState, onSubmit 함수를 축약해 개인적으로 가독성과 데이터 응집도가 높아졌다고 생각한다.

“form, input, button 요소에 action 및 formAction props로 Server Action을 전달하면 JavaScript가 비활성화되었거나 코드가 로드되기 전에도 사용자가 폼을 제출하고, 오류를 표시할 수 있게 되었다.”

JavaScript가 비활성화되거나 코드가 로드되기 전에 사용자가 form을 제출할 수 있으면 뭐가 좋은걸까?

사용자의 인터넷 연결이 느리거나, 장치 성능이 낮거나, JavaScript가 비활성화된 환경에서도 폼 제출 기능이 정상적으로 작동하도록 보장해줄 수 있다. 이로써 웹사이트의 접근성을 높여 모든 사용자에게 일관된 경험을 제공할 수 있게 되고, 결과적으로 사용자가 겪을 수 있는 잠재적인 문제를 줄이고 더 많은 사용자가 서비스를 이용할 수 있게 하는 것이다.

• 리액트 상태 관리 라이브러리들 (feat. 장단점)
• 상태 관리에 Redux를 선택하게 된 계기
• Redux 셋팅하기
• Next.js에 Redux를 적용하며 마주하게 된 사사로운 오류사항들
• 번외

🛠️ 리액트 상태 관리 라이브러리들 (feat. 장단점)

리액트 상태 관리 라이브러리에는 다양한 종류가 있다. 익숙한 것들만 간단히 나열해보자면 Recoil, Redux, Jotai, Mobx, zustand 등등 ...

우리가 사용할 기술을 선정할 때 고려해야 할 것이 몇가지 있다. 각 기술의 특성과 장단점을 무조건 파악을 해야 한다는 거다.

제일 주의해야하는 건 무작정 '남들이 다 사용하니까' 선택하는 일이다.

그렇게 되면 내가 만들 프로젝트와 그 기술의 성격이 맞지 않을 수가 있고, 몸집이 커진 프로젝트를 다시 싹 다 갈아 엎어야 하는 대참사가 발생할 수도 있다.

상태관리에 Redux를 선택하게 된 계기

위와 같은 다양한 라이브러리 중 나는 zustand 또는 Redux 사이에서 고민하게 되었다.

나의 상황을 적어보자면

1) 온전히 혼자 작업을 해야 한다. 2) 최대한 빠르게 작업을 마무리 하면 좋다. 3) 두 라이브러리 모두 사용해 본 경험이 없거나 적다.

위 같은 상황에서 빠르고 쉽게 작업할 수 있는 zustand 를 선택하는게 더 효율적이었겠지만, 나는 redux를 선택했다!

왜냐면 redux는 대규모 프로젝트에 더 적합하기 때문이다. (나는 런칭해서 운영까지, 즉 유지보수까지 해보고 싶었기 때문이다.) 그리고 '쉬운걸 먼저 적용해버리면 나중에 더 큰 어려움을 마주하게 되지 않을까? 그러니까 어려운 것부터 먼저 깊게 다뤄보자!' 싶은 마음이었다.

따라서 redux를 next.js(App Route) + typescript 에 적용하게 되는데 ,,,

Redux 셋팅하기

자 차근차근 적용해보도록 하자.

우선, redux와 관련 패키지를 설치해야 한다.

Redux 설치

npm install @reduxjs/toolkit react-redux

Redux 설정

일단, store를 만든다. 이때 store는 redux의 모든 상태들을 관리하게 된다.

// store.ts

import { configureStore } from "@reduxjs/toolkit";
import rootReducer from "./rootReducer";

export const makeStore = () => {
  return configureStore({
    reducer: rootReducer,
  });
};


export type AppStore = ReturnType<typeof makeStore>;
export type RootState = ReturnType<AppStore["getState"]>;
export type AppDispatch = AppStore["dispatch"];

slice 생성

slice는 액션 및 리듀서를 포함한다.

import { createSlice } from "@reduxjs/toolkit";

const userAuthSlices = createSlice({
  name: "userAuth", // slice 식별
  initialState: { name: "subeen" },
  reducers: {
    setUserAuth: (state, action) => {
      state.name = action.payload;
    },
  },
});

export const { setUserAuth } = userAuthSlices.actions;

export default userAuthSlices.reducer;

이때, name에 따라 slice가 식별되니 직관적이게 작명하도록 유의한다.

Provider 설정

Provider를 설정해 모든 페이지에서 Redux 상태에 접근할 수 있도록 한다.

Next.js App Router 구조에서는 app/layout.tsx 파일에서 설정한다.

"use client";

import React from "react";
import { Provider } from "react-redux";
import { makeStore } from "./lib/store";

const store = makeStore(); // makeStore 함수를 호출하여 스토어 객체를 생성합니다.

const ClientLayout: React.FC<{ children: React.ReactNode }> = ({
  children,
}) => {
  return (
    <Provider store={store}>
      {/* store 객체를 Provider에 전달합니다. */}
      <main>{children}</main>
    </Provider>
  );
};

export default ClientLayout;

import Footer from "@/components/Footer";
import Header from "@/components/Header";
import type { Metadata, Viewport } from "next";
import { Inter } from "next/font/google";
import ClientLayout from "./ClientLayout";
import "./globals.css";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
  title: "Create Next App",
  description: "Generated by create next app",
};

export const viewport: Viewport = {
  initialScale: 1,
  width: "device-width",
};

const RootLayout = ({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) => {
  return (
    <html lang="en">
      <body className={inter.className}>
        <ClientLayout>
          <Header />
          {children}
        </ClientLayout>
        <Footer />
      </body>
    </html>
  );
};

export default RootLayout;

위의 코드를 보면 바로 Provider로 감싸는 대신 ClientLayout으로 감쌌는데, 이는 Redux가 클라이언트 컴포넌트에서만 작동하는 훅을 사용해야하기 때문이다. (useSelector, useDispatch)

여기서 잠깐

Redux는 클라이언트 사이드 상태 관리 (브라우저 환경에서 동작하는 상태 관리 도구) 라이브러리이기 때문에 "use client" 지시어가 필요하다.

("use client" 지시어는 초기 페이지 로딩 속도나 사용자 경험에 부정적인 영향을 미칠 가능성이 있다. 번들 크기가 커져 페이지 로드 시간이 증가하는 단점도 있다.)

보통 그래서 next-redux-wrapper 라이브러리를 사용한다.

Redux 사용 예시

컴포넌트에서 redux 상태와 액션 사용 방법이다. useSelector와 useDispatch 훅을 이용하여 상태를 조회하고, 액션을 디스패치 할 수 있다.

// app/login/page.tsx
'use client';

import { useState } from 'react';
import { useDispatch } from 'react-redux';
import { login } from '../../features/userSlice';
import { useRouter } from 'next/navigation';

const LoginPage = () => {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const dispatch = useDispatch();
  const router = useRouter();

  const handleLogin = async (e: React.FormEvent) => {
    e.preventDefault();

    // 실제로는 백엔드에서 로그인 API 호출
    const userData = {
      id: '123',
      name: 'John Doe',
      email: email,
    };

    // 로그인 성공 시 Redux에 사용자 정보를 저장
    dispatch(login(userData));

    // 대시보드로 리디렉션
    router.push('/dashboard');
  };

  return (
    <form onSubmit={handleLogin}>
      <div>
        <label>Email</label>
        <input
          type="email"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
          required
        />
      </div>
      <div>
        <label>Password</label>
        <input
          type="password"
          value={password}
          onChange={(e) => setPassword(e.target.value)}
          required
        />
      </div>
      <button type="submit">Login</button>
    </form>
  );
};

export default LoginPage;

Next.js에 Redux를 적용하며 마주하게 된 사사로운 오류사항들

가장 많이 언급되는 불편함: 새로고침 하면 날라가요 ,,,

이를 해결하기 위한 몇가지 방법이 있다.

아. 일단 왜 이런 문제가 발생하냐면, 브라우저를 새로고침 하면 페이지 전체를 다시 로드하기 때문에 Redux 상태가 초기화된다.

첫번째 해결방법) redux-persist 라이브러리 사용

간략한 사용법 설명

npm install redux-persist

2. 스토어 설정

   // lib/store.ts
   import { configureStore } from '@reduxjs/toolkit';
   import { persistStore, persistReducer } from 'redux-persist';
   import storage from 'redux-persist/lib/storage'; // 기본적으로 localStorage 사용
   import rootReducer from './rootReducer'; // 모든 리듀서를 합친 rootReducer
   

const persistConfig = { key: 'root', storage, // localStorage에 저장 };

const persistedReducer = persistReducer(persistConfig, rootReducer);

export const store = configureStore({ reducer: persistedReducer, });

export const persistor = persistStore(store);

<br>

3. Provider 설정
<br>

// app/layout.tsx 'use client';

import './globals.css'; import { Provider } from 'react-redux'; import { store, persistor } from '../lib/store'; import { PersistGate } from 'redux-persist/integration/react'; import Header from '../components/Header';

export default function RootLayout({ children }: { children: React.ReactNode }) { return (

<br>


redux-persist의 PersistGate를 사용하여, 스토어가 복원되기 전까지 앱을 지연시킬 수 있다.

<br>



만약 세션 중에만 상태를 유지하고 싶다면 redux-persist/lib/storage/session을 사용할 수 있다.

<br>


__단점__
- 스토리지의 크기가 제한적이고, 복잡한 상태 관리에는 다소 비효율적일 수 있습니다.
상태가 커질수록 브라우저 로딩 시간이 길어질 수 있음.








<br><br>

**두번째 해결방법) localStorage나 sessionStorage 직접 사용**
<br>


1. store가 업데이트 될 때마다 localStorage에 상태 저장
<br>

<br>


__장점__
- redux-persist보다 가볍고, 직접 제어 가능.
- 상태가 단순한 경우 빠르게 적용 가능.
<br>
__단점__
- 수동으로 상태 직렬화/역직렬화를 관리해야 하므로 코드 복잡도가 약간 증가.
- 상태가 클 경우 저장 성능에 영향을 줄 수 있음.






<br>
<br>


**세번째 해결방법) 쿠키 사용**

<br>

쿠키를 사용하여 상태를 저장할 수 있지만, 쿠키는 브라우저가 서버에 전송하는 용도로 주로 사용되므로 큰 데이터를 저장하는 데는 부적합하다. 그러나 인증 정보나 작은 상태값을 저장하는 데에는 적합.

<br>

<br>



__장점__
- 인증 정보나 작은 상태 저장에 적합.
- 서버 사이드 렌더링(SSR)과 쉽게 연동 가능.
<br>
__단점__
- 쿠키는 용량 제한이 있으므로 큰 데이터를 저장할 수 없음.
- 보안 이슈가 있을 수 있으며, 민감한 정보는 적절히 암호화 필요.





<br><br>





**네번째 해결방법) 서버 사이드에서 상태 저장**

<br>

Next.js의 API Routes를 활용하여 서버에 상태를 저장하고, 필요할 때 API를 통해 불러오는 방법.


<br>

<br>

새로고침 시 상태가 서버로부터 복원될 수 있도록 useEffect로 API를 호출하여 상태를 불러오고, 저장할 때는 API로 상태를 보낸다. 

<br>


__장점__
- 큰 데이터를 저장하거나, 보안이 필요한 상태 관리에 적합.
- 서버에서 관리되므로 클라이언트 측의 저장 용량 한계를 걱정할 필요 없음.
<br>
__단점__
- 상태 저장 및 불러오는 로직이 복잡해질 수 있음.
- 상태 저장/복원 시 네트워크 지연이 발생할 수 있음.


<br>



<br>

**나는 위 방법들 중에 localStorage 직접 설정을 택했다.**

<br>

redux-persist 는 나중에 사용해보도록 하자 ~

<br><br>




#### localStorage에 직접 설정하기
<br>

<br>

이런식으로 작성했더니 타입 오류가 났다.

<br>


makeStore 함수에 직접적으로 subscribe 메서드를 호출하려고 했기 때문이다. 

makeStore 함수는 store를 반환하는 함수이지 store 자체가 아니다.

(makeStore 함수가 호출된 후에 반환된 store 인스턴스를 사용해야 함)



<br>




코드를 수정해준 후, 디버깅을 해보았는데 store를 참조하고 있지 않았다.

(그래서 자꾸 데이터가 보존되지 않고 날아감)


<br>


각 store는 name에 따라 식별되고 있는데, localStorage에서 가져온 이 데이터가 어느 store에 대한 데이터인지 매칭이 안되고 있었다. 



<br>

따라서 아래와 같이 수정해주었다. 

const parsedState = JSON.parse(serializedState);

// 로컬 스토리지의 상태를 rootReducer의 구조에 맞게 변환
return {
  userAuth: parsedState, // userAuth로 감싸기
};

<br><br>


이상으로 Redux 적용기 1탄을 마무리해보도록 하겠다. 




<br><br>


~~velog 예쁘고 가독성 있게 작성하는거 왜케 어려워 ...~~

export const getServerSideProps: GetServerSideProps = async (context) => {
  try {
    const { menuId } = context.query;
    const response = await axios.get<CategoryType[]>(
      "http://localhost:8080/category/get/menu",
      {
        headers: {
          "Content-Type": "application/json",
          "Access-Control-Allow-Origin": "*",
        },
        params: {
          menuId: menuId,
        },
      }
    );
    const data = response.data;
    console.log(data);
    return {
      props: {
        CategoryData: data,
      },
    };
  } catch (err) {
    console.log(err);
    return {
      props: {},
    };
  }
};

export NODE_OPTIONS="--max-old-space-size=8192"

// 직접 무효화 하기 전까지는 이 request는 캐싱됨.
// `getStaticProps`와 비슷! (즉, 빌드 시점에 fetch)
// `force-cache`가 디폴트 값이므로 생략 가능
fetch(URL, { cache: 'force-cache' });

// 매번 요청 때마다 refetch 됨.
// `getServerSideProps`와 비슷!
fetch(URL, { cache: 'no-store' });

// 이 request는 10초동안 캐싱됨.
// This request should be cached with a lifetime of 10 seconds.
// `revalidate` 옵션을 지정한 `getStaticProps`와 비슷!
fetch(URL, { next: { revalidate: 10 } });