실무에서 검색 기능을 구현할 때 이런 고민을 해보신 적 있으신가요?

"이건 데이터 조회니까 useQuery를 써야 하나? 아니면 버튼 클릭 시에만 실행되어야 하니까 useMutation을 써야 하나?"

더 나아가 복잡한 필터 조건을 가진 검색 API는 GET이 아닌 POST로 요청해야 하는 경우도 많습니다. REST 원칙상 조회는 GET을 사용해야 하지만, 실무에서는 다음과 같은 이유로 POST를 사용합니다:

• URL 길이 제한 (2048자)
• 복잡한 객체 구조를 query string으로 변환하는 어려움
• 배열, 중첩 객체 등 복잡한 필터 조건 전달의 불편함
• 보안상 민감한 검색 조건을 URL에 노출하지 않기 위함

이런 상황에서 useQuery와 useMutation 중 어느 것을 선택해도 아쉬운 점이 생깁니다. 이 글에서는 두 가지의 장점을 결합한 useQueryMutation 패턴을 소개합니다.

문제 상황

useQuery의 한계

React Query의 useQuery는 데이터 조회에 최적화된 훅입니다. 하지만 검색 기능 구현 시 다음과 같은 문제가 있습니다:

1. 초기 렌더링 시 자동 실행

// 문제: 컴포넌트가 마운트되자마자 API 호출됨
const { data } = useQuery({
  queryKey: ['products', filters],
  queryFn: () => fetchProducts(filters),
});

사용자가 검색 버튼을 클릭하지 않았는데도 API가 호출됩니다.

2. enabled 옵션 사용 시 코드 복잡도 증가

const [shouldFetch, setShouldFetch] = useState(false);

const { data } = useQuery({
  queryKey: ['products', filters],
  queryFn: () => fetchProducts(filters),
  enabled: shouldFetch, // 추가 상태 관리 필요
});

const handleSearch = () => {
  setShouldFetch(true); // 상태 변경으로 쿼리 실행
};

검색을 제어하기 위해 별도의 상태를 관리해야 하고, 코드가 장황해집니다.

3. queryKey 의존성 변경 시 의도치 않은 재실행

const { data } = useQuery({
  queryKey: ['products', filters], // filters가 변경되면 자동 재실행
  queryFn: () => fetchProducts(filters),
  enabled: shouldFetch,
});

// 문제: 필터를 변경하는 순간 API가 호출됨 (검색 버튼을 누르지 않았는데도)
const handleFilterChange = (newFilters) => {
  setFilters(newFilters); // queryKey 변경 → 자동 refetch
};

useMutation의 한계

반대로 useMutation을 사용하면 어떨까요?

const { mutate, data } = useMutation({
  mutationFn: (filters: ProductFilters) => fetchProducts(filters),
});

const handleSearch = () => {
  mutate(filters); // 수동 실행 ✅
};

수동 실행은 가능하지만, 다음과 같은 Query의 강력한 기능들을 사용할 수 없습니다:

• 캐싱: 같은 조건으로 재검색 시 캐시된 데이터 사용 불가
• keepPreviousData: 새 데이터 로딩 중 이전 데이터 유지 불가 (화면 깜빡임)
• staleTime: 데이터 신선도 관리 불가
• gcTime: 메모리 효율적인 캐시 정리 불가
• refetchOnMount, refetchOnWindowFocus: 세밀한 refetch 제어 불가

해결 방법: useQueryMutation

useQueryMutation은 Query의 캐싱/최적화 기능과 Mutation의 수동 실행을 결합한 커스텀 훅입니다.

핵심 아이디어

1. 내부 상태로 variables 관리: useState로 요청 파라미터를 내부에서 관리
2. Lazy Execution: enabled: !!variables로 variables가 설정될 때만 쿼리 실행
3. Dynamic Query Key: variables를 queryKey에 포함하여 검색 조건별 캐싱
4. Mutation-like API: mutate() 함수로 수동 실행

구현 코드

import {
  keepPreviousData,
  useQuery,
  UseQueryOptions,
} from '@tanstack/react-query';
import { useCallback, useState } from 'react';

interface UseQueryMutationOptions<TData, TError = Error, TVariables = void> {
  queryKey: unknown[];
  queryFn: (variables: TVariables) => Promise<ApiResponse<TData>>;
  queryOptions?: Omit<
    UseQueryOptions<ApiResponse<TData>, TError, ApiResponse<TData>, readonly unknown[]>,
    'queryKey' | 'queryFn'
  >;
}

export function useQueryMutation<
  TData = unknown,
  TError = Error,
  TVariables extends Record<string, any> | null | undefined = Record<string, any>,
>({ queryKey, queryFn, queryOptions }: UseQueryMutationOptions<TData, TError, TVariables>) {
  // 1. 요청 파라미터를 내부 상태로 관리
  const [variables, setVariables] = useState<TVariables | null>(null);

  // 2. useQuery 래핑
  const query = useQuery<ApiResponse<TData>, TError, ApiResponse<TData>, readonly unknown[]>({
    // variables를 queryKey에 포함하여 검색 조건별 캐싱
    queryKey: generateQueryKeysFromUrl(queryKey + createQueryString(variables)),
    queryFn: () => queryFn(variables!),

    // 핵심: variables가 설정될 때만 실행
    enabled: !!variables,

    // 기본 최적화 설정
    retry: 1,
    refetchOnMount: false,
    refetchOnWindowFocus: false,
    staleTime: 1000 * 60 * 5,        // 5분간 캐시 유지
    gcTime: 1000 * 60 * 10,          // 10분 후 메모리에서 정리
    placeholderData: keepPreviousData, // 로딩 중 이전 데이터 유지

    // 사용자 정의 옵션으로 오버라이드 가능
    ...queryOptions,
  });

  // 3. Mutation처럼 사용할 수 있는 mutate 함수
  const mutate = useCallback((newVariables: TVariables) => {
    setVariables(newVariables); // 상태 변경 → useQuery 자동 실행
  }, []);

  // 4. Query의 모든 상태 + mutate 함수 반환
  return {
    ...query,
    mutate,
  };
}

동작 원리

1. 초기 상태: variables가 null이므로 enabled: false → 쿼리 실행 안 됨
2. mutate 호출: mutate(params) 호출 → variables 상태 업데이트
3. 자동 실행: variables가 설정되어 enabled: true → 쿼리 자동 실행
4. 캐싱: queryKey에 variables 포함 → 같은 조건 재검색 시 캐시 사용
5. UX 최적화: keepPreviousData로 로딩 중에도 이전 데이터 유지

ApiResponse 패턴

실무에서는 백엔드 응답 구조가 정형화되어 있는 경우가 많습니다. 우리 프로젝트에서는 다음과 같은 응답 구조를 사용합니다:

export interface ApiResponse<T> {
  status: 'success' | 'fail';
  code: string;
  message: string;
  token: string;
  data: T;  // 실제 응답 데이터
}

useQueryMutation은 이러한 래핑된 응답 구조를 제네릭으로 처리하여, 타입 안정성을 유지하면서도 일관된 API를 제공합니다.

실제 사용 예시

프로젝트에서 실제로 사용하고 있는 패턴들을 소개합니다.

1. 기본 패턴: API 훅 생성

먼저 타입을 정의합니다:

// types.ts
export interface ProductListRequest {
  pageIndex: number;
  pageCount: number;
  categoryL?: string;
  categoryM?: string;
  categoryS?: string;
  keyword?: string;
}

export interface ProductItem {
  productId: string;
  productName: string;
  category: string;
  price: number;
}

export interface ProductListResponse {
  productItemList: ProductItem[];
  totalCount: number;
}

API 함수를 작성합니다:

// useProductList.ts
import { ApiResponse, axiosInstance } from '@/shared/api';
import { API_ENDPOINTS } from '@/shared/constants';
import { useQueryMutation } from '@/shared/hooks';
import { ProductListRequest, ProductListResponse } from './types';

const fetchProductList = async ({ pageCount = 30, ...body }: ProductListRequest) => {
  const { data } = await axiosInstance.post<ApiResponse<ProductListResponse>>(
    API_ENDPOINTS.PRODUCT.LIST, // '/v3/product/list'
    { ...body, pageCount },
  );
  return data; // ApiResponse<ProductListResponse> 반환
};

export const useProductList = () => {
  return useQueryMutation<ProductListResponse, Error, ProductListRequest>({
    queryKey: [API_ENDPOINTS.PRODUCT.LIST],
    queryFn: fetchProductList,
  });
};

2. 컴포넌트에서 사용

import { useProductList } from '@/features/product/api';

const ProductSearchModal = () => {
  const {
    mutate: searchProducts,
    data,
    isPending,
    isError
  } = useProductList();

  const [filters, setFilters] = useState({
    categoryL: '',
    keyword: '',
  });

  const handleSearch = () => {
    searchProducts({
      pageIndex: 1,
      pageCount: 30,
      categoryL: filters.categoryL,
      keyword: filters.keyword,
    });
  };

  const handlePageChange = (page: number) => {
    searchProducts({
      pageIndex: page,
      pageCount: 30,
      categoryL: filters.categoryL,
      keyword: filters.keyword,
    });
  };

  return (
    <div>
      <input
        value={filters.keyword}
        onChange={(e) => setFilters({ ...filters, keyword: e.target.value })}
      />
      <button onClick={handleSearch}>검색</button>

      <Spin spinning={isPending}>
        {data?.data?.productItemList.map((product) => (
          <ProductCard key={product.productId} product={product} />
        ))}
      </Spin>

      <Pagination
        total={data?.data?.totalCount || 0}
        onChange={handlePageChange}
      />
    </div>
  );
};

장점:

• 필터를 변경해도 즉시 API 호출 안 됨 (useQuery의 문제 해결)
• 검색 버튼 클릭 시에만 mutate() 호출
• 같은 조건으로 재검색 시 캐시된 데이터 사용
• 페이지 변경 시 keepPreviousData로 이전 데이터 유지 (깜빡임 없음)

3. 고급 패턴: 초기 로딩 자동화

컴포넌트가 마운트될 때 기본값으로 자동 검색이 필요한 경우:

// useAlarmList.ts
export const useAlarmList = (params?: { pageCount?: number; state?: string }) => {
  const queryMutate = useQueryMutation<AlarmListResponse, Error, AlarmListRequest>({
    queryKey: [API_ENDPOINTS.HISTORY.ALARM.LIST],
    queryFn: fetchAlarmList,
  });

  // 초기 로딩: 기본값으로 자동 실행
  useEffect(() => {
    const defaultFormData = getDefaultFormValues(); // { state: 'all', pageIndex: 1 }
    const requestData = {
      ...defaultFormData,
      pageIndex: 1,
      pageCount: params?.pageCount ?? 20,
      state: params?.state ?? null,
    };

    queryMutate.mutate(requestData);
  }, []); // 마운트 시 한 번만

  return queryMutate;
};

사용:

const AlarmListPage = () => {
  const { data, isPending, mutate } = useAlarmList({ pageCount: 30 });

  // 마운트 시 자동으로 pageCount: 30으로 알림 조회
  // 이후에는 mutate()로 수동 제어 가능

  return (
    <div>
      <AlarmList items={data?.data?.alarmList || []} />
      <button onClick={() => mutate({ state: 'unread', pageIndex: 1, pageCount: 30 })}>
        읽지 않은 알림만 보기
      </button>
    </div>
  );
};

4. 캐시 전략 커스터마이징

데이터 특성에 따라 캐시 전략을 다르게 설정할 수 있습니다:

실시간 데이터 (캐시 사용 안 함)

// useAssetList.ts
export const useAssetListQuery = () => {
  return useQueryMutation<AssetListResponse, Error, AssetListRequest>({
    queryKey: [API_ENDPOINTS.ASSET.LIST],
    queryFn: fetchAssetList,
    queryOptions: {
      staleTime: 0,  // 항상 stale 상태 (즉시 refetch)
      gcTime: 0,     // 즉시 메모리에서 제거
    },
  });
};

정적 데이터 (캐시 적극 활용)

// usePriceOverviewList.ts
export const usePriceOverviewList = () => {
  return useQueryMutation<PriceOverviewListResponse, Error, PriceOverviewListRequest>({
    queryKey: [API_ENDPOINTS.REPORT.PRICE_OVERVIEW.LIST],
    queryFn: fetchPriceOverviewList,
    queryOptions: {
      staleTime: 5 * 60 * 1000,  // 5분간 캐시 유지
      gcTime: 10 * 60 * 1000,    // 10분 후 메모리에서 제거
      retry: 2,                  // 실패 시 2번 재시도
    },
  });
};

5. 복잡한 폼 상태와 통합

React Hook Form과 함께 사용하는 패턴:

const AssetsView = () => {
  const { control, watch } = useFormContext<FilterFormData>();
  const { mutate: fetchAssets, data, isPending } = useAssetListQuery();

  const [keyword, filters, currentPage, pageCount] = watch([
    'keyword',
    'filters',
    'currentPage',
    'pageCount',
  ]);

  // 폼 상태를 API 요청 파라미터로 변환
  const queryParams = useMemo(() => {
    if (!filters || currentPage === undefined) {
      return null;
    }
    return {
      keyword: keyword || '',
      startDate: filters.startDate,
      endDate: filters.endDate,
      siteList: filters.siteList,
      categoryList: filters.categoryList,
      pageIndex: currentPage,
      pageCount: pageCount || 20,
    };
  }, [keyword, filters, currentPage, pageCount]);

  // 폼 상태 변경 시 자동 검색
  useEffect(() => {
    if (!queryParams) return;
    fetchAssets(queryParams);
  }, [queryParams, fetchAssets]);

  return (
    <div>
      <FilterForm />
      <Spin spinning={isPending}>
        <AssetList items={data?.data?.assetInfoList || []} />
      </Spin>
    </div>
  );
};

주의사항

1. 초기 렌더링 시 자동 실행이 필요한 경우

useEffect로 초기 로딩 처리:

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

2. 실시간 데이터 처리

캐시가 오히려 문제가 되는 경우 staleTime: 0 설정:

queryOptions: {
  staleTime: 0,
  gcTime: 0,
}

3. 메모리 관리

불필요한 캐시 축적 방지를 위해 적절한 gcTime 설정:

queryOptions: {
  gcTime: 1000 * 60 * 5, // 5분 후 정리
}

4. 타입 안정성

제네릭 타입을 명시적으로 정의하여 타입 추론 오류 방지:

useQueryMutation<
  ResponseType,  // TData
  Error,         // TError
  RequestType    // TVariables
>({ ... })

결론

useQueryMutation은 실무의 복잡한 검색/필터 요구사항을 해결하는 실용적인 패턴입니다.

언제 사용하면 좋을까요?:

• ✅ 검색/필터 기능
• ✅ POST로 데이터 조회하는 API
• ✅ 사용자 액션 기반 데이터 로딩
• ✅ 페이지네이션 + 필터 조합
• ❌ 단순 GET 조회 (useQuery 사용)
• ❌ 실제 데이터 변경 (useMutation 사용)

React Query를 사용하면서 검색 기능 구현에 어려움을 겪고 계셨다면, useQueryMutation 패턴을 적용해보시기 바랍니다. 코드가 간결해지고, 성능이 향상되며, 사용자 경험도 개선될 것입니다.

🎯 알게 될 점

• React Query mutation의 3가지 onSuccess 실행 방식 이해
• mutate vs mutateAsync 차이점과 선택 기준
• 컴포넌트 언마운트 시 발생하는 문제와 해결법
• 실제 프로젝트에서 사용할 수 있는 베스트 프랙티스

📖 React Query Mutation의 3가지 패턴

React Query에서 mutation 성공 후 처리는 크게 3가지 방식으로 할 수 있습니다.

1. 훅 레벨에서 onSuccess 정의

const useCreatePackage = () => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: createPackage,
    onSuccess: (data) => {
      // 🔥 이 훅을 사용하는 모든 mutate 호출에서 실행
      queryClient.invalidateQueries(['packages']);
    },
  });
};

특징:

• 해당 훅으로 생성한 모든 mutation이 성공할 때마다 실행
• 캐시 무효화, 전역 상태 업데이트 등 공통 로직에 적합
• 컴포넌트 마운트 상태와 무관하게 실행

2. mutate 호출 시 onSuccess 전달

const { mutate } = useCreatePackage();

mutate(packageData, {
  onSuccess: (data) => {
    // 🔥 이 특정 mutate 호출에만 실행
    navigate('/packages');
    setModalOpen(false);
  },
});

특징:

• 특정 mutate 호출에만 실행
• 컴포넌트별 특수한 처리(네비게이션, 모달 닫기 등)에 적합
• ⚠️ 컴포넌트가 언마운트되면 실행되지 않음

3. mutateAsync로 Promise 처리

const { mutateAsync } = useCreatePackage();

try {
  const result = await mutateAsync(packageData);
  // 🔥 성공 시 여기서 처리
  navigate('/packages');
  showSuccessMessage();
} catch (error) {
  // 🔥 실패 시 여기서 처리
  showErrorMessage(error);
}

특징:

• Promise를 반환하여 await으로 결과 대기
• 복잡한 흐름 제어, 순차적 처리에 적합
• try/catch로 명시적인 에러 처리 가능

⚡ mutate vs mutateAsync: 언제 뭘 써야 할까?

mutate: Fire and Forget 방식

const { mutate } = useMutation({ mutationFn: updateUser });

// 🔥 비동기 작업을 시작하고 바로 다음 코드 실행
mutate(userData, {
  onSuccess: (data) => console.log('성공!', data),
  onError: (error) => console.log('실패!', error),
});

console.log('이 코드는 mutation 완료를 기다리지 않고 즉시 실행됨');

mutateAsync: Promise 기반 처리

const { mutateAsync } = useMutation({ mutationFn: updateUser });

try {
  console.log('mutation 시작');
  const result = await mutateAsync(userData);
  console.log('성공!', result);
  // 성공 후에만 실행되는 코드
  navigate('/success');
} catch (error) {
  console.log('실패!', error);
  // 실패 후에만 실행되는 코드
  setError(error.message);
}

console.log('mutation 완료 후 실행됨');

선택 기준표

🚨 자주 빠지는 함정들과 해결법

함정 1: 컴포넌트 언마운트 시 onSuccess 미실행

이것은 React Query를 사용할 때 가장 흔히 겪는 문제 중 하나입니다.

// ❌ 위험한 패턴
const CreateItemPage = () => {
  const { mutate } = useMutation({ mutationFn: api.create });

  const handleSubmit = () => {
    mutate(data, {
      onSuccess: () => {
        // 컴포넌트가 언마운트되면 실행되지 않음!
        navigate('/other-page');
        showSuccessToast();
      },
    });

    // mutate 호출 직후 다른 페이지로 이동하면?
    navigate('/loading-page'); // onSuccess가 실행되지 않을 수 있음
  };
};

해결법: 훅 레벨에서 처리

// ✅ 안전한 패턴
const useCreateItem = () => {
  const navigate = useNavigate();

  return useMutation({
    mutationFn: api.create,
    onSuccess: () => {
      // 훅 레벨에서 처리하여 컴포넌트 언마운트와 무관
      navigate('/success-page');
      showSuccessToast();
    },
  });
};

함정 2: 여러 번 연속 mutate 호출 시 예상과 다른 동작

const { mutate } = useMutation({ mutationFn: api.create });

// ❌ 문제가 될 수 있는 패턴
['item1', 'item2', 'item3'].forEach(item => {
  mutate(item, {
    onSuccess: () => {
      console.log('완료!'); // 마지막 호출에 대해서만 실행될 수 있음
    },
  });
});

해결법: 훅 레벨에서 공통 처리

// ✅ 안전한 패턴
const { mutate } = useMutation({
  mutationFn: api.create,
  onSuccess: (data, variables) => {
    console.log(`${variables} 완료!`); // 모든 호출에 대해 실행
  },
});

['item1', 'item2', 'item3'].forEach(item => {
  mutate(item);
});

함정 3: onSuccess 실행 순서 오해

React Query는 정해진 순서로 onSuccess를 실행합니다.

const mutation = useMutation({
  mutationFn: createItem,
  onSuccess: (data) => {
    console.log('1️⃣ 훅 레벨 onSuccess 실행');
  },
});

mutation.mutate(data, {
  onSuccess: (data) => {
    console.log('2️⃣ mutate 레벨 onSuccess 실행');
  },
});

// 실행 순서: 1️⃣ → 2️⃣

💡 실전 사용 예시

예시 1: 패키지 생성 (역할 분리 패턴)

// API 훅 - 데이터 관련 공통 로직
export const usePackageCreate = () => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: createPackage,
    onSuccess: () => {
      // 항상 실행되어야 하는 데이터 동기화
      queryClient.invalidateQueries(['packages']);
    },
  });
};

// 컴포넌트 - UI 관련 특수 처리
const PackageCreatePage = () => {
  const { mutate } = usePackageCreate();
  const { openModal } = useModalStore();
  const navigate = useNavigate();

  const handleSubmit = (data) => {
    mutate(data, {
      onSuccess: () => {
        // 이 페이지에서만 필요한 UI 처리
        openModal({
          title: '패키지가 생성되었습니다',
          onConfirm: () => navigate('/packages'),
        });
      },
    });
  };
};

예시 2: 복잡한 흐름 제어 (mutateAsync 활용)

const BusinessSearchModal = () => {
  const { mutateAsync: searchBusiness } = useBusinessSearch();
  const { mutateAsync: saveRecentSearch } = useSaveRecentSearch();

  const handleSearch = async (searchData) => {
    try {
      setLoading(true);

      // 1단계: 사업자 정보 검색
      const { data, status } = await searchBusiness(searchData);

      if (status === 'success') {
        // 2단계: 성공 시 최근 검색어 저장
        await saveRecentSearch(searchData);

        // 3단계: 결과 표시
        onSearchComplete(data);
      }
    } catch (error) {
      setError(error.message);
    } finally {
      setLoading(false);
    }
  };
};

예시 3: 낙관적 업데이트 패턴

const BookmarkButton = ({ item, isBookmarked }) => {
  const { mutateAsync } = useBookmarkToggle();
  const [optimisticBookmark, setOptimisticBookmark] = useState(isBookmarked);

  const handleToggle = async () => {
    const newBookmarkState = !optimisticBookmark;

    // 즉시 UI 업데이트 (낙관적 업데이트)
    setOptimisticBookmark(newBookmarkState);

    try {
      await mutateAsync({
        bookmark: newBookmarkState,
        itemId: item.id,
      });

      // 성공 시 추가 처리
      showToast(`북마크가 ${newBookmarkState ? '추가' : '제거'}되었습니다`);

    } catch (error) {
      // 실패 시 원래 상태 복원
      setOptimisticBookmark(isBookmarked);
      showErrorToast('북마크 처리에 실패했습니다');
    }
  };
};

🏆 베스트 프랙티스

1. 역할 분리 원칙

데이터 로직은 훅에서, UI 로직은 컴포넌트에서

// ✅ 권장: 명확한 역할 분리
const useItemCreate = () => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: createItem,
    onSuccess: () => {
      // 🎯 데이터 관련 로직만
      queryClient.invalidateQueries(['items']);
    },
  });
};

const ItemCreatePage = () => {
  const { mutate } = useItemCreate();

  const handleSubmit = (data) => {
    mutate(data, {
      onSuccess: () => {
        // 🎯 UI 관련 로직만
        showSuccessToast('아이템이 생성되었습니다');
        navigate('/items');
      },
    });
  };
};

2. 타입 안전성 확보

interface CreateItemRequest {
  name: string;
  description: string;
}

interface CreateItemResponse {
  id: number;
  name: string;
  createdAt: string;
}

const useItemCreate = () => {
  return useMutation<
    CreateItemResponse,
    Error,
    CreateItemRequest
  >({
    mutationFn: createItem,
    onSuccess: (data, variables) => {
      // data: CreateItemResponse (타입 추론됨)
      // variables: CreateItemRequest (타입 추론됨)
      console.log(`생성된 아이템 ID: ${data.id}`);
    },
  });
};

3. 재사용 가능한 패턴 만들기

// 공통 mutation 훅 패턴
const useOptimisticMutation = <TData, TVariables>(
  mutationFn: MutationFunction<TData, TVariables>,
  queryKey: string[],
  options?: UseMutationOptions<TData, Error, TVariables>
) => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn,
    onSuccess: () => {
      queryClient.invalidateQueries(queryKey);
    },
    onError: (error) => {
      console.error('Mutation failed:', error);
    },
    ...options,
  });
};

// 사용
const usePackageCreate = () =>
  useOptimisticMutation(createPackage, ['packages']);

const useItemCreate = () =>
  useOptimisticMutation(createItem, ['items']);

4. 에러 처리 표준화

const useCreateItem = () => {
  return useMutation({
    mutationFn: createItem,
    onSuccess: (data) => {
      queryClient.invalidateQueries(['items']);
    },
    onError: (error) => {
      // 공통 에러 처리
      console.error('Item creation failed:', error);

      // 사용자에게 친화적인 에러 메시지 표시
      const userMessage = error.code === 'VALIDATION_ERROR'
        ? '입력값을 확인해주세요'
        : '서버 오류가 발생했습니다';

      showErrorToast(userMessage);
    },
  });
};

🎉 마무리

React Query의 mutation은 올바르게 사용하면 매우 강력한 도구가 됩니다. 핵심은 역할을 명확히 분리하고, 컴포넌트 생명주기를 고려하여 적절한 패턴을 선택하는 것입니다.

기억해야 할 핵심 포인트:

• 공통 로직은 훅 레벨 onSuccess에서
• UI 특화 로직은 mutate 호출 시 onSuccess에서
• 복잡한 흐름은 mutateAsync로
• 컴포넌트 언마운트 가능성을 항상 고려하기

이 가이드가 React Query mutation을 더 안전하고 효율적으로 사용하는 데 도움이 되었기를 바랍니다. 실제 프로젝트에 적용해보시고, 궁금한 점이나 개선할 부분이 있다면 언제든 피드백 주세요! 🚀

IoC는 프로그래머가 작성한 프로그램이 재사용 라이브러리의 흐름 제어를 받게 되는 소프트웨어 디자인 패턴을 말한다. 전통적인 프로그래밍에서 흐름은 프로그래머가 작성한 프로그램이 외부 라이브러리의 코드를 호출해 이용한다. 하지만 제어 반전이 적용된 구조에서는 외부 라이브러리의 코드가 프로그래머가 작성한 코드를 호출한다. 설계 목적상 제어 반전의 목적은 다음과 같다.

• 작업을 구현하는 방식과 작업 수행 자체를 분리한다.
• 모듈을 제작할 때, 모듈과 외부 프로그램의 결합에 대해 고민할 필요 없이 모듈의 목적에 집중할 수 있다.
• 모듈을 바꾸어도 다른 시스템에 부작용을 일으키지 않는다.

DI(Dependency injection)

IoC 컨테이너가 직접 객체의 생명주기를 관리하는 방식이다. 위 사진의 모듈에 클래스들 사이엔 명확한 종속성이나 계층 구조가 있다. 서비스가 올바르게 작동하기 위해서 저장소에 의존하고, 컨트롤러가 올바르게 작동하기 위해서는 서비스에 의존한다.

export class UsersController {
    constructor(private readonly usersService: UsersService) {}
        ...
}

UsersController는 UsersService에 의존하고 있지만 UsersService 객체의 라이프 사이클에는 전혀 관여하지 않고 있다. 어디선가 자신의 생성자에 주어지는 객체를 가져다 쓰고 있을 뿐이다. 이 역할을 하는것이 IoC 다.

DI는 이렇게 IoC 컨테이너가 직접 객체의 생명주기를 관리하는 방식이다. 예를 들어 A 객체에서 B객체가 필요하다고 할 때, A 클래스에는 B 클래스를 직접 생성하여 사용할 수 있다. 여기서 B의 구현체가 변경되면 문제가 발생한다. A는 B를 직접 참조하고 있으므로 B가 변경될 때마다 컴파일러는 A를 다시 컴파일 해야한다.

이를 해결하려면 B에 대한 인터페이스 IB를 정의하고, A에서는 IB 타입을 이용하면 된다. 하지만 IB의 구현체 B1, B2 등을 직접 생성해야 하는 것은 여전하다. 여기서 IoC의 강력함이 발휘되는 것이다.

IoC를 사용하지 않은 코드와 사용한 코드를 비교해보자

IoC사용 X

export interface Person {
  getName: () => string;
}

@Injectable()
export class Dexter implements Person {
  getName() {
    return 'Dexter';
  }
}

@Injectable()
export class Jane implements Person {
  getName() {
    return 'Jane';
  }
}

class MyApp {
    constructor(private person: Person) {}
}

L1~17: Person 인터페이스를 구현하는 2개의 클래스 Dexter, Jane이 있다. 각 클래스는 getName 함수의 구현체가 다르다.

L19~24: MyApp 클래스는 Person 타입의 멤버 변수를 가지고 생성자에서 구현체를 생성.

IoC 사용 O

class MyApp {
    constructor(@Inject('Person') private person: Person) { }
}

이제 Person 객체의 관리는 IoC가 담당한다. Person은 interface인데 Person을 실제로 구현한 클래스를 어디선가 정의를 해두어야 객체를 생성할 수가 있을 것이다. 이는 모듈에서 선언한다.

@Module({
  controllers: [UsersController],
  providers: [
        UsersService,
    {
      provide: 'Person',
      useClass:Dexter
    }
  ]
})
export class UserssModule {}

객체로 선언할 때 provide 속성에 토큰을 'Person'으로 주고 있다. 이 토큰은 프로바이더를 가져다 쓸 때 @Inject 데코레이터의 인자로 넘겨준 것과 같다. 만약 Dexter 객체가 아니라 Jane으로 구현을 바꾸고자 한다면 useClass 속성의 클래스 이름만 바꾸면 된다.

@Module({
  controllers: [UsersController],
  providers: [
        UsersService,
    {
      provide: 'Person',
      useClass:Jane
    }
  ]
})
export class UserssModule {}

DI 기능 비유

고문관한테 아 제발 넌 아무것도 하지마. 그냥 뭐 필요한 거 있으면 얘기해 내가 도와줄테니까. 너는 뭐 하려는 능력을 키우지마, 그냥 부탁해 니 능력 내가 대신 해줄게. 그러니까 DI는 어떤 것을 필요할 때 필요하다고 말만 하면 프레임워크가 알잘딱해주는 것이다. 이렇게 프로그램에게 뭐 필요하다 요청을 통해 객체 간의 의존성을 낮출 수 있다.

1. Incoming request
2. Globally bound middleware
3. Module bound middleware
4. Global guards
5. Controller guards
6. Route guards
7. Global interceptors (pre-controller)
8. Controller interceptors (pre-controller)
9. Route interceptors (pre-controller)
10. Global pipes
11. Controller pipes
12. Route pipes
13. Route parameter pipes
14. Controller (method handler)
15. Service (if exists)
16. Route interceptor (post-request)
17. Controller interceptor (post-request)
18. Global interceptor (post-request)
19. Exception filters (route, then controller, then global)
20. Server response

1. 깃헙 레포지토리를 새로 파서 build된 폴더(dist), package.json, package-lock.json 이 3개만 올려두시는 거를 추천합니다. 뭐 엄청 좋은 인스턴스 대여 할 것도 아닐테니 깡 코드 빌드돌리면 뻑이 날 수도 있기 때문입니다.
2. package.json에 start:prod 내용 바꿔주기

"start:prod": "pm2 start dist/main.js"

VPS: 가상 사설 서버 구축

1. AWS Lightsail 페이지로 이동

바로 인스턴스 생성 들어가줍니다.

위 사진처럼 플랫폼은 Linux/Unix 선택 후 밑의 OS전용 탭에서 Ubuntu골라주시면 됩니다.

인스턴스들은 보다시피 3개가 3개월동안 무료인데 째째하게 3.5달러는 고르지 마시고 최소 5달러짜리로 가셔야합니다. (특별한 이유는 없음)

이름은 하고싶은거 입력하시면 됩니다. 그 후에 특별히 할 거 없고 바로 인스턴스 생성

다 만들고나면 이렇게 생성이 되는데 아직 완전히 만들어 진것은 아니니 담배한대 피고 와줍니다.

다 생성돼서 들어오면 이런 위와같은 창이 뜹니다. 그러면 표시되어있는 SSH를 사용하여 연결을 눌러 인스턴스로 들어가줍니다.

내가 SSH좀 해봤고 내 터미널에서 바로 들어가도록 하고싶다~ 하면은 맨 밑에 따로 설명하겠습니다.

들어오면 위와같은 화면이 뜹니다. 그러면 아래에 있는 명령어들 복붙해서 필요한 것들 깔아줍시다.

명령어

• sudo apt-get update (각종 프로그램 설치 및 버전관리 매니저)
• sudo apt-get -y upgrade (아래같은거 뜨면은 그냥 OK하고 넘어가기)

• sudo apt-get install build-essential (C++, Python등 빌드에 관련한 패키지 묶음 다운로드)
• sudo apt-get install curl (웹 사이트에 접속해서 패키지를 다운받는거)
• curl -sL https://deb.nodesource.com/setup_16.x | sudo -E bash --
• sudo apt-get install -y nodejs
• sudo apt-get install git
• sudo apt-get install vim (우분투에서 쓰는 코드 에디터)
• touch .gitconfig
• git config --global user.name gyomdyung (git config --global user.name [깃허브 닉네임])
• git config --global user.email seastory624@gmail.com (git config --global user.email [깃허브 이메일])
• git config --global --list
• git clone <프로젝트>
• cd repository-name
• npm i (npm i --legacy-peer-deps)
• sudo npm i -g @nestjs/cli@8
• sudo npm i -g pm2
• vi .env (환경변수 붙여 넣기) - 레포지토리에 (중요한).env 파일도 같이 배포하신…..분은 없으실테니 vim 에디터로 만들어줍시다.
• sudo npm run start:prod

npm run 돌렸는데 아래처럼 뭐 이런 에러 뜨면서 안 되면

0|main   | [Nest] 44811  - 02/23/2023, 4:13:54 PM   ERROR [NestApplication] Error: listen EACCES: permission denied 0.0.0.0:80 +3ms
0|main   | Error: listen EACCES: permission denied 0.0.0.0:80

sudo su 커맨드를 입력해서 슈퍼유저로 전환 후에 pm2 start dist/main.js 쳐서 실행해보세요. 그럼 됩니다.

2. 퍼블릭 IP를 고정 IP로 바꾸기

우선 우리 인스턴스 페이지로 가봅시다.

네트워크 탭을 눌러줍시다.

고정 IP연결 누르면은 고정IP로 바뀌면서 퍼블릭 IP 번호도 바뀌었을거에요.

이제 postman에서 [고정IP]/[route] 입력하고 실험해보시면 저렇게 될겁니다.

끝.

번외. 터미널로 SSH 연결하는 법

여기서 기본 키 다운로드 하면 뭐시깽이.pem 프라이빗 키 파일을 다운받게 되는데 그 파일을 적당한 곳에 보관하고 (필자의 경우 - /Users/jangseong-u/.ssh 폴더에 보관)

본론

1. 프라이빗 키를 사용자만 읽고 쓸 수 있도록 하는 작업

sudo chmod 400 /path/to/private-key.pem
# sudo chmod 400 ./LightsailDefaultKey-ap-northeast-2.pem 이런식으로

1. 아래 명령어를 입력하여 SSH를 통해 Lightsail에서 인스턴스에 연결

ssh -i /path/to/private-key.pem ubuntu@public-ip-address
# 해설 ssh -i [pem경로] ubuntu@퍼블릭IP나 고정IP
# ex_)ssh -i ./LightsailDefaultKey-ap-northeast-2.pem ubuntu@6.96.969.696

끝. 만약 안되시면 다른 블로그 글 구글링 하면서 도전해보세요^^

useMemo는 메모이제이션 된 값을 반환하는 Hook이다. Memo는 “memoized”를 의미하며 간단하게 설명하면 이전에 계산한 값을 재사용 한다는 의미정도이고 자세한 내용은 여기에서 확인해주세요^^

랜더링마다 호출되는 컴포넌트 함수

일반적으로 React의 함수형 컴포넌트는 다음과 같은 구조로 작성된다.

const Component = ({a, b}) => {
    const value = 개쩌는_함수(a, b)
  return <OtherComponent>{value}</OtherComponent>
}

컴포넌트 함수는 렌더링이 일어날 때마다 호출이 된다. 함수가 호출 되면 내부 로직들이 돌아가고, 이를 기반으로 JSX문법으로 마크업 된 UI가 리턴된다.

컴포넌트의 렌더링은 앱을 실행했을때 뿐만이 아니라 자기 자신이나 부모 컴포넌트의 상태 변경이 일어날 때도 렌더링 되기도 한다.

만약에 내가 만든 함수가 너무 대단한 나머지 컴퓨터도 연산하기 힘들어하면 컴포넌트의 재 랜더링이 될 때마다 함수가 호출이 되므로 리액트 앱의 성능이 떨어질 것이다.

함수형 컴포넌트에 memoization 적용

랜더링이 일어날 때 마다, 함수의 인자 값들이 항상 바뀌는 게 아니라면 굳이 없을 것이다. 위와 같은 문제는 useMemo Hook을 사용하면 개선할 수 있다.

useMemo Hook의 기본 구조는 아래와 같고 인자들로는 “생성(create)” 함수와 그것의 의존성 값의 배열 2개의 인자를 받는다.

const memoizedValue = useMemo(() => 개쩌는_함수(a, b), [a, b]);

useMemo는 의존성이 변경되었을 때에만 메모이제이션된 값만 다시 계산 할 것입니다. 이 최적화는 모든 렌더링 시의 고비용 계산을 방지하게 해준다.

리액트에서 Ref는 그냥 참조를 의미한다. (reference의 준말)

• ref의 가장 기본적인 기능은 다른 DOM 요소에 접근해 그것들로 작업할 수 있게 해주는 기능이다.
• HTML 작성 시 DOM요소에 이름을 달 경우 id를 사용한다. 이처럼 리액트에서도 DOM을 직접 접근하기 위한 방법이 있는데 이를 ref라고 부른다.

2. Ref를 사용해야 할 때

1. 변화는 감지해야 하지만 그 변화가 렌더링을 발생시키면 안되는 값을 다룰 때

State vs Ref

• State의 변화 → 컴포넌트 렌더링 → 컴포넌트 내부 변수들 초기화
• Ref의 변화 → 렌더링 X → 변수들의 값이 유지됨
  • State의 변화 → 컴포넌트 렌더링 → Ref의 값은 초기화되지 않음

useRef를 사용하여 ref 연결하기

// App.js
import { useRef } from 'react';

function App() {
    const inputEl = useRef(null);

    const onButtonClick = (e) => {
        e.preventDefault();
        console.log(inputEl);
    };

    return (
        <form>
            <input ref={inputEl} type="text" />
            <button onClick={onButtonClick}>보내기</button>
        </form>
    );
}

export default App;

2. DOM 요소에 접근할 때

Javascript에서 querySelector, getElementById같은 DOM API를 리액트에서도 가끔씩 사용을 해줘야 할 때가 있다 (스크롤바 위치 가져오기, 포커스 설정 등). 그럴 때 useRef Hook 함수를 사용한다.

useRef를 사용하여 input에 포커스가 잡히도록 구현

// App.js
import { useEffect, useRef } from 'react';

const App = () => {
    const inputRef = useRef();

    useEffect(() => {
        inputRef.current.focus();
    }, []);

    const greetHandler = () => {
        alert(`안녕하세요. ${inputRef.current.value}님`);
    };

    return (
        <div>
            <input type="text" placeholder="사용자 이름" ref={inputRef} />
            <button onClick={greetHandler}>로그인</button>
        </div>
    );
};

export default App;

끝으로 사용사례 정리

공식문서에서 발췌한 Ref의 바람직한 사용 사례.

• 포커스, 텍스트 선택영역, 혹은 미디어의 재생을 관리할 때.
• 애니메이션을 직접적으로 실행시킬 때.
• 서드 파티 DOM 라이브러리를 React와 같이 사용할 때.

내 경우

• 폼 태그의 데이터 제출용: ref Hook 사용
• 유효성 검증을 위해 매 입력마다 값이 필요한 경우: state Hook을 사용

예) input 태그에서 사용자가 입력한 내용일 관리할 때 state로 관리하는 방법이 있다. 하지만 state로 관리를 하면 매번 키를 누를 때마다 사용자로부터 얻은 값을 업데이트하고, 그것을 state에 저장하고 그 state를 input에 다시 공급한다. 그리고 나중에 그 state를 사용해 인풋을 재설정하고 데이터가 필요한 곳으로 보내기도 한다.

물론 이 방법이 나쁜것은 아니지만 폼 태그에서 제출할 때만 필요한 경우에는 좀 과한 프로세스로 느껴진다. 이 경우 ref를 사용할 수가 있다.

useEffect는 컴포넌트가 Mounting(생성 될 때), Unmounting(제거 할 때), Updating(props나 state가 바뀔 때 등) 특정 작업(구독 설정, API 호출, 컴포넌트의 DOM 수정 등) 처리하는 함수이다.

useEffect는 첫 번째 인자로 작업을 해야할 코드가 담긴 콜백 함수를 받고, 두 번째 인자(option)로는 Dependency Array(이하 의존성 배열)를 받는다.

만약에 빈 배열을 넣는다면 deps가 없어 변경되는 것이 없으므로 마운트 될 때 처음 한 번만 실행이 되고, 의존성 배열을 인자로 넣지 않는다면 컴포넌트가 렌더링 될 때마다 useEffect에 등록된 콜백이 실행된다.

useEffect의 구조

//1. 렌더링 될 때마다 실행
useEffect(() => { //작업...});

// 1. 마운트 될 때 실행
// 2. 배열 안의 value값이 바뀔 때 실행.
useEffect(() => { //작업...}, [value]);

useEffect 실습

아래의 코드를 그대로 가져가 버튼을 눌러보고 input태그에 타이핑을 해가며 마운트 / 언마운트 / 업데이트 타이밍을 알아보자.

import { useEffect, useState } from 'react';

function App() {
    const [count, setCount] = useState(1);
    const [name, setName] = useState('');

    const countUpdateHandler = () => {
        setCount(count + 1);
    };

    const inputChangeHandler = (e) => {
        setName(e.target.value);
    };

    useEffect(() => {
        console.log('렌더링 될 때 마다 실행');
    });

    useEffect(() => {
        console.log('마운트 될 때 처음 한 번만 실행');
    }, []);

    // 마운트 + 업데이트
    useEffect(() => {
        console.log('마운트 될 때 처음 한 번만 실행 || count state가 변할 때 마다 실행');
    }, [count]);

    // 마운트 + 업데이트
    useEffect(() => {
        console.log('마운트 될 때 처음 한 번만 실행 || name state가 변할 때 마다 실행');
    }, [name]);

    return (
        <div>
            <button onClick={countUpdateHandler}>Update</button>
            <span>count: {count}</span>
            <div>
                <input type="text" onChange={inputChangeHandler} />
                <span>name: {name}</span>
            </div>
        </div>
    );
}

export default App;

마운트(Mount)와 렌더(Render) 차이

렌더링(rendering)

render는 DOM생성을 위해 함수가 호출 될 때.

마운트(Mount)

컴포넌트의 인스턴스가 생성되어 DOM 상에 삽입이 될 때.

결론

컴포넌트가 render될 때 mount 과정을 거친다. 그러나 props나 state가 변경되어 render 될 때는 mount를 거치지 않는다. 결국 mount는 DOM이 생성되고, 웹 브라우저상에 처음으로 나타나는 과정을 말하는 것이다.

정리(Clean-up)를 이용하는 Effects

위에서 useEffect는 컴포넌트 렌더링 이후 특정 작업 처리하는 함수라고 설명했다. 위의 실습 코드는 정리(Clean-up)가 필요하지 않은 코드였지만 useEffect를 사용하다 보면 정리(Clean-up)가 필요한 effect가 있다.(구독 설정, API 호출, 컴포넌트의 DOM 수정 등)

effect를 정리(Clean-up)하는 정확한 시점

리액트는 컴포넌트가 마운트 해제되는 때에 정리(Clean-up)를 실행한다.

Clean-up 실습

// App.js
import { useState } from 'react';
import FactriotRocket from './components/FactriotRocket';

function App() {
    const [showTimer, setShowTimer] = useState(false);

    const timerStatusHandler = () => {
        setShowTimer(!showTimer);
    };

    return (
        <div>
            {showTimer && <FactriotRocket />}
            <button onClick={timerStatusHandler}>
                못생긴 남자가 은근히 인기 많은 이유
            </button>
        </div>
    );
}

export default App;

// FactriotRocket.js
import { useEffect } from 'react';

const FactriotRocket = (props) => {
    useEffect(() => {
        const Patriot = setInterval(() => {
            console.log('같은건 없습니다.');
        }, 1000);

        return () => {
            clearInterval(Patriot);
            console.log('그럼 전 20000');
        };
    }, []);

    return (
        <div>
            <span>개발자 도구를 열어 콘솔을 보세요!</span>
        </div>
    );
};

export default FactriotRocket;

useContext함수는 전역적으로 상태관리를 할 수 있는 도구이다. useContext는 전역적으로 상태를 관리하기에 props를 통해 많은 데이터를 전달하거나 잘못된 부분을 수정할 때 복잡한 과정을 줄여줄 수 있는 장점이 있다.

API 사용방법

1. React.createContext

createContext 함수 import 후 상태관리를 할 값(보통은 객체)을 넣어주면 컨텍스트 객체 생성이 완료된다. createContext에서 반환반은 값은 컴포넌트가 되거나, 컴포넌트를 포함하는 객체가 된다. 컴포넌트를 렌더링 할 때 리액트 트리 상위에서 가장 가까이 있는 Provider로부터 현재 값을 읽음

// src/store/theme-context.js
import { createContext } from 'react';

const ThemeContext = createContext(defaultValue)
// ThemeContext가 컴포넌트는 아니지만 컴포넌트를 포함할 객체이기에
// 파스칼 케이스로 명명함
export default ThemeContext;

defaultValue매개변수는 트리 안에서 적절한 Provider를 찾이 못했을 때만 쓰이는 값이다. (현실적으로는 컴포넌트를 독립적으로 테스트할 때 유용한 값임)

2. Context.Provider

특정 컴포넌트를 포함한 하위의 모든 컴포넌트의 상태값을 바꾸고 싶을 때는 특정 컴포넌트를 포함하고 있는 부모 컴포넌트의 <Context.Provider> 태그로 감싸주고 value 속성을 추가해 값을 바꾸어 주면 Provider 하위에 있는 컴포넌트 안에서 useContext가 반환하는 값이 Provider의 값과 같아진다.

import ThemeContext from './theme-context';

const ThemeContextProvider = (props) => {
    const themeContext = { border: '10px solid red' };
    return (
        <ThemeContext.Provider value={themeContext}>
            {props.children}
        </ThemeContext.Provider>
    );
};

export default ThemeContextProvider;

Context API 적용

// App.js
import { useContext } from 'react';
import { Helmet } from 'react-helmet';
import classes from './App.module.css';
import ThemeContext from './store/theme-context';
import ThemeContextProvider from './store/ThemeProvider';

const App = (props) => {
    return (
        <ThemeContextProvider>
            <div className={classes.root}>
                <Helmet htmlAttributes={{ lang: 'ko' }} />
                <h1>Hello World</h1>
                <Sub1 />
            </div>
        </ThemeContextProvider>
    );
};

function Sub1() {
    const theme = useContext(ThemeContext);

    return (
        <div style={theme}>
            <h1>Sub1</h1>
            <Sub2 />
        </div>
    );
}

function Sub2() {
    return (
        <div>
            <h1>Sub2</h1>
            <Sub3 />
        </div>
    );
}

function Sub3(props) {
    const themeCtx = useContext(ThemeContext);
    return (
        <div style={themeCtx}>
            <h1>Sub3</h1>
        </div>
    );
}

export default App;

3. Context.Consumer

<<MyContext.Consumer>
  {(ctx) => return (/* context 값을 이용한 렌더링 */)}
</MyContext.Consumer>

Context.Consumer의 자식은 함수여야 한다. 이 함수는 context의 현재값을 받고 리액트 노드를 반환한다. 이 함수가 받는 ctx 매개변수 값은 해당 context의 Provider 중 상위 트리에서 가장 가까운 Provider의 ctx props와 동일하다.

1. 클래스: object 뽑아내는 기계
2. 인스턴스: 기계로부터 생성되는 object
3. 프로퍼티: 오브젝트의 속성

자바스크립트에서 클래스란?

자바스크립트에서 클래스란 인스턴스를 생성하기 위한 생성자 함수다.

자바스크립트에서 클래스는 기존 프로토타입 기반 패턴을 클래스 기반 패턴처럼 사용할 수 있도록 하는 문법적 설탕이라고 볼 수 있다. 클래스와 생성자 함수 모두 프로토타입 기반의 인스턴스를 생성하지만 정확히 동일하게 동작하지는 않고 클래스가 생성자 함수보다 엄격하며 생성자 함수에서는 제공하지 않는 기능도 제공한다.

1. 클래스를 new 연산자 없이 호출하면 에러가 발생한다. 하지만 생성자 함수를 new 연산자 없이 호출하면 일반 함수로서 호출된다.
2. 클래스는 상속을 지원하는 extends와 super 키워드를 제공한다.
3. 클래스는 호이스팅이 발생하지 않는 것처럼 동작한다. 하지만 함수 선언문으로 정의된 생성자 함수는 함수 호이스팅이, 함수 표현식으로 정의한 생성자 함수는 변수 호이스팅이 발생한다.
4. 클래스 내의 모든 코드에는 암묵적으로 strict mode가 지정되어 실행되며 이를 해제할 수도 없다.
5. 클래스의 counstructor, 프로토타입 메서드, 정적 메서드는 모두 프로퍼티 어트리뷰트 [[ Enumerable ]]의 값이 false다. 즉 열거되지 않는다.

클래스를 단순히 문법적 설탕이라기 보다는 새로운 객체 생성 메커니즘으로 보는 것이 합당하다.

클래스 정의

// 클래스 선언문
class Person {}

• class 키워드를 사용하여 정의
• 클래스 이름은 파스칼 케이스로 사용하는 것이 일반적
• 함수처럼 클래스를 표현식으로도 정의할 수는 있음 (일반적이진 않음)
  • 이는 클래스는 값처럼 사용할 수 있는 일급 객체라는 것을 의미함.
• 클래스 몸체에는 0개 이상의 메서드만 정의할 수 있음.
  • constructor(생성자), 프로토타입 메서드, 정적 메서드

클래스와 생성자 함수의 정의 방식 비교

var Person = (function () {
    // 생성자 함수
    function Person(name) {
        this.name = name;
    }

    // 프로토타입 메서드
    Person.prototype.sayHi = function () {
        console.log('Hi! My name is ' + this.name);
    };

    // 정적 메서드
    Person.sayHello = function () {
        console.log('Hello');
    };

    // 생성자 함수 반환
    return Person;
})();

class Person {
    // 생성자
    constructor(name) {
        this.name = name;
    }

    // 프로토타입 메서드
    sayHi() {
        console.log(`Hi! My name is ${this.name}`);
    }

    // 정적 메서드
    static sayHello() {
        console.log('Hello');
    }
}

클래스 호이스팅

클래스는 함수로 평가된다.

클래스 선언문으로 정의한 클래스는 함수 선언문과 같이 런타임 이전에 먼저 평가되어 함수 객체를 생성한다. 이렇게 평가되어 생성된 함수 객체는 생성자 함수로서 호출할 수 있는 함수 즉, constructor다.

클래스 선언문도 변수 선언, 함수 정의와 마친가지로 호이스팅이 발생한다. 단, 클래스는 let, const 키워드로 선언한 변수처럼 호이스팅 된다. 따라서 클래스 선언문 이전에 TDZ에 빠지기 때문에 호이스팅이 발생하지 않는 것처럼 동작한다.

인스턴스 생성

클래스는 생성자 함수이며 new 연산자와 함께 호출되어 인스턴스를 생성한다. 함수는 new 연산자 사용 여부에 따라 일반 함수로 호출되는지, 생성자 함수로 호출되던지 하지만 클래스는 인스턴스를 생성하기 위한 존재이므로 반드시 new 연산자와 함께 호출해야 한다.

• 식별자를 사용해 인스턴스를 생성하지 않고 기명 클래스 표현식의 클래스 이름을 사용해 인스턴스를 생성하면 에러가 발생한다.

const Person = class MyClass {};

// 함수 표현식과 마찬가지로 클래스를 가리키는 식별자로 인스턴스를 생성해야 한다.
const me = new Person();

// 클래스 이름 MyClass는 함수와 동일하게 클래스 몸체 내부에서만 유효한 식별자다.
console.log(MyClass); // 참조 에러

const you = new MyClass(); // 참조 에러

기명 함수 표현식처럼 클래스 표현식에서 사용한 클래스 이름은 외부 코드에서 접근이 불가함

메서드

클래스 몸체에는 0개 이상의 메서드만 선언할 수 있다. 정의 가능한 메서드는 constructor, 프로토타입 메서드, 정적 메서드 세 가지가 있다.

1. constructor

constructor는 인스턴스를 생성하고 초기화하기 위한 특수한 메서드다.

• constructor 이름변경 불가
• constructor는 클래스 내에 최대 한 개만 존재할 수 있다
• constructor는 생략 가능하다 - 빈 constructor가 암묵적으로 생성됨
• constructor는 별도의 반환문을 가져선 안된다. 명시적으로 반환하면 인스턴스(this)가 반환되지 못하고 return 문에 명시한 객체만 반환된다.

2. 프로토타입 메서드

3. 정적 메서드

4. 정적 메서드와 프로토타입 메서드의 차이

아래의 차이점과 예시를 보고 정적 메서드와 프로토타입 메서드를 무엇을 기준으로 구분하여 정의해야 할지 알아보자.

1. 정적 메서드와 프로토타입 메서드는 자신이 속해 있는 프로토타입 체인이 다르다.
2. 정적 메서드는 클래스로 호출하고 프로토타입 메서드는 인스턴스로 호출한다.
3. 정적 메서드는 인스턴스 프로퍼티를 참조할 수 없지만 프로토타입 메서드는 인스턴스 프로퍼티를 참조할 수 있다.

class Square {
    static area(width, height) {
        console.log(width * height);
    }
}

Square.area(10, 10); // 100

위 예제는 정적 메서드 area를 사용해 사각형의 넓이를 구한 것이다. 이 때 정적 메서드 area는 인스턴스 프로퍼티를 참조하지 않는다. 인스턴스 프로퍼티를 참조해야 한다면 정적 메서드 대신 프로토타입 메서드를 사용해야 한다.

class Square {
    constructor(width, height) {
        this.width = width;
        this.height = height;
    }

    area() {
        console.log(this.width * this.height);
    }
}

const sq = new Square(10, 10);

sq.area(); // 100

위 예제에서 메서드 내부의 this는 메서드를 소유한 객체가 아니라 메서드를 호출한 객체. 즉 메서드 이름 앞의 마침표(.) 연산자 앞에 기술한 객체에 바인딩된다.

정적 메서드와 프로토타입 메서드 사용 기준

정적 메서드는 클래스로 호출해야 하므로 정적 메서드 내부의 this는 인스턴스가 아닌 클래스를 가리킨다. 즉, 프로토타입 메서드와 정적 메서드 내부의 this 바인딩이 다르다.

따라서 메서드 내부에서 인스턴스 프로퍼티를 참조할 필요가 있다면 this를 시용해야 하며, 이러한 경우 프로토타입 메서드로 정의해야 한다. 하지만 메서드 내부에서 인스턴스 프로퍼티를 참조해야 할 필요가 없다면 this를 사용하지 않게 된다.

물론 메서드 내부에서 this를 사용하지 않더라도 프로토타입 메서드로 정의할 수 있다. 하지만 반드시 인스턴스를 생성한 다음 인스턴스를 호출해야 하므로 this를 사용하지 않는 메서드는 정적 메서드로 정의하는 것이 좋다.

클래스의 인스턴스 생성 과정

프로퍼티

1. 인스턴스 프로퍼티

인스턴스 프로퍼티는 constructor 내부에서 정의해야 한다.

class Person {
    constructor(name) {
        // 인스턴스 프로퍼티
        this.name = name;
    }
}
const me = new Person('Sung Woo');
console.log(me); //Person { name: 'Sung Woo' }

생성자 함수에서 생성자 함수가 생성할 인스턴스의 프로퍼티를 정의하는 것과 마찬가지로 constructor 내부에서 this에 인스턴스 프로퍼티를 추가한다. 이로써 클래스가 암묵적으로 생성한 빈 객체, 즉 인스턴스에 프로퍼티가 추가도어 인스턴스가 초기화 된다.

2. 접근자 프로퍼티

접근자 프로퍼티는 자체적으로 값([[Value]])을 갖을 갖지 않고 다른 데이터 프로퍼티의 값을 읽거나 저장할 때 사용하는 접근자 함수로 구성된 프로퍼티다. (그냥 게터세터)

class Person {
    constructor(firstName, lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    // fullName은 접근자 함수로 규정된 접근자 프로퍼티다.
    get fullName() {
        return `${this.firstName} ${this.lastName}`;
    }

    set fullName(name) {
        [this.firstName, this.lastName] = name.split(' ');
    }
}

const me = new Person('Sungwoo', 'Jang');

// 데이터 프로퍼티를 통한 프로퍼티 값의 참조.
console.log(`${me.firstName} ${me.lastName}`);

// 접근자 프로퍼티를 통한 프로퍼티 값의 저장
// 접근자 프로퍼티 fullName에 값을 할당하면 setter 함수가 호출된다.
me.fullName = 'Heegun Lee';
console.log(me); // {firstName: 'Heegun', lastName: 'Lee'}

// 접근자 프로퍼티를 통한 프로퍼티 값의 참조
// 접근자 프로퍼티 fullName에 접근하면 getter 함수가 호출된다.
console.log(me.fullName); // Heegun Lee

// fullName은 접근자 프로퍼티다.
// 접근자 프로퍼티는 get, set, enumerable, configurable 프로퍼티 어트리뷰트를 갖는다.
Object.getOwnPropertyDescriptor(Person.prototype, 'fullName')
// {enumerable: false, configurable: true, get: ƒ, set: ƒ}

• getter
  1. 인스턴스 프로퍼티에 접근할 때마다 프로퍼티 값을 조작하거나 별도의 행위가 필요할 때 사용
  2. 무언가를 취득할 때 사용하므로 반드시 무언가를 반환해야 함
• setter
  1. 프로퍼티에 값을 할당할 때마다 프로퍼티 값을 조작하거나 별도의 행위가 필요할 때 사용
  2. 단 하나의 값만 할당받기 때문에 단 하나의 매개변수만 선언 가능.

private 필드 정의 제안

원래 JS는 캡슐화를 완전히 지원하지 않는다. ES6의 클래스도 생성자 함수와 마찬가지로 다른 클래스 기반 객체지향 언어에서 지원하는 private, public, protected 같은 접근 제한자를 지원하지 않는다. 따라서 인스턴스 프로퍼티는 언제나 public이다. (하지만 private 필드를 정의할 수 있게 된다. 방법설명 간다)

class Person {
    // 클래스 필드 정의
    #name = '';

    constructor(name) {
        // private 필드 참조
        this.#name = name;
    }
}
const me = new Person('jang');
// private 필드 #name은 클래스 외부에서 참조할 수 없다.
console.log(me.#name); // 문법에러 뜸

private은 클래스 내부에서만 접근 가능하니 이렇게 에러가 뜬다. 접근하고 싶으면 접근자 프로퍼티를 사용한다.

class Person {
    // 클래스 필드 정의
    #name = '';

    constructor(name) {
        // private 필드 참조
        this.#name = name;
    }
    get name() {
        return this.#name.trim(); // 양 끝 공백 제거 메서드
    }
}
const me = new Person('jang');
console.log(me.name); // jang

상속에 의한 클래스 확장

클래스 상속과 생성자 함수 상속

1. 프로토타입 기반 상속

• 프로토타입 체인을 통해 다른 객체의 자산을 상속받는 개념

  2. 상속에 의한 클래스 확장

• 기존 클래스를 상속받아 새로운 클래스를 확장하여 정의

상속을 통해 super을 확장한 child 클래스 구현 예제

class Animal {
    constructor(age, weight) {
        this.age = age;
        this.weight = weight;
    }
    eat() {
        return 'eat';
    }
    move() {
        return 'move';
    }
}

class Bird extends Animal {
    constructor(...args) {
        super(...args);
    }
    fly() {
        return 'fly';
    }
}

const bird = new Bird(3, 8);
console.log(bird.eat()); // eat
console.log(bird.move()); // move
console.log(bird.fly()); // fly

동적 상속

let condition = true;

class Animal {
    constructor(age, weight) {
        this.age = age;
        this.weight = weight;
    }
    eat() {
        return 'eat';
    }
    informState() {
        return '새';
    }
}

class IronDragon {
    constructor(age, weight) {
        this.age = age;
        this.weight = weight;
    }
    informState() {
        return '씹새끼';
    }
}

class Bird extends (condition ? IronDragon : Animal) {
    constructor(...args) {
        super(...args);
    }
    fly() {
        return 'fly';
    }
    informState() {
        return super.informState();
    }
}

const bird = new Bird(3, 8);
console.log(bird.informState());

super 키워드는 함수처럼 호출할 수도있고 this와 같이 식별자 처럼 참조할 수 있는 특수한 키워드다. 이를 활용해 메서드 명이 같아도 실행 되게 구현 한 것이다.

• super를 호출하면 수퍼클래스의 constructor를 호출한다.
• super를 참조하면 수퍼클래스의 메서드를 호출할 수 있다.

상속 클래스의 인스턴스 생성 과정

상속 관계에 있는 두 클래스가 어떻게 협력하며 인스턴스를 생성하는지 알게되면 super를 더욱 명확하게 이해할 수 있다.

class Reactangle {
    constructor(width, height) {
        this.width = width;
        this.height = height;
    }

    getArea() {
        return this.width * this.height;
    }

    toString() {
        return `width = ${this.width}, height = ${this.height}`;
    }
}

class ColorRectangle extends Reactangle {
    constructor(width, height, color) {
        super(width, height);
        this.color = color;
    }
    // 메서드 오버라이딩
    toString() {
        return super.toString() + `, color = ${this.color}`;
    }
}

const colorRectangle = new ColorRectangle(2, 5, 'Red');
console.log(colorRectangle);
// 상속을 통해 getArea 호출
console.log(colorRectangle.getArea()); // 8
// 오버라이딩된 toString 메서드를 호출
console.log(colorRectangle.toString()); // width = 2, height = 5, color = Red

서브 클래스에서 반드시 super를 호출하는 이유

서브클래스는 자신이 직접 인스턴스를 생성하지 않고 수퍼클래스에게 인스턴스 생성을 위임한다. 그렇기에 서브클래스의 constructor에서 반드시 super를 호출해야 한다.

수퍼클래스의 인스턴스 생성과 this 바인딩

수퍼클래스의 constructor 내부의 코드가 실행되기 이전에 암묵적으로 빈 객체를 생성한다. 이 빈 객체가 클래스가 생성한 인스턴스다. 그리고 인스턴스는 this에 바인딩된다. 따라서 수퍼클래스의 constructor 내부의 this는 생성된 인스턴스를 가리킨다.

class Reactangle {
    constructor(width, height) {
        console.log(this); // ColorRectangle {}
```![업로드중..](blob:https://velog.io/17ac3f73-9ccf-4751-9398-96a7d1398f42)

useReducer는 useState의 대채 함수이다.

useReducer 장점

1. 한 컴포넌트 내에서 State 업데이트 로직을 컴포넌트로부터 분리가 가능
2. 복잡한 상태를 체계적으로 관리하기 용이함

useState 와 useReducer 차이

useState 와 useReducer 차이

useState를 사용한 상태관리

import { useState } from 'react';
import { Helmet } from 'react-helmet';
import classes from './App.module.css';

const App = (props) => {
    const [number, setNumber] = useState(0);

    const upNumberHandler = () => {
        setNumber(number + 1);
    };
    const resetNumberHandler = () => {
        setNumber(0);
    };
    const downNumberHandler = () => {
        setNumber(number - 1);
    };
    return (
        <div className={classes.root}>
            <Helmet htmlAttributes={{ lang: 'ko' }} />
            <input type="button" value="-" onClick={downNumberHandler} />
            <input type="button" value="0" onClick={resetNumberHandler} />
            <input type="button" value="+" onClick={upNumberHandler} />
            <span>{number}</span>
        </div>
    );
};

export default App;

useReducer를 사용한 상태관리

import { useReducer } from 'react';
import { Helmet } from 'react-helmet';
import classes from './App.module.css';

const countReducer = (state, action) => {
    if (action === 'UP') {
        return state + 1;
    } else if (action === 'RESET') {
        return 0;
    } else if (action === 'DOWN') {
        return state - 1;
    }
};

const App = (props) => {
    const [number, numberDispatch] = useReducer(countReducer, 0);

    const upNumberHandler = () => {
        numberDispatch('UP');
    };
    const resetNumberHandler = () => {
        numberDispatch('RESET');
    };
    const downNumberHandler = () => {
        numberDispatch('DOWN');
    };
    return (
        <div className={classes.root}>
            <Helmet htmlAttributes={{ lang: 'ko' }} />
            <input type="button" value="-" onClick={downNumberHandler} />
            <input type="button" value="0" onClick={resetNumberHandler} />
            <input type="button" value="+" onClick={upNumberHandler} />
            <span>{number}</span>
        </div>
    );
};

export default App;

useReducer 기본 구조

const [state, dispatch] = useReducer(reducer, initialArg, init);

• state: 컴포넌트에서 사용할 state
• dispatch: 컴포넌트 내에서 state의 업데이트를 위해 reducer함수를 실행시키는 함수
• reducer: 컴포넌트 “외부”에서 state 업데이를 담당하는 함수(위 예에선 countReducer 실행 함수로 보면 됨)
• initialArg: 초기값 (초기 state)
• init: 초기함수

reducer 함수

state과 action 객체를 파라미터로 받아 새로운 상태를 반환해주는 함수이다.

const reducer = (state, action) => { ... }

• state: 컴포넌트에서 사용할 상태
• action: 업데이트를 위한 정보를 갖고있는 값 (주로 객체임)

모든 식별자(변수 이름, 함수 이름, 클래스 이름 등)는 자신이 선언된 위치에 의해 다른 코드가 식별자 자신을 잠조할 수 있는 유효 범위가 결정된다. 이를 스코프라 한다. 즉, 스코프는 식별자가 유효한 범위를 말한다.

스코프 체인

스코프는 함수의 중첩에 의해 계층적 구조를 갖는다. 즉, 중첩 함수의 지역 스코프는 중첩 함수를 포함하는 외부 함수의 지역 스코프와 계층적 구조를 갖는다. 이때 외부 함수와 지역 스코프를 중첩 함수의 상위 스코프라 한다.

let ediots;
function foo() {
  function bar() {
    ediots = 10;
  }
  bar();
}

function dumb() {
  console.log(ediots);
}
foo();dumb();

함수 레벨 스코프(let, const 쓰면 무의미)

지역은 함수 몸체 내부를 말하고 지역은 지역 스코프를 만든다. 이는 코드 블록이 아닌 함수에 의해서만 지역 스코프가 생성된다는 의미다. (나중에 이 부분을 보완하기 위해 let, const를 사용함)

C나 자바 등을 비롯해 대부분의 프로그래밍 언어는 함수 몸체만이 아닌 모든 코드 블록이 지역 스코프를 만들지만 var키워드로 선언된 변수는 오로지 함수의 코드 블록(함수 몸체)만을 지역 스코프로 인정한다.

스코프 체인은 물리적인 실체로 존재한다. 자바스크립트 엔진은 코드를 실행하기에 앞서 그림과 유사한 자료구조인 렉시컬 환경을 실제로 생성한다.

렉시컬 환경

스코프 체인은 실행 컨텍스트의 렉시컬 환경을 단방향으로 연결한 것이다. 전역 렉시컬 환경은 코드가 로드되면 곧바로 생성되고 함수의 렉시컬 환경은 함수가 호출되면 곧바로 생성된다.

렉시컬 스코프

렉시컬 스코프란 함수를 어디서 호출하는지가 아니라 어디에 선언하였는지에 따라 결정되는 것을 말한다. (렉시컬 스코프(lexical scope)는 정적 스코프(static scope)와 같은 말이라 봐도 무방)

var x = 1;

function foo() {
    var x = 10;
    bar();
}
function bar() {
    console.log(x);
}

foo();
bar()

자바스크립트는 렉시컬 스코프를 따르므로 함수 호출 위치가 아닌 함수를 어디서 정의했는지에 따라 상위 스코프를 결정한다. 함수가 호출된 위치는 상위 스코프 결정에 어떠한 영향도 주지 않는다. 즉, 함수의 상위 스코프는 언제나 자신이 정의된 스코프다.

함수의 상위 스코프는 함수 정의가 실행될 때 정적으로 결정된다.

결론: 함수의 상위 스코프는 함수 정의가 실행될 때 정적으로 결정된다.

질문: 위 예제의 결과를 예측하고 그 이유를 말해보시오

답: JS는 렉시컬 스코프를 따릅니다. 위 예제에서 bar 함수는 전역에서 정의된 함수니 bar 함수의 상위 스코프는 언제나 전역 스코프이기에 bar함수는 어떤 식으로 호출을 해도 1이 나옵니다.