사용자가 이미지를 업로드하면 preview 이미지로 drag and drop할 수 있다. 최대 5장, 10mb 이하로 제한했지만 버범임이 발생하는 것을 볼 수 있다.

최적화 이전

처음에는 Canvas API 활용해서 이미지 압축하고, jpeg 또는 png 이미지를 webp로 변환했다.

하지만 해당 작업을 메인 스레드에서 작업하다보니, 속도가 느렸다.

웹 브라우저에서 메인 스레드는 UI 렌더링, 이벤트 처리, DOM 조작 등의 작업을 담당한다. Canvas API를 활용한 이미지 압축은 데이터를 변환하는 과정에서 CPU 사용량이 증가한다. 특히 고해상도 이미지를 처리할 경우 연산 부담이 커져 UI가 멈추거나 렌더링 지연이 발생할 수 있다.

최적화 이후

Web Worker를 사용해 이미지 압축(메인 스레드에서 실행되는 연산)을 백그라운드에서 병렬 처리함으로써 최적화할 수 있다.

Web Worker는 스크립트 연산을 웹 메인 스레드와 분리된 별도의 백그라운드 스레드에서 실행할 수 있는 기술이다.

Web Worker 종류

Dedicated Worker

• 메인 스레드와 독립적으로 실행.
• 특정 페이지(스코프 내)에서만 사용 가능.
• postMessage로 메인 스레드와 통신.
• 이미지 압축, 데이터 처리, CPU 집약적 작업.

  Shared Worker

• 여러 브라우저 탭에서 공유 가능.
• 같은 도메인 내에서만 사용 가능.
• MessagePort로 통신.
• 여러 탭에서 동일한 상태 유지.

  Service Worker

• 백그라운드에서 실행되며 네트워크 요청 가로챌 수 있음.
• 브라우저 종료 후에도 동작 가능.
• HTTPS 환경에서만 작동
• 캐싱, 오프라인 지원, API 요청 가로채기 (MSW)

  Dedicated Worker 특징

• 별도의 스레드에서 동작하며 메인 스레드와 독립적으로 실행된다.
• 비동기적으로 동작하여 메인 스레드가 작업 완료를 기다리지 않아도 된다.
• DOM에 직접 접근할 수 없다. 대신 메인 스레드에서 DOM 작업을 처리해야 한다.
• Web Worker와 메인 스레드는 postMessage와 onmessage 이벤트 핸들러를 통해 데이터를 교환한다.

  과정

  포멧 변환

  사용자로부터 JPEG, PNG, WebP 등 다양한 포멧을 가진 이미지를 받는데 이를 압축 효율이 높은 WebP로 변환한다.

WebP는 2010년에 구글이 개발한 이미지 포멧으로 손실, 무손실 압축과 투명도를 모두 지원하고, GIF와 동일하게 애니메이션을 지원한다. 이미지 내에서 인접한 픽셀들은 대개 유사한 색상을 가지는 경향이 있는데, WebP는 이러한 상관관계를 활용하여 픽셀 색상을 인접 픽셀 색상에 기반하여 예측할 수 있는 효율적인 예측 알고리즘이 있다.

WebP는 2024년 12월 기준 전체 사용자의 약 97퍼를 지원하고 있고, 아직은 문제가 없기 때문에 호환성 측면에서 현재 프로젝트에서는 별다른 조치를 하고 있지 않다.

하지만 WebP를 지원하지 않는 브라우저를 사용하는 사용자가 있을 경우, 사용자로부터 원본 이미지를 받고 CDN에 이미지 요청할 때 유저의 user-agent 확인하여 webp 지원하면 변환하고 아니면 원본이미지를 보내는 방법으로 바꿔 문제를 해결하고자 한다.

worker script 작성

• /// <reference lib="webworker" /> 지시자(Triple-Slash Directive) 사용
  • 타입스크립트 환경에서 Web Worker 파일 작성할 때 사용한다.
  • 기본적으로 타입스크립트는 브라우저 환경에서 사용되는 DOM API 타입(window, document 등)을 참조한다. 하지만 Web Worker는 DOM이 없고, Worker 전용 API만 사용 가능하기 때문에, TypeScript가 이를 정확히 이해하려면 Worker 전용 타입 선언이 필요하다.
• OffscreenCanvas
  • Web Worker에서는 document, window와 같은 DOM API에 직접 접근할 수 없다.
  • OffscreenCanvas는 이러한 제약을 해결하기 위해 도입된 API로, 메인 스레드가 아닌 Worker 스레드에서 Canvas 렌더링을 가능하게 한다.

// imageCompressionWorker.ts

/// <reference lib="webworker" />

import { toast } from 'sonner';

interface WorkerMessage {
  fileData: ArrayBuffer;
  fileName: string;
}

self.onmessage = async (e: MessageEvent<WorkerMessage>) => {
  const { fileData, fileName } = e.data;

  try {
    const blob = new Blob([fileData]);
    const imageBitmap = await createImageBitmap(blob);

    const maxWidth = imageBitmap.width > 750 ? 750 : imageBitmap.width;
    const scale = maxWidth / imageBitmap.width;
    const targetWidth = maxWidth;
    const targetHeight = imageBitmap.height * scale;

    const offscreen = new OffscreenCanvas(targetWidth, targetHeight);
    const ctx = offscreen.getContext('2d');

    if (!ctx) {
      toast.error('이미지 업로드에 실패했습니다.');
      return;
    }

    ctx.drawImage(imageBitmap, 0, 0, targetWidth, targetHeight);

    // quality 설정
    const quality = 0.9;
    const webpBlob = await offscreen.convertToBlob({
      type: 'image/webp',
      quality
    });

    // 변환된 Blob을 소유권 이전 형태로 메인 스레드로 전송
    const arrayBuffer = await webpBlob.arrayBuffer();
    self.postMessage({ arrayBuffer, fileName }, [arrayBuffer]);
  } catch (error) {
    // 에러 발생 시 메인 스레드에 알림
    self.postMessage({ error: (error as Error).message });
  }
};

이미지 압축 및 포멧 변환 함수 작성

• promise를 리턴해서 여러 개의 이미지를 병렬 처리하도록 한다.
• ArrayBuffer 사용
  • 메인 스레드와 Worker는 별개의 실행 환경을 갖는다. 두 환경은 서로 전역 변수를 공유하거나 DOM 객체를 직접 주고받을 수 없으며, postMessage를 통해서만 통신한다. postMessage를 통해 객체를 Worker로 보내면 브라우저는 Structured Clone을 사용해 객체를 복제한다.
    • 단순 숫자나 문자열, JSON으로 표현 가능한 객체는 쉽게 복제되지만, 대용량 바이너리 데이터(File, Blob, ArrayBuffer)를 다룰 때는 효율적인 전송 방법이 필요하다.
    • File 객체는 브라우저에서 입력받은 파일이며, 메타데이터(파일명, 수정 시간, 타입)와 실제 바이너리 데이터가 함께 담겨 있다. 이를 Worker에 바로 넘길 수도 있지만, Worker 쪽으로 복사(copy)되는 형태로 전달되어 대용량 파일일수록 복사 과정이 비용이 많이 들 수 있다.
    • ArrayBuffer 객체는 순수 바이너리 데이터를 담는 컨테이너이다. 어떤 파일이든 file.arrayBuffer()를 통해 순수한 이진 데이터로 읽어낼 수 있다. 이 ArrayBuffer를 postMessage에 전달할 때, 두 번째 인자로 ArrayBuffer를 Transferable로 지정하면, 복사가 아닌 소유권 이전(transfer)이 일어난다.
    • 소유권 이전이란 메모리를 복사하지 않고, 메인 스레드에 있던 ArrayBuffer의 소유권을 Worker에게 넘겨버리는 것이다. 이로써 메인 스레드 쪽 arrayBuffer는 더 이상 유효하지 않고(길이 0짜리로 보이거나 사용 불가), Worker 측에서 해당 바이너리 데이터를 바로 사용할 수 있게 된다.

// compressAndConvertToWebP.ts
import { toast } from 'sonner';

export const compressAndConvertToWebP = async (file: File): Promise<File> => {
  try {
    const fileArrayBuffer = await file.arrayBuffer();

    const worker = new Worker(
      new URL('../lib/imageCompressionWorker.ts', import.meta.url),
      { type: 'module' }
    );

    return new Promise<File>((resolve, reject) => {
      worker.onmessage = (e: MessageEvent) => {
        const { arrayBuffer, fileName } = e.data;

        const blob = new Blob([arrayBuffer], { type: 'image/webp' });
        const webpFile = new File([blob], fileName, { type: 'image/webp' });
        resolve(webpFile);
        worker.terminate();
      };

      worker.onerror = (err) => {
        toast.error('이미지 압축 worker error!');
        reject(err);
        worker.terminate();
      };

      // 소유권 이전 형태로 work로 전송.
      worker.postMessage({ fileData: fileArrayBuffer, fileName: file.name }, [
        fileArrayBuffer
      ]);
    });
  } catch {
    toast.error('이미지를 읽지 못했습니다.');
    throw new Error('이미지를 읽지 못했습니다.');
  }
};

이미지 병렬 처리

이미지 압축 및 포멧 변환 작업을 병렬 처리함으로써 처리 속도를 유의미하게 개선할 수 있다.

const addImages = async (newFiles: File[]) => {
    const compressedAllFiles = await Promise.all(
      newFiles.map(async (file) => {
        const compressed = await compressAndConvertToWebP(file);
        return compressed;
      })
    );
    setState(compressedAllFiles);
  };

결과

성능 개선

버벅임 제거

JSX에 SVG 파일을 직접 import해서 사용하면 편리하지만 JS 번들 크기 늘어나고 불필요한 네트워크 요청 증가한다.

import NotFoundIcon from '@/assets/icons/404_sign.svg';

<img src={NotFoundIcon} alt="NotFoundLogo" className="size-40" />

아래는 랜딩 페이지의 네트워크 탭인데, 네트워크 요청의 절반이 아이콘 요청이다.

SVG Sprite

Sprite는 그래픽 리소스를 한 파일 안에 모아서 필요한 부분만 뽑아 쓰는 기법을 가리킨다. SVG Sprite 파일을 생성하면 SVG 파일을 한 파일에 모아서 필요한 부분만 뽑아서 사용할 수 있다.

이점

• 아이콘 HTTP 요청 줄임으로써 페이지 로딩 시간 단축할 수 있다.
• 새로운 아이콘 요소 쉽게 추가할 수 있다.
• SVG sprite 파일을 따로 생성하기 때문에 JS 번들 크기 줄어든다.

생성 및 사용 방법

1. <svg /> 태그를 <symbol /> 로 바꾼 svg 콘텐츠를 모아 하나의<svg />로 래핑한다.
2. symbol 태그의 id로 아이콘을 구분한다.
3. <svg />태그로 감싼 <use /> 태그의 href 속성에서 id를 사용하여 아이콘 사용한다.

이를 통해 아이콘이 아무리 많아도 스프라이트 파일 한 번만 요청하면 되고, 이후엔 <use />를 통해 각 아이콘을 재사용할 수 있어 성능과 관리 효율이 좋아진다.

자동화 작업

스크립트 작성

프로젝트에서 사용하는 SVG 파일들을 모아 단일 SVG Sprite로 결합하는 스크립트를 작성한다.

// generateSprite.ts
import fs from 'fs';
import { globSync } from 'glob';
import { HTMLElement, parse } from 'node-html-parser';
import path from 'path';

// 프로젝트 내에 있는 모든 SVG 파일 모은다.
const svgFiles = globSync('src/shared/assets/icons/*.svg');
const symbols: string[] = [];

// 각 SVG 파일을 읽고 svg 태그를 symbol 태그로 바꾸고 필요한 속성만 취한다.
svgFiles.forEach((file) => {
  const code = fs.readFileSync(file, 'utf-8');
  const svgElement = parse(code).querySelector('svg') as HTMLElement;
  const symbolElement = parse(`<symbol/>`).querySelector(
    'symbol'
  ) as HTMLElement;
  const fileName = path.basename(file, '.svg');

  svgElement.childNodes.forEach((child) => symbolElement.appendChild(child));

  symbolElement.setAttribute('id', fileName);
  if (svgElement.attributes.viewBox) {
    symbolElement.setAttribute('viewBox', svgElement.attributes.viewBox);
  }

  symbols.push(symbolElement.toString());
});

// 정적 폴더에 작성한다.
const svgSprite = `<svg>${symbols.join('')}</svg>`;
fs.writeFileSync('public/sprite.svg', svgSprite);

빌드 전에 스크립트 실행.

"scripts": {
    "dev": "vite",
    "generateSprite": "tsx generateSvgSprite.ts",
    "build": "npm run generateSprite && tsc -b && vite build",
  },

사용

추가적인 import 없이, 아이콘 컴포넌트를 생성해서 사용한다.

interface IconProps {
  name: string;
  style?: string;
  ariaLabel?: string;
}

export const Icon = ({ name, style, ariaLabel = name }: IconProps) => {
  return (
    <svg xmlns="http://www.w3.org/2000/svg" className={style} aria-label={ariaLabel}>
      <use href={`/sprite.svg#${name}`} />
    </svg>
  );
}

<Icon name='404_sign' style='size-40' ariaLabel="NotFoundLogo" />

적용 이후

출처

아이콘으로 SVG 스프라이트를 만드는 방법 SVG Sprite 기법을 사용해 나만의 특별한 Icon 컴포넌트 개발

리액트에서 단순한 form은 쉽게 관리할 수 있지만 대규모 form으로 발전하면 다음과 같은 문제가 발생한다.

• 관리 복잡성 증가: 입력 필드가 추가될 때마다 새로운 상태와 로직이 추가되어 코드가 방대해진다.
• 유효성 검사 관리 부담: 유효성 검사 로직이 분산되고 복잡하여 유지보수가 어려워진다.

이를 해결하기 위해 React Hook Form과 Zod를 활용하면 다음과 같은 장점이 있다.

• 간결한 코드 작성: Hook 기반으로 직관적이고 깔끔한 코드 작성이 가능하다.
• 유효성 검사 통합: 유효성 검사를 간단히 처리하며, 타입과 데이터 구조 관리를 쉽게 할 수 있다.

React Hook Form의 특징

성능 최적화

• 비제어 컴포넌트 방식을 기반으로 작동하여 DOM의 참조(ref)를 활용해 불필요한 렌더링을 줄인다.
• watch 기능으로 실시간 상태 추적이 가능하여 제어 컴포넌트의 장점을 함께 제공한다.

간결한 코드

• useForm 같은 Hook 기반 API로 직관적이고 간결한 코드 작성이 가능하다.
• register 를 사용해 필드 값과 유효성 검사를 자동으로 관리한다.

  유연한 유효성 검사

• HTML5 기본 유효성 검사를 지원한다.
• Zod와 같은 Schema 기반 유효성 검사 라이브러리 호환을 지원한다. 공식 문서
• 비동기 유효성 검사를 지원한다.

  외부 라이브러리와의 호환성

  Material-UI 같은 UI 라이브러리나 shadcn/ui 같은 component collection과 쉽게 통합 가능하다. 공식 문서

제어 컴포넌트 vs 비제어 컴포넌트

제어 컴포넌트

리액트 내부에서 값이 제어되는 컴포넌트를 의미하며, 리액트의 상태를 통해 입력 필드의 값을 관리하는 방식이다.

• 장점: 상태와 UI가 동기화되며 실시간 유효성 검사가 쉽다.
• 단점: 상태 관리 로직으로 인해 코드가 복잡해지고 리렌더링으로 인해 성능 문제가 발생할 수 있다.

  비제어 컴포넌트

  DOM이 직접 입력값을 괸리하는 방식으로 useRef를 활용한다.

useRef는 heap 영역에 저장되는 일반적인 자바스크립트 객체로, 애플리케이션이 종료되거나 가비지 컬렉팅될 때까지 참조할 때마다 같은 메모리 값을 가진다. 값이 변경되어도 같은 메모리 주소를 가지고 있기 때문에 리액트는 변경사항을 감지할 수 없어 리렌더링하지 않는다. 이를 통해 렌더링 횟수를 줄이고 성능을 최적화할 수 있다.

• 장점: 코드가 간단하고 리렌더링이 최소화되어 성능적으로 유리하다.
• 단점: 상태와 유효성 검사를 직접 관리해야 하므로 복잡해질 수 있고 데이터 흐름이 직관적이지 않다.

  Zod: 스키마 기반 유효성 검사 라이브러리

  Zod는 타입스크립트를 우선으로 설계된 스키마(Schema) 선언 및 유효성 검사 라이브러리이다. 데이터 스키마를 선언적으로 정의하여 사용하는데, 여기서 스키마란 데이터의 형태, 데이터의 타입 그리고 데이터가 충족해야 할 조건들을 지정한다. 해당 스키마를 기준으로 Zod는 주어진 데이터를 검증하고 검증에 실패하면 에러를 리턴한다. 이를 통해 데이터의 무결성을 유지하고 예상치 못한 데이터 구조로 발생하는 에러를 방지할 수 있다.

  특징

• 스키마 정의: 스키마를 통해 Object, Array, String, Number 등의 타입과 그에 따른 조건을 정의한다.
• 유효성 검사: parse()와 safeParse() 메서드로 데이터를 검증한다.
• 타입 추론: 타입스크립트 타입을 스키마로부터 자동으로 추론한다.
• 동적 스키마 구성: 함수형 API로 복잡한 조건부 유효성 검사를 처리할 수 있다.

React Hook Form과 Zod 연결

@hookform/resolvers 라이브러리를 사용하여 React Hook Form과 Zod의 스키마를 연결한다.

• Zod는 타입스크립트 우선 라이브러리이기 때문에 스키마를 통해 타입과 유효성 검사를 동시에 처리할 수 있다.
• 스키마에서 작성한 에러 메시지를 React Hook Form의 error 객체에서 바로 활용할 수 있다.
• 동일한 스키마를 여러 form에서 재활용할 수 있어 코드 중복을 줄이고 유지보수가 용이해진다.
• 입력 필드의 조건부 유효성 검사나 복잡한 데이터 구조 처리하는데 매우 유연하다.

  사용 예시

  스키마 선언

• 데이터 구조와 유효성 검사를 정의한다.
• superRefine() 메서드를 사용하면 여러 이슈를 추가하여 조건부 검사를 진행할 수 있다.

  import { z } from 'zod';
  

export const RegisterSchema = z.object({ productName: z.string().superRefine((value, ctx) => { const name = value.replaceAll(' ', ''); if (name.length === 0 || name.length < 2) { ctx.addIssue({ code: z.ZodIssueCode.custom, message: '제목은 공백을 제외하고 2자 이상 입력해 주세요.', }); } if (name.length > 30) { ctx.addIssue({ code: z.ZodIssueCode.custom, message: '제목은 최대 30자 이하로 입력해 주세요.', }); } }), minPrice: z.string().superRefine((value, ctx) => { const num = Number(value.replace(/[^\d]/g, '')); if (num < 1000) { ctx.addIssue({ code: z.ZodIssueCode.custom, message: '최소 1000원 이상 입력해 주세요.', }); }

if (num > 2_000_000) {
  ctx.addIssue({
    code: z.ZodIssueCode.custom,
    message: '2,000,000원 이하로 입력해 주세요.',
  });
}

if (num % 1000 !== 0) {
  ctx.addIssue({
    code: z.ZodIssueCode.custom,
    message: '1000원 단위로 입력해 주세요.',
  });
}

}), description: z .string() .superRefine((value, ctx) => { const name = value.replaceAll(' ', ''); const newLineCount = (value.match(/\n/g) || []).length; if (name.length > 1000) { ctx.addIssue({ code: z.ZodIssueCode.custom, message: '상품 설명은 최대 1000자 이하로 입력해 주세요.', }); } if (newLineCount > 10) { ctx.addIssue({ code: z.ZodIssueCode.custom, message: '상품 설명은 줄바꿈을 10개 이하로 입력해 주세요.', }); } }) .or(z.literal('')), });

### FormField 컴포넌트 구현
재사용가능한 컴포넌트로 분리하여 재사용성을 높인다.
```tsx
import { ReactElement } from 'react';
import { Control, Controller, ControllerRenderProps, FieldValues, Path } from 'react-hook-form';
import { ErrorMessage } from './ErrorMessage';

interface FormFieldProps<T extends FieldValues> {
  name: Path<T>;
  control: Control<T>;
  label?: string;
  render: (field: ControllerRenderProps<T>) => ReactElement;
  error?: string;
}

export const FormField = <T extends FieldValues>({ name, control, label, render, error }: FormFieldProps<T>) => {
  return (
    <div className='relative flex flex-col gap-2'>
      <label htmlFor={label} className='cursor-pointer text-body2 web:text-heading3'>
        {label}
      </label>
      <Controller name={name} control={control} render={({ field }) => render(field)} />
      {error && <ErrorMessage message={error} />}
    </div>
  );
};

Form 컴포넌트 구현

React Hook Form과 Zod를 통합해 Form을 작성한다.

import { FormField } from "@/shared";
import { zodResolver } from "@hookform/resolvers/zod";
import { SubmitHandler, useForm } from "react-hook-form";
import { z } from "zod";

// 작성한 스키마로 타입 추론
type FormFields = z.infer<typeof RegisterSchema>;

export const Form = () => {
  const {
    control,
    handleSubmit,
    formState: { errors },
  } = useForm<FormFields>({
    defaultValue: {
      productName: '',
      description: '',
      minPrice: '',
    },
    // zodResolver로 연결
    resolver: zodResolver(RegisterSchema),
  });

  const onSubmit: SubmitHandler<FormFields> = async (data) => {
    // submit 로직
  };

  return (
    <Layout.Main>
      <form onSubmit={handleSubmit(onSubmit)}>
        <FormField
          label='제목*'
          name='productName'
          control={control}
          error={errors.productName?.message}
          render={(field) => <Input id='제목*' type='text' placeholder='제목을 입력해주세요.' {...field} />}
          />
        <FormField
          label='시작 가격*'
          name='minPrice'
          control={control}
          error={errors.minPrice?.message}
          render={(field) => (
            <Input
              id='시작 가격*'
              type='number',
              placeholder='최소 시작가는 1,000원입니다.'
              {...field}
              />
          )}
          />
        <FormField
          label='상품 설명'
          name='description'
          control={control}
          error={errors.description?.message}
          render={(field) => (
            <Textarea
              id='상품 설명'
              placeholder='경매에 올릴 상품에 대해 자세히 설명해주세요.(최대 1,000자)'
              {...field}
              />
          )}
          />
      </form>
    </Layout.Main>
  );
}

결과

매우 깔끔하다.

출처

react hook form 공식문서 zod 공식문서 React Hook Form - Complete Tutorial (with Zod) [번역]스키마 유효성 검사 라이브러리 비교: Zod vs. Yup React: 제어 컴포넌트와 비제어 컴포넌트의 차이점 React Hook Form: Schema validation using Zod

리액트에서 일반적으로 Modal은 상태를 선언하고 이를 조작하여 열고 닫는 형태로 구현된다.

const App = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div>
      <button onClick={() => setIsOpen(true)}>모달 열기</button>
      {isOpen && <Modal onClose={() => setIsOpen(false)} />}
    </div>
  );
};

문제점

이 방식은 직관적이고 간단하지만, Modal이 늘어날수록 같은 상태와 조작 로직을 중복 작성하게 된다. 특히 Modal을 여러 곳에서 사용해야 하는 경우, 유지 보수성이 떨어지고 상태 관리가 번거로워진다.

해결방안

Compound Component Pattern과 React Portal을 사용하면 Modal을 보다 유연하고 재사용 가능하며 유지 보수성이 높은 컴포넌트로 개선할 수 있다.

Compound Component Pattern

기본 개념

Compound Component Pattern은 부모 컴포넌트와 여러 자식 컴포넌트가 하나의 상태를 공유하여 협력적으로 동작하도록 만드는 패턴이다. 예를 들어 HTML의 select와 option처럼 동작한다.

<label for="pet-select">Choose a pet:</label>

<select name="pets" id="pet-select">
  <option value="">--Please choose an option--</option>
  <option value="dog">Dog</option>
  <option value="cat">Cat</option>
  <option value="hamster">Hamster</option>
  <option value="parrot">Parrot</option>
  <option value="spider">Spider</option>
  <option value="goldfish">Goldfish</option>
</select>

리액트에서의 Compound Component 구현 예시

1. Context 생성 및 부모 컴포넌트 구현

컴포넌트 간 상태를 공유하기 위해 Context를 생성한다.

const FlyOutContext = createContext();

function FlyOut(props) {
  const [open, toggle] = useState(false);

  const providerValue = { open, toggle };

  return (
    <FlyOutContext.Provider value={providerValue}>
      {props.children}
    </FlyOutContext.Provider>
  );
}

2. 자식 컴포넌트 생성

FlyOut에서 사용할 자식 컴포넌트를 구현한다. 자식 컴포넌트는 Context를 통해 부모의 상태를 공유한다.

function Toggle() {
  const { open, toggle } = useContext(FlyOutContext);

  return (
    <div onClick={() => toggle(!open)}>
      <span>Toggle</span>
    </div>
  );
}

function List({ children }) {
  const { open } = useContext(FlyOutContext);

  return open && <ul>{children}</ul>;
}

function Item({ children }) {
  return <li>{children}</li>;
}

3. 부모 컴포넌트에 자식 컴포넌트 연결

부모 컴포넌트의 static 속성으로 자식 컴포넌트를 추가하여 부모 컴포넌트만 import하면 자식 컴포넌트를 사용할 수 있게 한다.

FlyOut.Toggle = Toggle;
FlyOut.List = List;
FlyOut.Item = Item;

사용 예시

FlyOut 컴포넌트를 사용하여 FlyoutMenu를 구성한다. FlyoutMenu 컴포넌트는 자체적인 상태를 가지지 않는다.

import { FlyOut } from './FlyOut'

function FlyoutMenu() {
  return (
    <FlyOut>
      <FlyOut.Toggle />
      <FlyOut.List>
        <FlyOut.Item>Edit</FlyOut.Item>
        <FlyOut.Item>Delete</FlyOut.Item>
      </FlyOut.List>
    </FlyOut>
  )
}

React Portal

React Portal은 컴포넌트를 부모 컴포넌트의 계층 구조 밖에 있는 DOM 노드의 자식 컴포넌트로 렌더링하는 방법을 제공한다.

특징

독립적 스타일링

부모 컴포넌트의 계층 구조 밖에서 컴포넌트를 렌더링하기 때문에 부모 컴포넌트의 스타일에 영향을 받지 않는다. 상위 컴포넌트의 overflow: hidden 과 같은 설정과의 충돌을 피할 수 있고 z-index와 같은 속성을 쉽게 제어할 수 있어 스타일링이 간단해진다.

이벤트 버블링

Portal로 렌더링된 컴포넌트는 시각적으로 부모 컴포넌트 외부에서 렌더링되지만, 여전히 리액트의 상태나 이벤트와 연결되어 있어 이벤트 버블링이 정상적으로 동작한다.

사용 예시

ReactDOM의 createPortal 함수를 사용하여 JSX와 렌더링할 위치의 부모 DOM node 를 인수로 전달한다.

import React from 'react';
import { createPortal } from 'react-dom';

function Portal({ children }) {
  return createPortal(
    <div className="modal">{children}</div>,
    document.body
  );
}

Modal 구현

목표

1. Compound Component Pattern을 활용하여 상태와 로직을 Modal 컴포넌트 내부로 캡슐화함으로써 재사용성을 높인다.
2. React Portal을 활용하여 스타일 충돌 방지 및 유연한 Modal 렌더링을 가능하게 한다.

   구현 과정

   1. Context 생성

   const ModalContext = createContext({
   openName: '',
   open: (name: string) => { },
   close: () => { }
   });

   2. 부모 컴포넌트 생성

   Modal의 상태와 함수를 Context Provider로 관리한다.

export const Modal = ({ children }: { children: ReactNode }) => {
  const [openName, setOpenName] = useState('')
  const close = () => setOpenName('')
  const open = (name: string) => setOpenName(name);

  return <ModalContext.Provider value={{ openName, open, close }}>
    {children}
  </ModalContext.Provider>
}

3. Open 컴포넌트 생성

Modal을 열기 위한 트리거 컴포넌트로, 버튼 같은 트리거 요소를 감싼다.

const Open = ({ children, name }: { children: ReactElement, name: string }) => {
  const { open } = useContext(ModalContext)

  return cloneElement(children, { onClick: () => open(name) })
}

4. Window 컴포넌트 생성

Modal UI를 렌더링하며 Portal을 활용한다.

const Window = ({ children, name }: { children: ReactElement, name: string }) => {
  const { openName, close } = useContext(ModalContext)

  if (openName !== name) return null

  return createPortal(
    <div className="absolute inset-0 z-50 flex items-center justify-center" onClick={handleClose}>
      <div
        className="relative z-50 flex items-center justify-center h-full w-web min-w-mobile bg-black/50"
      >
        {cloneElement(children, { onCloseModal: close })}
      </div>
    </div >,
    document.body,
  );
};

부모와 자식 연결

Modal에 Open과 Window를 연결한다.

Modal.Open = Open;
Modal.Window = Window;

사용 예시

버튼을 클릭하면 ConfirmModal을 띄우는 예제이다.

interface ConfirmProps {
  children: ReactNode
  onCloseModal?: () => void
}

// Modal 컴포넌트에서 onCloseModal 속성에 close 함수를 정의한다.
const Confirm = ({ children, onCloseModal }: ConfirmProps) => {
  return (
    <div onClick={(e) => e.stopPropagation()} >
      <div>
        Modal 내용...
      </div>
      <div>
        <button type='button' onClick={onCloseModal} >
          닫기
        </button>
        {children}
      </div>
    </div>
  );
}

const Details = () => {
  const { mutate: cancelBid } = useCancelBid()
  const clickCancel = () => cancelBid()

  return (
    <Modal>
      <Modal.Open name="cancelBid">
        <button>
          참여 취소
        </button>
      </Modal.Open>
      <Modal.Window name="cancelBid">
        <Confirm type="cancelBid" >
          <button onClick={clickCancel}>
            참여 취소
          </button>
        </Confirm>
      </Modal.Window>
    </Modal>
  );
}

결과

개발자 도구에서 확인하면 body태그에 Modal이 렌더링된 것을 볼 수 있다.

출처

Compound Pattern MDN HTML select What are React Portals? React Portals 공식문서

// 현재 프로젝트의 폴더 구조
└─src
    ├─api
    ├─assets
    ├─components
    ├─constants
    ├─hooks
    ├─lib
    ├─mocks
    ├─pages
    ├─provider
    ├─store
    ├─utils
    └─types

현재 프로젝트의 폴더 구조는 Monolith 구조로, 모든 코드와 기능이 기술적 요소별로 한곳에 모여있다. Monolith 구조는 기능적 역할보다는 코드의 기술적 속성에 중점을 두어 폴더를 구성하기 때문에, 프로젝트 초기에는 코드 탐색이 단순하고 명확하다는 장점이 있다. 그러나 프로젝트 규모가 점차 커질수록 의존성 관리, 확장성, 협업 효율성 등의 문제가 발생하며 Monolith 구조의 한계가 명확해진다.

Monolith 구조의 문제점

의존성 문제

서로 다른 폴더의 코드들이 서로를 참조하는 과정에서 순환 참조 문제가 발생할 수 있다. 이는 예기치 못한 동작을 유발하거나 디버깅을 어렵게 만들어 각 기능이 명확히 분리되지 않는 상황에서 특정 기능과 관련된 코드를 추적하고 의존 관계를 파악하는 데 많은 시간이 소요된다.

확장성 문제

Monolith 구조에서는 코드가 기술적 요소로만 구분되어 있어 기능별로 캡슐화되지 않는다. 따라서 새로운 기능을 추가하거나 기존 기능을 수정할 때 예상치 못한 의존성 문제가 발생할 수 있다. 결과적으로 프로젝트가 커질수록 복잡도가 증가하고 유지보수가 어려워진다.

협업 비효율성

기술 기반으로 분류된 폴더에서는 개발자들이 같은 폴더 내에서 작업해야 하는 경우가 많아지면서 기능 간 충돌이 발생할 가능성이 커진다. PR을 통해 코드 리뷰를 해서 이러한 문제를 막을 수 있지만, 코드 리뷰가 길어지는 시간 또한 리소스 낭비이다. 서로 다른 개발자가 특정 기능을 구현할 때 일관된 기준 없이 폴더와 파일을 생성하다 보면, 구조의 일관성이 깨지기 쉬워진다. 예를 들어 한 개발자는 components 폴더에 모든 컴포넌트를 넣는 반면, 다른 개발자는 페이지에 종속된 컴포넌트를 따로 관리하고 싶어할 수도 있기 때문에 협업 시 불필요한 코드 중복과 혼란이 발생할 수 있다.

유지 보수의 어려움

기술 기반으로 분류된 폴더에서는 폴더 구조를 변경하는 작업이 코드 전체에 영향을 미치기 쉽다. 특히, 각 폴더에 분산된 코드가 서로 얽혀 있다면 폴더 구조를 바꾸는 작업은 순환 참조나 의존성 문제를 더 심화시킬 수 있다. 기술적인 기준만을 고려한 구조에서는 기능별로 코드가 분리되지 않아 재사용성이 떨어지고 응집력 또한 낮아진다. 이로 인해 코드의 유지보수가 어려워지고, 기능 확장 시에도 새로운 폴더나 파일을 만들면서 계속해서 복잡해진다.

정리

Monolith 구조는 간단한 프로젝트에서는 빠르게 사용할 수 있지만, 프로젝트가 커질수록 유지보수, 협업, 확장성 등 다양한 측면에서 한계를 드러내는 구조다. 이를 해결하기 위해 각 기능 단위로 코드를 분리하고 의존 관계를 명확히 관리할 수 있는 FSD(Feature Sliced Design)와 같은 구조가 점점 더 필요한 이유가 된다.

FSD(Feature Sliced Design) 소개

FSD(Feature Sliced Design)는 애플리케이션의 기능을 중심으로 코드를 구조화하는 설계 패턴이다. 여기서 기능 중심이란, 코드를 기술적인 요소로 분류하는 대신 비즈니스 로직에 따라 각 기능별로 독립된 모듈로 나눈다는 의미이다. 이러한 기능 단위의 모듈화를 통해 각 기능이 독립적으로 개발, 테스트, 유지보수될 수 있도록 만든다. FSD는 코드가 확장성과 유지보수성이 뛰어나도록 설계되어 있어, 개발 팀이 협업하는 과정에서 효율성을 크게 증진시켜준다.

주요 목적

FSD의 주요 목적은 코드를 기능 단위로 모듈화하여, 확장성과 유지보수성을 높이는 것이다. 기능 중심의 코드 구조는 팀 단위로 작업할 때 특정 기능의 코드에만 집중할 수 있게 하며, 기능별로 코드가 모듈화되어 있어 변경사항이 다른 기능에 미치는 영향을 최소화할 수 있다. 이를 통해 코드의 가독성을 높이고, 복잡성을 줄여 효율적인 협업을 가능하게 해준다.

FSD의 핵심 원칙

1. 기능 중심 설계 애플리케이션을 기능 단위로 구분하여 설계한다. 이는 각 기능이 독립적인 모듈로 구분되어, 개발과 테스트, 유지보수가 기능별로 독립적으로 이루어질 수 있게 하는 방식이다.

2. 계층화 코드를 여러 계층으로 나누어 관심사를 분리한다. 예를 들어, UI 계층과 비즈니스 로직 계층을 구분하여 코드 간섭을 줄이고, 특정 계층만 수정해도 다른 계층에 영향을 주지 않도록 한다. 이를 통해 코드를 탐색하거나 유지보수할 때 필요하지 않은 코드까지 볼 필요가 없어져 코드의 일관성을 유지할 수 있다.

3. 단방향 의존성 상위 계층은 하위 계층에만 의존할 수 있도록 제한한다. 이는 특정 기능이 상위 계층으로 올라가면서도 하위 계층의 기능을 참조하는 구조를 막아주어, 의존 관계가 복잡하게 얽히지 않도록 한다.

4. 공개 API 각 모듈이 명확한 공개 API를 통해 다른 모듈과 상호작용하게 한다. 각 모듈이 제공하는 기능은 공개 API를 통해서만 접근할 수 있고, 그 외의 세부 구현은 외부로 노출되지 않아 캡슐화가 잘 유지된다. 이로 인해 코드 수정이 필요한 경우 외부에 미치는 영향을 최소화할 수 있다.

   FSD의 구성 요소

   

   레이어

   레이어는 FSD의 가장 상위 수준의 구조 6개로 제한되어 있으며 표준화되어 있다. 상위 레벨에 있는 레이어는 하위 레벨을 의존성으로 가질 수 있지만 그 반대는 성립될 수 없고, 하위 레이어로 갈수록 추상화가 심화되며 상위 레이어로 갈수록 비즈니스 로직이 심화된다.

   app

   애플리케이션 초기화 및 글로벌 설정을 정의한다. 애플리케이션의 진입점, 전역 상태 관리, 라우팅 설정, 전역 스타일 파일이 있다. 슬라이스 없이 세그먼트로 나눈다.

   pages

   각 라우트에 해당하는 페이지 컴포넌트를 정의한다.

   widgets(선택적 레이어)

   독립적으로 작동하는 대규모 기능 또는 UI 컴포넌트, 보통 하나의 완전한 기능을 정의한다. 즉 UI와 로직이 결합된 독립적인 기능 단위로 페이지의 특정 기능을 담당한다.

   features

   사용자의 특정 상호작용과 비즈니스 로직을 정의한다. 특정 작업과 관련된 로직과 UI 요소를 포함하며, 사용자 시나리오에 따른 기능을 정의한다.

   entities(선택적 레이어)

   애플리케이션 전반에서 반복적으로 사용되는 핵심 비즈니스 데이터 모델 및 도메인 객체를 정의한다. 예를 들어 데이터의 타입 정의와 기본적인 데이터 구조, 데이터에 대한 기본적인 연산이나 로직 관련된 유틸리티 함수나 상수가 있다.

   shared

   비즈니스 로직에 의존하지 않으면서 애플리케이션 전반에서 사용되는 공통 유틸리티 및 UI 컴포넌트를 정의한다. 슬라이스 없이 세그먼트로 나눈다.

슬라이스

슬라이스는 각 레이어 내에서 특정 기능 영역이나 도메인을 나타내는 하위 디렉토리이다.

목표

• 슬라이스를 통해 특정 비즈니스 도메인이나 기능을 캡슐화한다.

• 독립적으로 개발 및 테스트를 한다.

• 다른 슬라이스와의 의존성을 명시적으로 관리한다.

• 레이어에서 슬라이스끼리 기능을 공유하지 않고 독립적으로 사용한다.

  세그먼트

  세그먼트는 슬라이스 내부의 코드를 목적에 따라 더 세분화한 것이다. 세그먼트의 이름은 ui, model, lib, api등이 될 수 있으며 예시는 아래와 같다.

• api - 외부 서비스와의 통신.

• UI - UI 컴포넌트.

• model - 비즈니스 로직,상태와의 상호 작용, actions 및 selectors 등.

• lib - 슬라이스 내에서 사용되는 보조 기능, 유틸리티 함수, 헬퍼 함수, 훅.

• config - 설정 및 상수

  Public API

  Public API는 각 슬라이스나 세그먼트가 외부에 노출하는 인터페이스이다. index.js 또는 index.ts 파일이며, 이 파일을 통해 슬라이스 또는 세그먼트에서 필요한 기능만 외부로 추출하고 불필요한 기능은 격리할 수 있다.

  목표

• 캡슐화: Public API는 폴더 외부로 필요한 것만 노출하도록 하여 내부 구조를 감추는 역할을 한다. 만약 모든 파일을 외부에서 직접 import하도록 허용하면, 해당 feature의 구조가 외부에 그대로 노출되어 캡슐화가 깨진다.

• 일관성 유지: 여러 팀원이 작업할 때, Public API를 통한 import 경로가 있으면 모든 코드에서 동일한 경로를 사용하게 되어 일관성이 유지된다.

• 유지보수성: Public API를 통해 노출된 파일만 공식 API로 간주하고, 내부 파일의 구조가 변경되더라도 외부에서는 이를 알 필요가 없기 때문에 유지보수가 용이하다.

• 간결한 import 경로: Public API 덕분에 import 경로가 간결해지며, 특정 feature의 모든 export를 한 경로로 모을 수 있다.

장점

1. 확장성

   • 새로운 기능을 추가하거나 기존 기능을 수정하기에 용이하다. 기능이 명확하게 분리되어 있어 코드베이스가 커지더라도 각 기능을 독립적으로 다룰 수 있으며, 전체 코드에 영향을 주지 않으면서 특정 기능을 확장할 수 있기 때문이다.

2. 모듈성

   • 각 기능이 독립적인 모듈로 구성되어 있어 재사용성과 유지보수성이 높아진다. 다른 기능에 종속되지 않고 독립적으로 동작하기 때문에 기능 단위로 쉽게 유지보수할 수 있는 구조이다.

3. 테스트 용이성

   • 기능별로 코드가 분리되어 있어 각 기능을 독립적으로 테스트하기가 용이하다. 슬라이스와 세그먼트 단위로 테스트가 가능해 에러 발생 시 디버깅이 수월하다는 장점이 있다.

4. 팀 협업 효율성

   • 기능 단위로 작업을 분배하여 병렬로 개발할 수 있다. 각 개발자가 독립된 기능을 담당하므로 작업 간섭이 줄어들고, 협업 시 코드 충돌 가능성도 낮아진다.

5. 코드 탐색과 유지보수의 편리함

   • 일관된 구조 덕분에 코드 탐색이 쉽다. 프로젝트 내에서 필요한 코드의 위치를 빠르게 파악할 수 있어 유지보수가 수월하고, 새로운 팀원이 합류해도 구조를 이해하기가 용이하다.

6. 의존성 관리

   • 명시적으로 의존성을 관리하여 코드의 예측 가능성이 높아진다. 단방향 의존성을 유지해 구조가 명확해지므로 코드 복잡성을 줄일 수 있다.

단점

1. 리팩토링 비용

   • 처음부터 FSD를 사용하지 않았다면, 마이그레이션 과정에서 큰 리팩토링 비용이 발생할 수 있다. 특정 코드를 어디에 배치해야 할지 고민해야 하는 등 초기 생산성이 낮아질 가능성도 크다.

2. 오버엔지니어링 위험

   • 작은 프로젝트에서는 FSD 구조가 오히려 복잡성을 높일 수 있다. 작은 프로젝트에서 기능 중심 구조는 단순한 구조보다 효율이 떨어질 수 있어 불필요하게 복잡해질 수 있다.

3. Public API 관리

   • Public API를 설정해 각 모듈에 접근할 때 진입점을 정의하지만, 파일 경로나 폴더 구조가 변경되면 Public API 파일도 수정해야 해 추가적인 리팩토링 작업이 발생할 수 있다.

4. 협업 과정에서의 온보딩 시간

   • FSD 규칙을 프로젝트 전반에 일관되게 적용해야 하므로 팀원 온보딩에 시간이 소요될 수 있다. 모든 팀원이 규칙에 따라 코드를 작성해야 해 협업 초기에는 일관성 유지를 위해 학습 곡선이 존재한다.

barrel 파일 순환 참조 에러 발생

barrel file이란?

barrel file은 하나의 파일에서 여러 모듈을 re-export 하는 역할만 하는 파일을 의미한다. 보통 index.ts 또는 index.js라는 이름을 사용하며, 폴더 내부의 구조를 외부에 감추고 단일 엔트리 포인트로 노출하기 위해 사용한다.

이를 통해 내부에서 모듈 위치가 변경되어도 소비자 측에서는 폴더 경로 변경 없이 일관된 import를 유지할 수 있으며, import 문을 깔끔하게 정리할 수 있다.

barrel file의 문제점

순환 참조 및 트리 쉐이킹 문제

폴더 내부의 모듈이 내부 다른 모듈을 import할 때 import문을 잘못 작성(대부분 자동 경로를 사용)하는 경우, 직접 참조가 아닌 배럴 파일 통해 import하기 때문에 순환 참조가 발생할 수 있다.

순환 참조는 두 개 이상의 모듈이 서로를 직접 또는 간접적으로 참조할 때 발생하는 상황을 말한다. 이런 순환 참조는 코드 가독성과 유지보수 어렵게 하고, 빌드 및 번들링 과정에서 트리 쉐이킹과 같은 최적화가 제대로 이루어지지 않을 가능성 크다. 결과적으로 불필요한 코드가 번들에 포함되거나, 번들 크기가 비정상적으로 커질 수 있다.

불필요한 모듈 로딩

barrel file에서 특정 모듈 불러오면 자바스크립트는 먼저 barrel file을 열어 내부의 모든 export를 확인한다. 이 과정에서 파일 내에 존재하는 모든 모듈들이 동기적으로 로드된다. 몇 개의 export만 있다면 상관없는데, 많은 모듈을 export하거나 일부 모듈이 다시 다른 barrel file을 포함하고 있다면 한 번의 import 로 실제로는 사용하지 않는 많은 모듈까지 모두 로드된다. 불필요하게 많은 모듈이 동시에 로드되면, 특히 개발 모드에서 페이지 시작 시 로딩 시간이 급격히 늘어날 수 있다.(빌드 환경에서는 트리 쉐이킹으로 실제 사용되지 않는 코드는 제외될 수 있음.)

주의사항 및 권장사항

• 라이브러리 작성 제외하고는 barrel file 사용 지양할 것을 추천.
• 내부 참조 시 barrel file 대신 직접 경로 사용.
• import/no-cycle eslint 규칙 적용
  • eslint-plugin-import에서 제공하는 규칙 중 하나로, 모듈 간에 순환 참조(circular dependency)가 발생하는 것을 감지하고 경고 또는 에러를 발생시킨다.
  • ESLint가 코드 내의 import 구문들을 분석하여, 모듈 간의 의존성 그래프를 생성한다.
• madge 라이브러리 통해 시각적 의존성 확인

참고 자료

tkdodo barrel files

출처

FSD 공식 문서 (번역) 기능 분할 설계 - 최고의 프런트엔드 아키텍처 feature-sliced/examples 기능 분할 설계(FSD)를 이용한 FE 아키텍처 구성 FSD 아키텍처 알아보기 기능 분할 설계(Feature-Sliced Design, FSD) Feature-Sliced Design을 직접 사용하면서 느낀 장점과 단점 프론트엔드 개발자 관점으로 바라보는 관심사의 분리와 좋은 폴더 구조 (feat. FSD)

이 현상을 이해하려면 한글의 입력 방식과 브라우저의 처리 방식 차이를 살펴봐야 한다.

한글 입력 방식

한글은 다른 언어와 다르게 자음과 모음이 조합되어 완성된 한 글자가 만들어진다. 예를 들어, 'ㅎ'과 'ㅏ'를 입력하면 '하'가 되는 식이다. 이 과정에서 사용자가 키보드로 자음과 모음을 입력할 때마다 입력 중인 문자를 브라우저에 보낸다.

브라우저의 숫자 입력 처리

input 타입이 number일 때, 브라우저는 기본적으로 숫자 외의 입력을 막도록 설계되어 있다. 하지만 한글 입력의 특수성 때문에 자음 또는 모음 하나만 먼저 전송하는 경우가 생겨서 한글의 첫 자음 또는 모음이 입력창에 들어가게 된다. 브라우저는 이 상황을 제대로 처리하지 못하고, 첫 글자를 일시적으로 보여준 다음에서야 숫자가 아닌 입력임을 인지하고 차단하게 된다.

해결 방법

여러 방법이 있을 수 있겠으나, 이 글에서는input에서 숫자가 아닌 문자가 입력되는 것을 실시간으로 감지하는 oninput 이벤트를 사용한다.

예제

리액트에서는 onInput 이벤트를 사용한다.

 const preventInvalidInput = (event: ChangeEvent<HTMLInputElement>) => {
    // 숫자가 아닌 입력값과 한글 입력을 필터링한다.
    event.target.value = event.target.value.replace(/[^0-9]/g, '');
  };

<input
  type='number'
  onInput={preventInvalidInput}
/>

onInput과 onChange의 차이

• onInput: 값이 변경될 때마다 호출된다. 즉, 사용자가 키를 누를 때마다 실시간으로 이벤트가 발생하므로 실시간 검증이나 필터링 작업에 적합하다. 키 입력마다 호출되기 때문에 복잡한 처리가 들어가면 성능에 영향을 줄 수 있다.

• onChange: 입력을 마치고 포커스를 잃거나 Enter를 눌러야만 호출된다. 입력이 완료된 후의 처리가 필요한 경우에 적합하다.

원문: https://www.brandondail.com/posts/fault-tolerance-react

Fault Tolerance

모던 웹 애플리케이션을 구축하는 것은 변화하는 요소가 많은 복잡한 과정입니다. 때로는 이러한 요소들이 변화를 멈추면서 문제가 발생하기도 합니다.

우리는 이러한 문제가 발생하지 않도록 할 수 있는 모든 것을 하지만, 완전히 에러가 없는 상태를 유지하는 것은 현실적으로 불가능합니다. 즉 예상치 못한 방식으로 문제가 발생할 수 있다는 것을 항상 염두에 두어야 하며, 그럴 때 이를 우아하게 처리할 수 있어야 합니다.

다시 말해, 우리는 Fault Tolerance(장애 허용성)가 필요합니다.

Fault Tolerance 란 시스템의 일부 구성 요소에 장애가 발생하더라도 시스템이 정상적으로 작동을 계속할 수 있게 하는 특성을 말합니다.

내 경험상 Fault Tolerance은 웹 애플리케이션에서 종종 간과되고 과소평가됩니다. 잠재적으로 문제가 발생하지 않을 것이라는 자신감을 주는 수백 개의 테스트가 있을 수 있지만, 불가피한 장애가 발생했을 때 어떻게 대응할지에 대해서는 충분히 고려하지 않습니다. 이는 High availability(고가용성)을 우선시하는 경우 특히 중요합니다

그렇다면 리액트 애플리케이션에서 Fault Tolerance를 어떻게 구현할 수 있을까요?

Error Boundaries

답은 바로 error boundaries입니다. 현재 이 API는 클래스 컴포넌트에서만 사용 가능하며, 다음과 같은 형태로 보입니다.

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    // You can also log the error to an error reporting service
    logErrorToMyService(error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      return <h1>Something went wrong.</h1>;
    }

    return this.props.children; 
  }
}

💬 리액트에서 error boundary는 getDerivedStateFromError메서드와 componentDidCatch 메서드를 가진 클래스 컴포넌트입니다. 처음 사용하기에 좋은 예시를 원하신다면, 다음을 확인해보세요. react-error-boundary

리액트 공식 문서에서 error boundaries가 무엇인지와 사용하는 방법에 대해 매우 잘 설명하고 있으니, 제가 이 부분에 대해 길게 설명하지는 않겠습니다. 먼저 공식 문서를 읽어보시고, 기본적인 내용을 잘 이해한 후 다시 돌아오시면 좋을 것 같습니다.

Drawing the Right Fault Lines

애플리케이션에 error boundary를 추가하는 것은 쉽습니다. 몇 줄의 코드만으로 구현할 수 있죠. 어려운 점은 error boundary를 배치할 적절한 곳을 찾는 것입니다. 보통은 골디락스 원칙을 따르고, "적당한 양"의 error boundaries를 구현하는 것이 이상적이지만 그 "적당한 양"이란 무엇일까요?

먼저, 두 가지 극단적인 상황을 살펴보고 각각의 단점을 이해해 봅시다.

Not Enough Error Boundaries

첫 번째 극단적인 상황: 애플리케이션 최상단에 단 하나의 error boundary를 배치하는 경우입니다.

// ⚠️ 이번 예시들에서는 react-error-boundary 라이브러리를 사용할 것입니다.
import ErrorBoundary from "react-error-boundary";
import App from "./App.js";

ReactDOM.render(
  <ErrorBoundary>
    <App />
  </ErrorBoundary>,
  document.getElementById("root")
);

이 방법은 아마 대부분의 사람들이 사용하는 방식에 가까울 것입니다. 이는 서버 렌더링 애플리케이션이 실패할 때 발생하는 상황과 본질적으로 비슷합니다. 결코 나쁘지 않지만, 최선의 방법이라고는 할 수 없습니다. 문제는 하나에서 장애가 발생하면, 애플리케이션의 나머지 부분도 모두 장애가 발생한다는 점입니다.

애플리케이션 일부에서 발생한 장애가 애플리케이션 전체를 사용할 수 없음을 의미할 때 이는 옳은 방법일 수 있습니다. 앞선 접근 방식이 옳은 경우가 분명 있지만, 일반적인 경우는 아니라고 생각합니다.

Fault Tolerance의 정의로 돌아가 보면

Fault Tolerance는 시스템의 일부에서 장애가 발생해도 시스템이 정상적으로 작동을 계속할 수 있게 하는 특성을 말합니다.

단일 error boundary 방식은 하나의 장애가 전체 애플리케이션을 무너트리기 때문에 Fault Tolerance을 제대로 구현할 수 없다는 것을 알 수 있습니다.

Too Many Error Boundaries

다른 극단적인 경우로 넘어가 보면, 모든 컴포넌트를 error boundary로 감싸는 방법을 시도할 수 있습니다. 이 접근 방식의 문제는 쉽게 규정 지을 수 없기 때문에, 이것이 왜 단일 error boundary보다 나쁠 수 있는지 구체적인 예시를 통해 살펴보겠습니다.

예를 들어, 사용자가 장바구니를 확인하고, 신용카드 정보를 입력하며, 구매를 완료할 수 있는 컴포넌트가 있다고 가정해 봅시다.

function CheckoutForm(props) {
  return (
    <form>
      <CartDescription items={props.items} />
      <CreditCardInput />
      <CheckoutButton cartId={props.id} />
    </form>
  );
}

이제 모든 컴포넌트를 error boundary로 감싸봅시다.

<form>
  <ErrorBoundary>
    <CartDescription items={props.items} />
  </ErrorBoundary>
  <ErrorBoundary>
    <CreditCardInput />
  </ErrorBoundary>
  <ErrorBoundary>
    <CheckoutButton cartId={props.id} />
  </ErrorBoundary>
</form>

🤚 실제 예시에서는 각 컴포넌트가 자신의 export 부분을 error boundary로 감싸는 방식일 것입니다. (예를 들어, react-error-boundary의 withErrorBoundary HOC 패턴 을 사용하는 방식처럼요.) 하지만 여기서는 그 부분은 무시하고 보셔도 됩니다. 🙂

처음에는 이것이 괜찮은 아이디어처럼 보일 수 있습니다. error boundaries를 더 세분화할수록, 하나의 장애가 애플리케이션 전체에 미치는 영향이 줄어들기 때문이죠. 이를 Fault Tolerance라고 할 수도 있습니다! 그러나 문제는 error의 영향을 최소화하는 것이 곧 Fault Tolerance을 의미하지는 않는다는 점입니다.

예를 들어, 컴포넌트에서 어떤 문제가 발생했다고 가정해 봅시다.

<form>
  <ErrorBoundary>
    <CartDescription items={props.items} />
  </ErrorBoundary>
  <ErrorBoundary>
    {/* 에러 발생 😢 */}
    <CreditCardInput />
  </ErrorBoundary>
  <ErrorBoundary>
    <CheckoutButton cartId={props.id} />
  </ErrorBoundary>
</form>

이 상황이 사용자 경험(UX)에 어떤 영향을 미칠지 살펴보면, 이것이 사용자에게 큰 불편을 줄 수 있다는 것을 알 수 있습니다.

Half-Broken UI is Full-Broken UX

<CreditCardInput /> 컴포넌트가 자체적인 error boundary를 가지고 있기 때문에, 에러가 발생해도 <CreditCardForm /> 컴포넌트의 나머지 부분으로 전파되지 않습니다. 하지만 <CreditCardInput /> 컴포넌트 없이는 <CreditCardForm /> 컴포넌트가 제대로 작동할 수 없죠 🤔. <CheckoutButton /> 컴포넌트와 <CardDescription />컴포넌트는 여전히 렌더링되기 때문에 사용자는 항목을 보고 결제를 시도할 수 있지만, 신용카드 정보를 다 입력하지 않았다면 어떻게 될까요? 만약 <CreditCardInput /> 컴포넌트에서 장애가 발생하기 전에 신용카드 정보를 입력했다면 그 상태는 유지될까요? 사용자가 결제를 시도하면 무슨 일이 일어날까요?

아마도 이 컴포넌트들의 작성자조차도 이 상황에서 어떤 일이 일어날지 확신하지 못할 겁니다. 하물며 사용자야 말할 것도 없죠. 이는 사용자에게 혼란스럽고 실망스러울 수 있습니다.

Generic Error Boundary, Generic Fallback

이 상황이 얼마나 혼란스럽고 답답한지는 fallback으로 무엇을 렌더링하느냐 에 따라 달라집니다. 만약 컴포넌트가 경고 없이 화면에서 갑자기 사라진다면, 대부분의 사용자들은 매우 혼란스러울 것입니다.

만약 그렇지 않다면, 아마도 공통 fallback UI를 사용하고 있을 겁니다. 아마도, sad face 😭 와 함께 에러에 대한 유용한 정보를 제공할 것입니다. 없는 것보다는 낫지만, 모든 컴포넌트를 error boundary로 감싼다면 fallback이 가능한 모든 UI 요소에 맞게 적절하게 렌더링되어야 한다는 의미입니다. 그러나 이는 거의 불가능에 가깝습니다. 왜냐하면 각각의 요소들은 서로 다른 레이아웃 요구 사항을 가지고 있기 때문이죠. page-level의 section(예: header)에 적합한 fallback은 작은 아이콘 버튼에 적합하지 않을 수 있으며, 그 반대의 경우도 마찬가지입니다.

문제의 핵심: 모든 컴포넌트를 error boundary로 감싸는 것은 사용자에게 혼란스럽고 불완전한 사용자 경험을 초래할 수 있습니다. 애플리케이션이 일관성 없는 상태로 변해, 사용자를 혼란스럽게 할 수 있습니다. 흥미로운 점은, 이러한 "망가진 상태"를 피하는 것이 바로 error boundary가 존재하는 주요 이유 중 하나라는 것입니다.

이 결정을 두고 많은 고민을 했지만, 우리의 경험상 망가진 UI를 그대로 남겨두는 것보다 완전히 제거하는 것이 더 나은 선택이라고 판단했습니다.

🏎 성능 저하 Error Boundaries는 어느 정도의 오버헤드를 수반하기 때문에, 남용할 경우 성능에 부정적인 영향을 미칠 수 있습니다. 하지만 이것은 error boundary를 모든 곳에 사용할 때만 문제가 되므로, 이 때문에 error boundary 사용을 두려워할 필요는 없습니다.

The Right Amount of Error Boundaries

정리하자면, error boundaries가 너무 적으면 불필요하게 애플리케이션의 더 많은 부분이 중단되고, 너무 많으면 망가진 UI state로 이어질 수 있습니다. 그렇다면 error boundaries는 몇 개가 적당할까요?

이는 애플리케이션에 따라 다르기 때문에 정확한 숫자를 말하기는 어렵습니다. 제가 찾은 최선의 방법은 애플리케이션의 feature boundaries를 식별한 후, 그 경계 지점에 error boundaries를 배치하는 것입니다.

Finding Features

임의의 애플리케이션을 보고 그 경계를 식별하는 데 사용할 수 있는 '기능'에 대한 보편적인 정의는 없습니다. "보면 안다"는 것이 일반적으로 우리가 할 수 있는 최선이지만, 참고할 수 있는 몇 가지 공통적인 패턴이 있습니다.

대부분의 애플리케이션은 개별 섹션들이 모여서 구성됩니다. 예를 들어 header, navigation, main content, sidebars, footers 등이 있죠. 이 각각의 섹션은 전체적인 사용자 경험에 기여하면서도 어느 정도 독립성을 유지합니다.

트위터(현 X)를 예로 들어 살펴보겠습니다:

한눈에 봐도 페이지에는 분명히 구분된 섹션들과 기능들이 존재합니다. 트윗을 보여주는 메인 타임라인, 팔로우 추천, 트렌드 섹션, 네비게이션 바가 있습니다. 이 섹션들의 레이아웃과 스타일링만 봐도 섹션 간의 분리가 있다는 것을 알 수 있으며, 이는 error boundaries를 배치하기에 좋은 시작점입니다. 시각적으로 독립적인 섹션은 기능적으로도 독립적일 가능성이 크고, 그런 곳에 error boundaries를 두는 것이 적절합니다.

만약 여러 섹션 중 하나의 섹션의 특정 컴포넌트에서 에러가 발생한다면, 다른 섹션까지 같이 중단되지 않아야 한다는 것은 타당해보입니다. 예를 들어, 팔로우 추천 섹션에서 팔로우 버튼이 장애를 일으켜도 메인 타임라인까지 멈추게 해서는 안 됩니다.

A Recursive Line of Questioning

UI는 종종 재귀적 구조를 가집니다. 페이지 레벨에서는 사이드바나 타임라인 같은 큰 섹션들이 있지만, 이 섹션들 내부에도 헤더나 리스트 같은 하위 섹션들이 있고, 그 안에도 또 다른 섹션들이 있습니다.

error boundaries를 어디에 배치할지 고민할 때, 스스로에게 던질 좋은 질문은 "이 컴포넌트에서 발생한 에러가 형제 컴포넌트들에게 어떤 영향을 미치는가?" 입니다. 예시에서 우리가 고려했던 질문도 바로 이것이었죠: 만약 CreditCardInput 이 실패하면 CheckoutButton과 CardDescription은 어떤 영향을 받을까요?

이 질문을 재귀적으로 컴포넌트 트리에 적용하면, 각 feature boundires를 쉽게 식별할 수 있고, 그 경계에 맞춰 error boundaries를 배치할 수 있습니다.

Twitter Deep Dive: The Page

다시 트위터를 예로 들어 이 접근 방식이 어떻게 작동하는지 살펴보겠습니다. 최상단부터 시작해서 팔로우 추천 섹션까지 자세히 파고들어 보겠습니다.

이 분석에는 제가 이 기능들이 어떻게 작동하는지에 대한 인식과 기대를 바탕으로 한 의견과 편견이 많이 포함되어 있습니다. 이는 "정답"을 제시하려는 것이 아니라 과정 자체에 대한 감을 잡기 위한 것입니다.

우리는 최상단부터 시작해서 세 가지 메인 컨텐츠 섹션을 확인할 수 있습니다: Home, Trends for you, 그리고 Who to follow. 이제 Who to follow 섹션을 자세히 살펴보겠습니다.

먼저 스스로에게 질문합니다:

이 컴포넌트에서 발생한 에러가 형제 컴포넌트들에게 어떤 영향을 미치는가?

이 질문을 더 구체적으로 바꿔보면:

이 컴포넌트가 고장나면 형제 컴포넌트도 고장나야 할까?

만약 Who to follow 섹션에서 장애로 인해 멈췄을 때 Home과 Trends for you 섹션도 함께 멈춰야 하는지 고민해보자면, 저는 명확하게 아니라고 생각합니다. 각 섹션은 서로 의존하지 않기 때문에, 이곳에 error boundary를 배치하는 것은 적절한 선택입니다.

Twitter Deep Dive: Who To Follow

이제 같은 질문을 Who to follow 섹션에도 적용해 봅니다.

Who to follow 섹션을 보면, 명확하게 구분된 세 개의 섹션이 있습니다: 제목, 팔로우할 사용자 목록, 그리고 더 보기 버튼. 이제 사용자 목록을 자세히 들여다보며 동일한 질문을 다시 던져봅니다: 만약 팔로워 목록에 장애가 발생한다면, 제목과 더 보기 버튼도 함께 장애가 발생해야 할까요? 이번 경우는 조금 덜 명확하지만, 제 생각에는 역시 그럴 필요가 없을 것 같습니다. 제목을 유지한다고 해서 문제가 될 건 없고, 더 보기 버튼은 작동 중일 수 있는 다른 페이지로 연결되기 때문입니다. 그래서 팔로워 목록에 또 하나의 error boundary를 추가하는 것이 좋겠습니다!

Twitter Deep Dive: Follower Recommendation

한 번 더 해봅시다. 이번에는 팔로우 추천 섹션을 살펴보겠습니다.

여기에는 두 가지 섹션만 있으니 간단하게 질문할 수 있습니다: 만약 사용자의 이름과 고유 사용자명(@)이 장애를 일으킨다면, 팔로우 버튼도 함께 장애가 발생해야 할까요? 반대의 경우에는요?

저는 그렇다라고 생각됩니다! 사용자의 이름과 고유 사용자명(@)이 사라지면 우리가 누구를 팔로우하려는지 알 수 없게 됩니다. 그리고 팔로우 버튼이 사라지면 사용자는 추천만 받고 아무런 행동을 할 수 없기 때문에 불만족스러운 경험이 될 수 있습니다.

Testing your Fault Tolerance

이제 error boundaries와 Fault Tolerance에 대해 좀 더 알게 되었으니, 제가 이 과정에서 가장 좋아하는 부분을 하나 공유하고 싶습니다: 바로 이 모든 것을 테스트하는 방법입니다. 제가 발견한 애플리케이션의 Fault Tolerance를 테스트하는 가장 쉽고 간단한 방법은 일부러 에러를 일으키는 것입니다.

function CreditCardInput(props) {
  // What happens if I messed up here? Let's find out!
  throw new Error("oops, I made a mistake!");
  return <input className="credit-card" />;
}

이건 제가 새로운 컴포넌트를 추가할 때마다 했던 작업인데, 애플리케이션이 장애를 어떻게 처리하는지 확인하는 데 정말 유용했습니다. 다만, throw 문을 사용해서 일부러 장애를 발생시킨 코드를 커밋하지 않도록 주의하세요 🙂

🤔 참고: 카오스 엔지니어링 (Chaos Engineering)
의도적으로 에러를 발생시켜 fault tolerance를 테스트하는 것은 카오스 엔지니어링 의 매우 가벼운 예시입니다. 리액트 커뮤니티에서도 이 개념을 활용한 도구들이 더 많이 생겼으면 좋겠어요. 만약 React.ChaosMode 같은 것이 있어서, 랜덤으로 일부 컴포넌트들을 고장 내서 fault tolerance를 테스트할 수 있다면 어떨까요?

Summary

모든 내용을 요약하자면, 다음과 같습니다:

• 최상단에 단일 error boundary만 두는 것은 피하세요. 이런 방식이 장애를 처리하는 최선의 방법인 경우는 드뭅니다.

• error boundaries를 과도하게 사용하지 마세요. 이것은 사용자 경험을 저하시키고 성능에 악영향을 미칠 수 있습니다.

• 애플리케이션의 feature boundaries를 식별하고, 그곳에 error boudaries를 배치하세요. 리액트 앱은 트리 구조로 되어 있으니, 상단에서 시작해 하위로 내려가며 error boundary를 추가하는 것이 좋은 접근법입니다.

• "이 컴포넌트가 고장나면 형제 컴포넌트도 고장나야 할까?"라는 질문을 재귀적으로 던져보세요. 이 방법은 feature boundaries를 찾는 데 좋은 기준이 됩니다.

• 에러 상태를 사전에 고려하여 애플리케이션을 설계하세요. feature boundaries에 error boudaries를 배치하면, 사용자에게 문제 발생을 알리고, 사용자 친화적인 fallback UI를 제공하기가 쉬워집니다. 또한, 기능별로 재시도 로직을 구현하면 사용자가 페이지 전체를 새로고침하지 않고도 해당 섹션만 새로고침할 수 있습니다.

• 일부러 에러를 발생시키고, 어떤 일이 일어나는지 확인해 보세요

실시간 알림 기능을 구현하기 위해 서버와의 실시간 통신을 구축한다.

실시간 통신 방법

Polling

클라이언트가 주기적으로 서버에 요청을 보내는 방식.

장점

• 구현이 간편하고 추가적인 서버 설정이 필요 없다.
• 일정하게 갱신되는 서버 데이터의 경우 유용하게 사용할 수 있는 방식이다.

  단점

• 주기적인 요청으로 발생할 수 있는 불필요한 요청과 응답으로 인해 서버에 부하가 생길 수 있다.
• 요청을 보내는 주기 만큼의 지연이 발생하여 실시간 데이터를 기대하기 힘들다.
• 주기가 짧아질수록 서버 및 네트워크 부하가 높아질 수 있다.
• HTTP 통신 시 매번 보내는 요청과 응답 헤더의 크기가 불필요하게 크다.

  사용 예시

  일정 시간 간격으로 데이터를 업데이트하는 경우에 유용하다. ex) 실시간 야구 문자 중계, 뉴스 헤드라인

  Long Polling

  클라이언트가 서버에 요청을 보내면, 서버는 클라이언트의 요청에 바로 응답하지 않고 업데이트가 발생할 때까지 기다린다. 업데이트가 발생하거나 설정된 시간이 지나면 서버는 응답을 보내고 클라이언트는 응답을 받아 연결을 종료한 뒤 곧바로 다시 요청을 보내 다음 응답을 기다린다.

장점

• polling 보다 데이터의 업데이트에 반응하는 속도가 빨라질 수 있고 서버의 부담이 줄어들 수 있다.
• 실시간성이 필요한 적은 수의 클라이언트와 연결되어 있는 경우 사용하는 것이 좋다.

  단점

• 클라이언트의 요청 주기가 짧다면 일반 polling과 별 차이가 없으며, 다수의 클라이언트에게 동시에 이벤트가 발생될 경우 한 번에 응답을 하고 요청을 다시 보내야 하기 때문에 서버에 순간적인 부담이 가해질 수 있다.
• HTTP 통신 시 매번 보내는 요청과 응답 헤더의 크기가 불필요하게 크다.

  사용 예시

  ex) 적은 인원의 채팅 앱, 알림

  WebSocket

  웹소켓 프로토콜을 사용하면 클라이언트와 서버가 지속적인 연결을 통해 서로가 원할 때 데이터를 주고 받을 수 있다. 즉 웹소켓은 데이터의 송수신을 동시에 처리하는 양방향 통신 기법이다.

기존 HTTP 요청 응답 방식은 요청한 그 클라이언트에만 응답이 가능했는데, ws 프로토콜을 통해 웹소켓 포트에 접속해있는 모든 클라이언트에게 이벤트 방식으로 응답할 수 있다.

프레임으로 구성된 메시지라는 논리적 단위로 송수신하며, 메시지에 포함될 수 있는 교환 가능한 메시지는 텍스트와 바이너리이다.

장점

• 최초 접속시 HTTP 프로토콜을 통해 연결하기 때문에 별도의 포트 없이 기존의 포트(HTTP: 80, HTTPS: 443) 를 사용할 수 있어 추가 방화벽을 열지 않아도 양방향 통신이 가능하고 HTTP 규격인 CORS 적용, 인증 등을 기존과 동일하게 보장받을 수 있다.
• 기존 HTTP 통신과 달리 Connection을 지속하므로 요청 및 응답 헤더와 같은 연결 비용을 줄일 수 있다.

  단점

• 연결을 계속 유지하는 만큼 서버의 부하가 생길 수 있고, 많은 사용자들이 동시에 접속해 있을 수록 유지해야 하는 TCP 연결이 많아져 메시지들이 오가는 빈도가 높다면 네트워크 대역폭과 CPU의 사용량 또한 증가할 수 있다.
• 서버의 설계에 따라 구현이 복잡해질 수 있다. 특히 로드밸런싱이 적용된 서버에서는 이를 위해 고려하고 설정할 부분이 많아진다.
• HTTP와는 다른 프로토콜이기 때문에 처음 사용할 때 구현 및 학습 난이도가 높다.
• HTML5 이후에 등장했기 때문에, 이전의 기술로 구현된 서비스에서는 Socket.io와 같은 라이브러리를 사용해야 한다.
• 웹소켓은 문자열들을 주고 받을 수 있게 해줄 뿐 그 이상의 일은 하지 못한다.

  사용 예시

  주식, 채팅 등 연속된 데이터를 빠르게 노출해야 하는 실시간 서비스 분야에 활용된다. ex) 온라인 게임, 실시간 협업 도구에서 여러 사용자의 동시 문서 편집, 화상 채팅 및 회의에서 실시간 데이터 송수신

  SSE(Server Sent Event)

  SSE를 사용하면 서버에서 클라이언트로의 실시간 단방향 통신을 할 수 있다.

한 번의 HTTP 요청을 통해 연결이 이루어지면, 그 이후로 별도의 요청 없이 실시간으로 서버에서 클라이언트로 데이터를 송신할 수 있다.

메시지에 포함될 수 있는 교환 가능한 메시지는 텍스트이다.

장점

• HTML5 표준 기술로서 모든 브라우저가 지원한다.(IE는 사라졌으니 말이다.)
• HTTP 프로토콜 기반으로 동작하기 때문에 학습 및 구현 난이도가 비교적 낮다.
• 자동 재연결 기능이 있다.(기본값은 3000ms)

  단점

• 단방향 통신이다.
• HTTP/1.1의 경우 브라우저당 6개의 접속만을 허가하며 HTTP/2에서는 100개까지의 접속을 허용한다.

  사용 예시

  ex) 주식 거래, 뉴스 피드, 실시간 알림

  SSE 선택 이유

기능에 따라 양방향 통신이 필요하지 않은 경우도 많다. 예를 들어, 서버에서 시간이 걸리는 작업의 진행 상태를 보여주는 진행 바(progress bar), 실시간 소식을 전하는 SNS, 뉴스, 주식 거래 서비스, 또는 기타 실시간 모니터링과 같은 경우가 그렇다.

내가 구현하려는 실시간 알림 기능 역시 양방향 통신이 불필요하다. 클라이언트가 지속적으로 데이터를 보낼 필요 없이, 서버에서 업데이트가 발생할 때만 실시간으로 데이터를 보내주면 충분하기 때문이다.

즉, 단방향 통신으로도 충분한 서비스에는 SSE가 적합하고, 양방향 통신이 필수적인 경우에는 웹소켓을 사용하는 것이 더 적절하다.

SSE 동작 및 사용 방법

동작 순서

• 클라이언트가 서버에 SSE로 통신하자는 요청을 보낸다.
• 서버는 이 요청을 수신하고 수락했음을 알리는 메시지를 보낸다.
• 클라이언트는 이를 받고, 서버가 보내주는 데이터들에 반응할 준비를 한다.
• 이 시점부터 서버는 정해진 이벤트가 있을 때마다 클라이언트에게 메시지를 보낸다. (단방향 통신이기 때문에 클라이언트는 이에 응답을 할 수는 없다.)
• 클라이언트는 서버로부터 메시지가 도착할 때마다 이에 반응하여 필요한 작업을 한다.
• 이 과정들은 하나의 연결 안에서 계속 이루어지고, 만약 연결이 끊기면 클라이언트는 자동으로 재연결을 요청하여 통신을 재개한다.
• 필요 작업을 마치면 클라이언트 또는 서버에서 상대방에게 종료를 통보하는 메시지를 보냄으로써 연결이 끝나게 된다.

  사용 방법

• 클라이언트가 브라우저일 경우, SSE 연결 요청을 위해 Web API의 EventSource 인터페이스를 사용한다.
• 클라이언트는 지정된 URL로 서버에게 요청을 보낸다.
  • SSE 통신을 통해 이벤트 스트림 타입의 메시지를 수신하겠다는 의미의 헤더가 실린다.
  • Accept: text/event-stream
• 이를 수신한 서버는 이벤트 스트림 타입의 메시지임을 명시하는 헤더를 실은 응답을 보낸다.
  • Content-Type: text/event-stream
  • 연결을 계속 유지한다는 항목도 실린다. 이 헤더 덕분에 클라이언트가 요청을 보내면서 만들어진 연결이 서버가 응답을 보낸 이후로도 계속 유지되는 것이다.
  • Connection: keep-alive
  • 서버의 첫 번째 응답 이후로는 메시지에 HTTP 헤더가 실릴 필요가 없게 된다.
• 서버는 지정된 이벤트가 발생할 때마다 실시간으로 클라이언트에게 메시지를 보내고 클라이언트에서는 각 메시지를 받아 특정 작업을 실행한다.
• 서버에서는 이벤스 소스에 이벤트 이름을 기입하여 토픽 기반으로 여러 이벤트를 발행할 수 있고, 클라이언트에서는 이벤트 리스너 설정을 통해 해당 토픽 이벤트를 구독할 수 있다.
• EventSource는 retry를 사용하여 자동으로 재접속할 수 있다.
  • 클라이언트가 따로 구현하지 않아도 연결이 비정상적으로 끊길 때마다 자동으로 연결 요청을 보낸다.
  • 연결이 끊어질 시 재접속을 몇 ms 후에 시도할 지 지정할 수 있고, 기본값은 3000ms이다.
  • 메시지에 id를 지정할 수도 있는데, 연결이 끊어졌다가 재개될 경우 클라이언트가 마지막에 받은 id를 Last-Event-ID 헤더에 담아 요청에 실어보냄으로써 서버는 그 다음에 해당하는 메시지부터 보낼 수 있다.
• 클라이언트에서 연결 종료할 때는 EventSource 객체의 close 메서드를 호출한다.
• 서버에서 연결 종료할 때는 전송을 중단하거나 합의된 메시지를 보내서 연결을 통지한다.
  • 서버에서 이벤트 소스의 이름을 end로 하고, 클라이언트에서는 end의 이벤트를 실행할 때 close 메서드를 호출하는 방법이 있다.

    클라이언트 예시 코드

import React, { useEffect, useState } from 'react';

function Notifications() {
    const [messages, setMessages] = useState([]);

    useEffect(() => {
        // 서버의 SSE 엔드포인트를 설정.
        const eventSource = new EventSource('http://서버주소/sse-endpoint');

        // onmessage는 이벤트 이름을 따로 명시하지 않은 모든 데이터를 처리한다.
        eventSource.onmessage = function(event) {
            const newMessage = JSON.parse(event.data);  // 이벤트 데이터는 JSON 형식일 수 있습니다.
            setMessages(prevMessages => [...prevMessages, newMessage]);
        };

        // 연결 성공시 실행
        eventSource.onopen = function() {}

        // 연결이 끊기거나 에러 발생시 실행
        eventSource.onerror = function() {}

        // 이벤트 이름을 명시한 메시지를 받을 때 사용
          // 아래 예시는 이벤트 이름이 customEvent인 메시지를 처리하는 경우
        eventSource.addEventListenr('customEvent', function(e) {})

        // 컴포넌트 언마운트 시 EventSource 연결 종료.
        return () => {
            eventSource.close();
        };
    }, []);

    return (
        <div>
            <h2>알림</h2>
            <ul>
                {messages.map((msg, index) => (
                    <li key={index}>{msg}</li>
                ))}
            </ul>
        </div>
    );
}

export default Notifications;

테스트 코드 및 기능 구현

설계 과정

[FE] 기능 테스트와 TDD 및 테스트 코드 작성 가이드라인 참고

1. 실사간 알림 기능이 제공하는 서비스에 대한 use case coverage 작성.
2. MSW 사용하여 API mocking.
3. 테스트 환경 설정 및 코드 작성.
4. 기능 구현.

   use case coverage 작성

• 실시간 알림이 도착하면 전체 화면에 알림 팝업이 발생하고, 그 안에 제목, 메시지, 버튼이 존재한다.
• 팝업이 발생하고 바깥 배경을 클릭하면 팝업이 사라진다.
• 팝업 버튼이 확인 버튼인 경우 버튼 클릭시 팝업이 사라진다.
• 팝업 버튼이 아닌 확인 버튼이 아닌 경우, 버튼 클릭시 특정 화면으로 이동한다.
• 알림 확인 도중 또 다른 실시간 알림 발생시 팝업을 닫자마자 새로운 팝업이 발생한다.

API mocking.

실시간 알림 테스트를 위해 서버로부터 특정 시간 후에 메시지를 수신하는 상황을 구현하고자 한다.

그러나 실제 API 요청을 통한 테스트는 API 개발이 완료된 후에만 가능하므로, 백엔드 개발과 병렬적으로 진행하기 어렵다는 문제가 있다. 또한 테스트 과정에서 불필요한 요청으로 인한 비용 발생과 API 의존성 문제도 고려해야 한다.

그래서 실제 API 요청을 통한 테스트가 아니라 네트워크 수준에서 mocking한 API를 이용하여 테스트하고자 한다. 이를 위해 MSW 라이브러리를 사용한다.

어떤 API를 mocking해야 하는가?

EventSource API는 클라이언트가 서버로부터 지속적인 데이터를 받는 것을 처리한다. 서버가 클라이언트에 이벤트를 계속해서 푸시하는 방식인데, 이 방식을 테스트 환경에서 mocking해야 한다.

실제 서버는 지속적으로 데이터를 전송해 주지만, mocking 상황에서는 실제 서버가 없기 때문에 서버가 데이터를 스트리밍하는 것을 흉내내야 한다.

MSW 공식문서에서 data streaming을 mocking하는 recipe를 제공하고 있는데, 그 방법으로 ReadableStream을 말한다.

ReadableStream을 사용하여 API mocking

Streams API의 ReadableStream 인터페이스는 바이트 데이터를 읽을 수 있는 Stream을 제공한다.

즉 EventSource API가 클라이언트에서 서버의 데이터를 실시간으로 받는 역할이라면, 서버에서 데이터를 생성하고 전달하는 역할은 ReadableStream API가 한다.

1. 백엔드 개발자와 EventSource 메시지 이벤트 이름과 메시지 타입을 합의하여 mock data 생성.
2. ReadableStream 생성자를 통해 응답값으로 Stream을 생성.
3. TextEncoder의 encode 메서드를 이용하여 문자열 데이터를 UTF-8 형식의 바이트 데이터로 변환.
4. controller의 enqueue 메서드를 이용하여 바이트 데이터를 Stream에 저장.
5. Stream을 Content-Type: text/event-stream 헤더와 함께 클라이언트에 응답.

실제 서버처럼 시간차를 두고 데이터를 순차적으로 전송할 수 있는 흐름을 제어하기 위해 setTimeout을 이용하여 1초, 4초, 7초 마다 메시지가 도착하도록 만들었다.

import { HttpHandler, HttpResponse, http } from 'msw';

import { API_END_POINT } from '@/constants/api';

const realTimeNotificationData = [
  'id:1_1722845403085\nevent:notification\ndata:{ "notificationId": 1, "message": "경매에 올린 test가 낙찰되었습니다.", "type": "AUCTION_SUCCESS", "auctionId": 59}\n\n',
  'id:1_1722845403090\nevent:notification\ndata:{ "notificationId": 2, "message": "경매에 올린 test가 미낙찰되었습니다.", "type": "AUCTION_FAILURE"}\n\n',
  'id:1_1722845403175\nevent:notification\ndata:{ "notificationId": 3, "message": "축하합니다! 입찰에 참여한 경매 test의 낙찰자로 선정되었습니다.", "type": "AUCTION_WINNER", "auctionId": 62}\n\n',
];

const encoder = new TextEncoder();

export const realTimeNotificationsHandler: HttpHandler = http.get(
  `${API_END_POINT.REALTIME_NOTIFICATIONS}`,
  () => { 
    const stream = new ReadableStream({
      start(controller) {
        realTimeNotificationData.forEach((message, idx) => {
          setTimeout(() => {
            controller.enqueue(encoder.encode(message));
          }, [1000, 4000, 7000][idx]);
        });
      },
    });

    return new HttpResponse(stream, {
      headers: {
        'Content-Type': 'text/event-stream',
      },
    });
  },
);

테스트 환경 설정 및 코드 작성

테스트 환경 설정

rendering component

어느 화면에서나 실시간 알림이 발생해야 하기 때문에 모든 페이지가 공유하는 GlobalLayout 컴포넌트를 작성하고 해당 컴포넌트에서 SSE 작업을 수행한다.

setup 함수 정의

render 메서드와 userEvent는 거의 매번 사용하기 때문에 setup 함수를 만들어 사용한다.

const setup = () => {
    const utils = render(<GlobalLayout />);
    const user = userEvent.setup();

    return {
      user,
      ...utils,
    };
};

EventSource API mocking

EventSource는 브라우저의 내장 객체로, 브라우저가 아닌 Node.js 테스트 환경에는 존재하지 않는다. 그래서 테스트를 실행해보면 EventSource is not defined 에러가 발생한다.

Node.js에서는 브라우저의 window 객체 대신 global 객체가 사용되는데, 테스트 환경에서 EventSource와 같은 브라우저 전용 객체를 사용하기 위해서는 EventSource를 mocking하여 global 객체에 직접 추가해줘야 한다.

아래 설정을 통해, 테스트 환경에서 EventSource를 사용하는 코드가 실제 브라우저의 EventSource 대신 우리가 정의한 EventSource를 사용하게 된다.

또한 addEventListener를 조작하여 내가 원하는 이벤트에서 원하는 데이터가 원하는 시간 후에 메시지를 수신하도록 만들었다.

나는 EventSource 객체를 GlobalLayout 컴포넌트 테스트 파일에서만 사용하기 때문에 해당 테스트 파일에서 정의하여 사용 범위를 제한했다.

const realTimeNotificationData = [
  'id:1_1722845403085\nevent:notification\ndata:{ "notificationId": 1, "message": "경매에 올린 test가 낙찰되었습니다.", "type": "AUCTION_SUCCESS", "auctionId": 59}\n\n',
  'id:1_1722845403090\nevent:notification\ndata:{ "notificationId": 2, "message": "경매에 올린 test가 미낙찰되었습니다.", "type": "AUCTION_FAILURE"}\n\n',
  'id:1_1722845403175\nevent:notification\ndata:{ "notificationId": 3, "message": "축하합니다! 입찰에 참여한 경매 test의 낙찰자로 선정되었습니다.", "type": "AUCTION_WINNER", "auctionId": 62}\n\n',
];

describe('Layout 알림 테스트', () => {
  // 테스트 시작 전에 EventSource 모킹
  beforeAll(() => {
    global.EventSource = vi.fn(() => ({
      addEventListener: vi.fn((event, callback) => {
        if (event === 'notification') {
          realTimeNotificationData.forEach((messageString, idx) => {
            // data 값 추출하고 callback이 처리.
            const dataMatch = messageString.match(/data:(.*)\n/);
            if (dataMatch && dataMatch[1]) {
              const message = JSON.parse(dataMatch[1].trim()); // 문자열을 객체로 변환
              setTimeout(() => {
                callback({ data: JSON.stringify(message) }); // JSON 문자열로 다시 전송
              }, [1000, 4000, 7000][idx]);
            }
          });
        }
      }),
      close: vi.fn(),
    })) as unknown as typeof EventSource; // 타입스크립트가 global.EventSource의 타입이 브라우저의 EventSource 타입과 같다고 간주한다.
  });
}

테스트 코드 작성

실시간 알림이 도착하면 전체 화면에 알림 팝업이 발생하고, 그 안에 제목, 메시지, 버튼이 존재한다.

test('실시간 알림이 도착하면 전체 화면에 알림 팝업이 발생하고, 그 안에 제목, 메시지, 버튼이 존재한다.', async () => {
    render(<GlobalLayout />);

    // 1초 후에 발생하는 popup을 찾기 timeout을 1100ms로 설정한다.
    const popup = await screen.findByLabelText(
      /알림 박스/,
      {},
      { timeout: 1100 },
    );

    const title = screen.getByRole('heading', { name: /제목/ });
    const message = screen.getByLabelText(/메시지/);
    const button = screen.getByRole('button', {
      name: /경매 참여자 목록 보러가기/,
    });

    expect(popup).toContainElement(title);
    expect(popup).toContainElement(message);
    expect(popup).toContainElement(button);
  });

팝업이 발생하고 바깥 배경을 클릭하면 팝업이 사라진다.

test('팝업이 발생하고 바깥 배경을 클릭하면 팝업이 사라진다.', async () => {
    const { user } = setup();

    const popup = await screen.findByLabelText(
      /알림 박스/,
      {},
      { timeout: 1100 },
    );

    const popupBackground = screen.getByLabelText('팝업 배경');
    await user.click(popupBackground);

    expect(popup).not.toBeInTheDocument();
  });

팝업 버튼이 확인 버튼인 경우 버튼 클릭시 팝업이 사라진다.

mock 데이터에서 두 번째 알림의 경우 버튼의 종류가 확인 버튼이다. 확인 버튼을 테스트하기 위해 두 번째 알림을 기다리려면 최소 4초를 기다리는 과정이 필요하다.

처음에 나는 findByLabelText의 timeout의 기능을 바로 알지 못해 5000ms로 설정을 해놓고 두 번째 알림을 기다렸다. 하지만 내가 원하는 두 번째 알림이 아닌 첫 번째 알림을 찾았다.

그 이유는 findByLabelText의 timeout의 기능은 설정한 시간 내에 가장 먼저 찾은 요소를 선택하기 때문이다.

그래서 4초 후에 오는 두 번째 알림을 받으려면 우선 1초 후에 오는 메시지를 찾고, setTimeout으로 3초 간 기다린다음 작업을 해야 한다.

여기서 일반적인 setTimeout을 이용하면 안된다. setTimeout은 비동기작업이기 때문에 리액트의 상태 변화나 DOM 작업을 기다리지 않기 때문이다.

이를 해결하기 위해 act와 Promise를 결합하여 setTimeout을 사용한다. RTL의 act 함수는 리액트 내의 상태나 DOM이 업데이트되는 동안 발생하는 사이드 이펙트를 묶어서 처리한다. act는 비동기 함수도 지원하는데, 비동기 함수 내의 비동기 작업이 완료될 때까지 기다린다.

기본 테스트 시간을 넘어가는 경우, test의 timeout 시간을 넉넉히 잡아 테스트를 실행한다.

 test(
      '팝업 버튼이 확인 버튼인 경우 버튼 클릭시 팝업이 사라진다.',
      { timeout: 8000 },
      async () => {
        const { user } = setup();

        // 첫 번째 알림을 찾고, 알림을 닫는다.
        const popup = await screen.findByLabelText(
          /알림 박스/,
          {},
          { timeout: 1100 },
        );
        const popupBackground = screen.getByLabelText('팝업 배경');
        await user.click(popupBackground);

        await act(async () => {
          await new Promise((resolve) => {
            setTimeout(resolve, 3000);
          });
        });

        // 두 번째 알림을 찾아 동작을 수행.
        const button = screen.getByRole('button', {
          name: /확인/,
        });
        await user.click(button);

        expect(popup).not.toBeInTheDocument();
      },
    );

팝업 버튼이 아닌 확인 버튼이 아닌 경우, 버튼 클릭시 특정 화면으로 이동한다.

render component에서 useNavigate hook을 사용하는 경우 useNavigate mocking이 필수이다.

나는 다른 테스트에서도 useNavigate hook을 사용했기 때문에 setupTests.ts 파일에서 mocking하고 export하여 모든 테스트 파일에서 사용했다.

// setupTests.ts
export const mockedUseNavigate = vi.fn();
vi.mock('react-router-dom', async () => {
  // importActual은 실제 모듈의 원래 구현을 가져오는 기능을 한다.
  // 일부 기능은 실제 동작을 그대로 유지하면서 useNavigate만 모킹하려는 경우에 유용하다.
  const mod =
    await vi.importActual<typeof import('react-router-dom')>(
      'react-router-dom',
    );
  return {
    ...mod,
    // useNavigate 훅이 호출될 때마다 mockedUseNavigate 라는 모의 함수가 호출된다.
    useNavigate: () => mockedUseNavigate,
  };
});

mocking한 useNavigate를 import하고 mockedUseNavigate가 실행되었음을 확인한다.

import { mockedUseNavigate } from '@/setupTests';

test('확인 버튼이 아닌 알림인 경우, 버튼 클릭시 특정 화면으로 이동한다.', async () => {
      const { user } = setup();

      await screen.findByLabelText(/알림 박스/, {}, { timeout: 1100 });

      const button = screen.getByRole('button', {
        name: /경매 참여자 목록 보러가기/,
      });
      await user.click(button);

      expect(mockedUseNavigate).toHaveBeenCalledOnce();
});

알림 확인 도중 또 다른 실시간 알림 발생시 팝업을 닫자마자 새로운 팝업이 발생한다.

test(
    '알림 확인 도중 또 다른 실시간 알림 발생시 팝업을 닫자마자 새로운 팝업이 발생한다.',
    { timeout: 8000 },
    async () => {
      const { user } = setup();

      await screen.findByLabelText(/알림 박스/, {}, { timeout: 1100 });

      await act(async () => {
        await new Promise((resolve) => {
          setTimeout(resolve, 3000);
        });
      });

      const button = screen.getByRole('button', {
        name: /경매 참여자 목록 보러가기/,
      });
      await user.click(button);

      const box = await screen.findByLabelText(
        /알림 박스/,
        {},
        { timeout: 1100 },
      );
      expect(box).toBeInTheDocument();
    },
  );

기능 구현

SSE 연결 및 custom hook 작성

useEffect 내에서 SSE 연결을 하고 notification event로 메시지를 수신하여 notifications 배열 상태에 저장한다.

위에서 mocking한 API handler와 동일한 URL로 요청을 하면 MSW가 이를 감지하여 내가 설정한 데이터를 전송해준다.

간단한 작업이기 때문에 useSSE hook을 만들어주었다.

import { useEffect, useState } from 'react';

export const useSSE = <T>(url: string) => {
  const [state, setState] = useState<T[]>([]);

  useEffect(() => {
    const eventSource = new EventSource(url);

    eventSource.onopen = () => {

    };
    eventSource.onerror = (error) => {

    };

    eventSource.addEventListener('notification', (e) => {
      const data = JSON.parse(e.data);
      setState((prev) => [...prev, data]);
    });

    return () => eventSource.close();
  }, [url]);

  return { state, setState };
};

알림이 발생시 팝업 발생

목표

• 알림이 발생하면 팝업이 발생하고, 바깥이나 버튼을 클릭하면 팝업을 닫는다.
• 팝업 읽는 도중 새로운 알림이 발생하면, 팝업을 닫자마자 새로운 팝업이 생성된다.

  구현

1. currentNotification 변수 생성
2. useSSE가 리턴한 notifications 배열과 currentNotification을 dependency로 가지는 useEffect 생성
3. currentNotification이 null이면서 notificaions 값이 있을 때 currentNotification 값을 notifications의 첫번째 값으로 설정하고 notifications의 첫번째 값을 제거.

// GlobalLayout
import { useEffect, useState } from 'react';

import { API_END_POINT } from '@/constants/api';
import { Outlet } from 'react-router-dom';
import Popup from '../common/Popup';
import RealTimeNotification from './RealTimeNotification';
import type { RealTimeNotificationType } from 'Notification';
import { useSSE } from '@/hooks/useSSE';

const GlobalLayout = () => {
  const { state: notifications, setState: setNotifications } =
    useSSE<RealTimeNotificationType>(`${API_END_POINT.REALTIME_NOTIFICATIONS}`);

  const [currentNotification, setCurrentNotification] =
    useState<RealTimeNotificationType | null>(null);

  const closePopup = () => {
    setCurrentNotification(null);
  };

  useEffect(() => {
    const showNextNotification = () => {
      setCurrentNotification(notifications[0]);
      setNotifications((prev) => prev.slice(1));
    };
    if (currentNotification === null && notifications.length > 0) {
      showNextNotification();
    }
  }, [currentNotification, notifications, setNotifications]);

  return (
    <div className="flex justify-center w-full h-screen">
      <div className="relative w-[46rem] min-w-[23rem] h-full">
        <Outlet />
        {currentNotification && (
          <Popup onClose={closePopup}>
            <RealTimeNotification
              onClose={closePopup}
              notification={currentNotification}
            />
          </Popup>
        )}
      </div>
    </div>
  );
};

export default GlobalLayout;

알림 팝업

테스트 코드를 보면 getByRole, getByLabelText 등의 접근성 handler로 요소를 찾는 것을 알 수 있다.

RTL(React Testing Library)은 어플리케이션의 접근성을 높이고 사용자가 원하는 방식으로 구성요소를 사용하는 방식에 가까운 테스트를 수행할 수 있도록 하여 테스트를 통해 실제 사용자가 어플리케이션을 사용할 때 어플리케이션이 작동할 것이라는 확신을 주는 것을 목표로 하기 때문이다.

이를 위해 팝업 코드 작성시 적절한 role을 사용하고 aria-label을 작성하는 등 접근성 향상에 공을 들여야 한다.

• 특정 role이 없는 경우 aria-label을 명시하여 해당 tag가 무슨 역할을 하는 지 명확히 한다.
• 제목은 heading tag를 사용한다.
• 이미지를 사용하는 경우 img 태그를 사용하고 alt 속성을 반드시 명시한다.
• 버튼을 사용하는 경우 button 태그를 사용한다.

// 코드를 간소화하여 role과 접근성만 강조했다.
const Popup = () => {
  return createPortal(
    <div>
      <div aria-label="팝업 배경">
        <div aria-label="알림 박스" >
          <div>
            <h2 aria-label="알림 제목" >
              {title}
            </h2>
            <div aria-label="알림 메시지" >
              {message}
            </div>
          </div>
          <Button
            ariaLabel={buttonName}
            type="button"
            hoverColor="black"
            className="w-full py-3"
            color="cheeseYellow"
          >
            {buttonName}
          </Button>
        </div>      
      </div>
    </div>,
    document.body,
  );
};

출처 및 참고 자료

MDN EventSource MDN ReadbleStream MDN Streams API MSW Streaming Using server-sent events 테코톡 주드 SSE [실전 프로젝트] React와 SSE SSE 얄코 React SSE 실시간 알림 구현하기 (폴리필 문제해결) 리액트 실시간 알림 SSE 헤더에 토큰 담아 보내기 서버사이드이벤트(SSE) 실시간 서버 데이터 구독하기 javascriptInfo SSE polling / long polling / SSE / websocket 정리 SSE(Server Sent Event)로 실시간 알림 받아오기 SSE 실시간 알림 기능 구현 알림 기능을 구현해보자 - SSE(Server-Sent-Events)! 웹소켓을 알아봅시다 테코톡 코일 웹소켓

Fetch-on-render

컴포넌트가 화면에 렌더링 된 후에, useEffect 혹은 ComponentDidMount 등의 라이프사이클 메서드를 활용해서 비동기 작업을 처리한다.

function ProfilePage() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser().then(u => setUser(u));
  }, []);

  if (user === null) {
    return <p>Loading profile...</p>;
  }
  return (
    <>
      <h1>{user.name}</h1>
      <ProfileTimeline />
    </>
  );
}

function ProfileTimeline() {
  const [posts, setPosts] = useState(null);

  useEffect(() => {
    fetchPosts().then(p => setPosts(p));
  }, []);

  if (posts === null) {
    return <h2>Loading posts...</h2>;
  }
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.text}</li>
      ))}
    </ul>
  );
}

실행 순서

• ProfilePage 렌더링.
• fetchUser 비동기 작업 시작.
• fetchUser 비동기 작업 끝.
• ProfileTimeline 렌더링.
• fetchPost 비동기 작업 시작.
• fetchPost 비동기 작업 끝.

문제점

warterfall 문제

위 방법은 매우 직관적인 방법이지만 Warterfall 문제를 야기한다. Warterfall은 이전 fetch 요청에 대한 응답이 와야 다음 fetch 요청을 보낼 수 있는 구조를 말한다. 각 작업이 3초가 걸린다면, 총 6초가 지나야 모든 비동기 작업이 완료된 화면을 볼 수 있다.

상태 분기 처리 문제

현재 비동기 작업이 하나기 때문에 하나의 로딩 상태만을 다루지만, 비동기 작업이 2개 이상으로 늘어나고, 에러 상태도 처리하게 되는 순간 하나의 컴포넌트에서 너무 많은 일을 하게 되어 비즈니스 로직을 파악하기 힘들다.

Fetch-then-render

비동기 작업을 한 번에 처리하고, 모두 완료한 후 화면을 렌더링한다. 여러 비동기 작업을 한 번에 처리함으로써 Warterfall 문제를 방지할 수 있다.

// Kick off fetching as early as possible
const promise = fetchProfileData();

function ProfilePage() {
  const [user, setUser] = useState(null);
  const [posts, setPosts] = useState(null);

  useEffect(() => {
    promise.then(data => {
      setUser(data.user);
      setPosts(data.posts);
    });
  }, []);

  if (user === null) {
    return <p>Loading profile...</p>;
  }
  return (
    <>
      <h1>{user.name}</h1>
      <ProfileTimeline posts={posts} />
    </>
  );
}

// The child doesn't trigger fetching anymore
function ProfileTimeline({ posts }) {
  if (posts === null) {
    return <h2>Loading posts...</h2>;
  }
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.text}</li>
      ))}
    </ul>
  );
}

실행 순서

• ProfilePage 렌더링.
• user data fetching 시작.
• posts data fetching 시작.
• user data fetching 끝.
• posts data fetching 끝.
• ProfilePage 리렌더링.

문제점

최종 렌더링 지연

Warterfall 문제는 해결했지만, 모든 비동기 작업이 완료될 때까지 ProfilePage는 렌더링하지 못한다.

컴포넌트 비대화

ProfilePage와 ProfileTimeline 컴포넌트에서 처리할 데이터와 로딩 상태를 모두 하나의 컴포넌트에서 처리하기 때문에 ProfilePage 컴포넌트가 비대화되는 문제가 발생한다.

코드의 가독성과 유지보수성이 떨어지며 비즈니스 로직을 파악하기 힘들어지는 문제가 발생한다.

비동기 작업의 선언적 처리

리액트의 선언적 프로그래밍

리액트의 특징 중 하나는 선언적 프로그래밍을 할 수 있다는 점이다. 선언적 프로그래밍이 가능하다는 것은 추상화 레벨이 높은 프로그래밍이 가능하다는 의미이기도 하다.

추상화에는 설계자와 사용자가 존재한다. 구체적인 기능 구현은 설계자의 책임이고, 기능 사용자는 구체적인 기능 구현을 알 필요 없이 원하는 기능을 사용하기만 하면 된다.

즉 리액트 사용자는 어떤 UI를 렌더링할 것인지에만 집중하고 이를 어떻게 렌더링할 것인지에 대한 책임은 설계자 역할인 리액트에게 넘긴다.

리액트 공식문서의 Design Principles에 다음과 같은 문구가 있다.

개발자는 함수로 컴포넌트를 작성할 때, 무엇을 렌더링할 것인지에 대한 설명에만 집중하고 해당 컴포넌트를 렌더하고 DOM에 적용하는 것은 리액트의 책임이므로 함수 호출에는 관여하지 않는다.

이러한 추상화로 인해 리액트 사용자인 개발자는 어떤 화면을 렌더링할 것인지를 고민하는 데에 더 많은 시간을 사용할 수 있으며, 이 화면을 어떻게 렌더링해야 할 지에 대한 고민은 리액트에게 온전히 맡길 수 있다.

그리고 우리는 Suspense와 ErrorBoundary를 사용하여 비동기 작업 또한 선언적으로 처리할 수 있다. 데이터가 로딩되었는지를 판단하는 책임은 Suspense에 맡기고, 에러에 대한 책임을 ErrorBoundary에 맡김으로써, 컴포넌트는 정상적으로 데이터가 로딩되었을 때의 UI 선언에만 집중할 수 있다.

Render-as-you-fetch(with Suspense)

Render-as-you-fetch 방법은 비동기 작업과 렌더링을 동시에 시작한다. Suspense는 모든 비동기 작업이 완료되기 전까지 fallback UI를 렌더링하고, 비동기 작업의 완료를 알아채면 중단 시점부터 컴포넌트를 렌더링한다.

즉 비동기 작업의 상태가 로딩상태인지 판단할 필요없이 Suspense에 fallback UI를 전달하여 로딩 상태에 따른 렌더링을 선언적으로 처리할 수 있다.

// 리액트 공식문서에서는 비동기 작업을 아래와 같이 promise로 wrapping 하여 상위 Suspense 컴포넌트와 소통한다.
// 컨셉 코드이기 때문에 상위 Suspense와 소통하는 개념에 집중하자.
function fetchUser() {
  console.log("fetch user...");
  return new Promise((resolve) => {
    setTimeout(() => {
      console.log("fetched user");
    }, 1000);
  });
}

function fetchPosts() {
  console.log("fetch posts...");
  return new Promise((resolve) => {
    setTimeout(() => {
      console.log("fetched posts");
    }, 1100);
  });
}

export function fetchProfileData() {
  let userPromise = fetchUser();
  let postsPromise = fetchPosts();
  return {
    user: wrapPromise(userPromise),
    posts: wrapPromise(postsPromise)
  };
}

// Suspense를 사용하기 위해서는 promise 객체로 인자를 받아 상태에 따라 리턴값을 달리해주는 함수이다.
// 구현체가 복잡하지만 tanstack query와 같은 비동기 통신 라이브러리에서 Suspense 기능을 쉽게 사용할 수 있도록 도와준다.
function wrapPromise(promise) {
  let status = "pending";
  let result;
  let suspender = promise.then(
    (r) => {
      status = "success";
      result = r;
    },
    (e) => {
      status = "error";
      result = e;
    }
  );
  return {
    read() {
      if (status === "pending") {
        throw suspender;
      } else if (status === "error") {
        throw result;
      } else if (status === "success") {
        return result;
      }
    }
  };
}


const resource = fetchProfileData();

function ProfilePage() {
  return (
    <Suspense fallback={<h1>Loading profile...</h1>}>
      <ProfileDetails />
      <Suspense fallback={<h1>Loading posts...</h1>}>
        <ProfileTimeline />
      </Suspense>
    </Suspense>
  );
}

function ProfileDetails() {
  // Try to read user info, although it might not have loaded yet
  const user = resource.user.read();
  return <h1>{user.name}</h1>;
}

function ProfileTimeline() {
  // Try to read posts, although they might not have loaded yet
  const posts = resource.posts.read();
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.text}</li>
      ))}
    </ul>
  );
}

실행 순서

• 비동기 작업과 렌더링 동시에 시작.
• 비동기 작업 완료.
• 리렌더링.

비동기 작업과 렌더링을 동시에 시작할 수 있는 이유

모든 비동기 작업이 완료되지 않아 Suspense가 fallback UI를 보여줄 때, 리액트는 hidden 모드로 자식 컴포넌트를 렌더하게 되며 이로 인해 부모 컴포넌트가 아직 로딩중이더라도 자식 컴포넌트는 자신의 비동기 작업을 Concurrent하게 수행할 수 있다.

때문에 부모 컴포넌트와 자식 컴포넌트의 비동기 작업과 렌더링을 동시에 할 수 있다.

Suspense 동작 원리

Suspense를 사용하면 비동기 작업의 로딩 상태를 판단할 필요 없이 로딩 상태에 따른 렌더링을 Suspense가 책임진다고 앞서 말했다.

그렇다면 Suspense는 어떻게 자식 컴포넌트의 비동기 작업에 대한 상태를 확인하는 것일까. Suspense가 동작하는 방식은 다음과 같다.

1. render method에서 캐시로부터 값을 읽기를 시도한다.
2. value가 캐시되어 있으면 정상적으로 render 한다.
3. value가 캐시되어 있지 않으면 캐시는 promise를 throw 한다.
4. 해당 promise는 가까운 상위 Suspense 컴포넌트로 전파되고, Suspense는 이 promise를 받아 fallback UI를 렌더링한다.
5. promise가 resolve되면 리액트는 promise를 throw 한 곳으로부터 재시작한다.

앞서 본 ProfilePage 예제에 적용하면 다음과 같다.

1. Suspense가 ProfilePage를 render 할 때 캐시로부터 데이터를 읽으려고 시도한다.
2. 데이터가 없으므로 ProfilePage의 캐시는 promise를 throw 한다.
3. Suspense는 이 promise를 받아 fallback UI를 render 하고, 정상적으로 resolve 되었다면 다시 ProfilePage를 render 한다.

즉 비동기 작업 중일 때 컴포넌트는 가장 가까운 상위 Suspense에 promise를 throw 한고, 비동기 작업이 완료되면(Promise가 resolve되면) Suspense는 fallback UI를 render 하는 것을 멈추고 다시 정상적으로 컴포넌트를 rener 한다.

Suspense의 핵심은 자식 컴포넌트의 비동기 작업에서 throw한 promise를 catch한다는 것이다.

개념적 구현

Prev React Core Team Sebastian Markbåge Example

_// Infrastructure.js_  
let cache = new Map();  
let pending = new Map();

// 실제 url로부터 데이터를 fetch하는 함수.
// fetch 요청의 완료 여부에 따라 리턴하는 값이 다르다.
// 로딩 중이면 resolve되지 않은 promise를 리턴하고, resolve되면 set한 캐시의 value를 리턴한다.

// 동일한 함수를 동일한 url을 가지고 여러 번 호출했을 때 promise의 resolve 여부에 따라서 리턴하는 값이 다르다.
// 즉 promise를 throw 했을 때 Suspense에서 이를 잡아서 resolve될 때까지 fallbackUI를 보여주다가 resolve가 되면 다시 throw한 곳으로부터 정상적인 컴포넌트 로딩을 처리할 수 있게 된다.
function fetchTextSync(url) {  
  if (cache.has(url)) {  
    return cache.get(url);  
  }  
  if (pending.has(url)) {  
    throw pending.get(url);  
  }  
  let promise = fetch(url).then(  
    response => response.text()  
  ).then(  
    text => {  
      pending.delete(url);  
      cache.set(url, text);  
    }  
  );  
  pending.set(url, promise);  
  throw promise;  
}

async function runPureTask(task) {  
  for (;;) {  
    try {  
      return task();  
    } catch (x) {  
      if (x instanceof Promise) {  
        await x;  
      } else {  
        throw x;  
      }  
    }  
  }  
}

Suspense와 대수적 효과(Algebraic Effects)

Suspense가 사용하는 개념적인 모델은 데이터의 상태를 확인하면서 pending 상태인 경우에는 원하는 비동기 작업에 대한 promise를 throw해서 suspense가 fallback UI를 render 하도록 하고, success 상태인 경우에는 컴포넌트를 render 하도록 하는 방식이다.

이 모델 자체는 대수적 효과는 아니지만, 대수적 효과의 영향을 받은 기술이라고 한다. 대수적 효과가 무엇일까.

Matija Pretnar의 “An Introduction to Algebraic Effects and Handlers Invited tutorial paper”에 의하면 대수적 효과란 exception throw 등을 포함하는 연산들의 집합으로부터 순수하지 못한 행위들이 발생할 수 있다는 전제를 바탕으로 computational effect에 대해 접근하는 방식을 의미한다.

위의 정의는 상당히 추상화되어 있어 쉽게 풀어보면 다음과 같다. 대수적 효과란 대수를 사용해서 연산을 수행할 때, 순수하지 못한 행위들이 일어날 수 있음을 전제로 하고 computational effect에 대해 접근하는 방식을 말한다.

여기서 computational effect는 자신의 환경을 변경하는 모든 연산을 포함하는 개념이다. 예를 들어 로컬 함수에서 부모 환경으로 작업을 넘겨 처리하게 하고 처리가 끝나면 로컬 함수의 실행이 멈췄던 곳으로 다시 돌아와 작업을 하는 경우, 이는 computational effect가 발생한 것이다.

작업을 넘긴다는 것은 로컬 함수에서 부모 컴포넌트로 promise를 throw하는 것으로 대치할 수 있으며, 이것이 바로 suspense가 promise의 pending 상태를 처리하는 방식과 동일하다.

다시 정리하면 대수적 효과는 서로 다른 환경(로컬 함수와 부모 환경)간의 상호작용에서 부수 효과가 발생할 수 있는데, 이를 적절한 handler를 통해 처리하는 접근 방식을 의미한다.

여기서 말하는 적절한 handler는 로컬함수에서 발생시킨 effect를 부모 환경에서 잡아 적절하게 처리한 뒤 다시 로컬 함수가 멈췄던 곳으로 실행 흐름을 되돌리는 역할을 한다. 이러한 handler가 바로 우리가 앞서 살펴본 Suspense 이다.

대수적 효과를 Suspense와 연관시켜 적용하면 다음과 같다.

대수적 효과는 부모 컴포넌트(Suspense)와 자식 컴포넌트(비동기 작업 처리 컴포넌트) 간의 상호작용에서 발생한 side effect(throw promise)를 적절한 handler(catch promise in suspense)를 사용해 해결하는 접근 방식을 의미하는 것이고, 이 handler는 자식 컴포넌트에서 발생시킨 effect(throw promise)를 부모 컴포넌트(suspense)에서 잡아 적절하게 처리한 뒤, 다시 자식 컴포넌트가 멈췄던 곳으로 흐름을 되돌려주는 것을 말한다.

대수적 효과는 어떤 코드 조각을 감싸는 맥락으로 side effect에 대한 책임을 분리하고, 분리된 책임에 대한 처리는 감싸는 맥락에서 처리하게 함으로써 "무엇"과 "어떻게"를 분리한다. 이렇게 책임을 분리하는 방식은 코드를 선언적으로 작성할 수 있는 관점을 제공하며 이는 앞서 말한 리액트의 설계 원칙과 동일하다.

즉 대수적 효과에서 영감을 받아 Suspense에게 비동기 작업의 로딩 상태에 대한 책임을 넘겼으며, 비동기 작업 처리 컴포넌트는 로딩 상태의 책임으로부터 벗어나 UI 선언에만 집중하도록 만들어줬다.

ErrorBoundary

ErrorBoundary는 리액트에서 에러를 선언적으로 처리하기 위해 제공하는 컴포넌트이다. 자식 컴포넌트에서 발생한 에러를 전달받아 핸들링하여 애플리케이션이 중단되는 것을 막는다.

ErrorBoundary 코드는 리액트 공식 문서에 제공된 기본 코드를 참고하여 사용한다.

ErrorBoundary에서 핵심은getDerivedStateFromError 메서드와 componentDidCatch 메서드이며, 어느 코드든 이 두 메서드만 가지고 있으면 에러 바운더리가 될 수 있다.

getDerivedStateFromError

• render 단계에서 실행된다. => 순수함수여야 한다.
• 자식 컴포넌트가 에러를 던질 때 호출된다.
• fallback UI를 표시하기 위해 state를 업데이트해야 한다.

  componentDidCatch

• commit 단계에서 실행된다. => side effect 허용된다.
• 자식 컴포넌트가 에러를 던질 때 호출된다.
• 에러 로그를 기록할 때 사용된다.

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  componentDidCatch(error, info) {
    logErrorToMyService(error, info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return this.props.fallback;
    }

    return this.props.children;
  }
}

사용 방법

에러가 발생할 수 있는 컴포넌트를 ErrorBoundary 컴포넌트로 감싸서 사용한다. 필요에 따라 에러 발생시 사용자에게 보여줄 fallback UI를 props로 전달할 수 있다.

<ErrorBoundary fallback={<Error />}>
  <App />
</ErrorBoundary>

ErrorBoundary가 캐치하지 못하는 에러

ErrorBoundary가 모든 에러를 캐치할 수 있는 것은 아니다. 리액트 공식문서에서 아래와 같은 에러는 ErrorBoundary가 캐치할 수 없다고 한다.

• 이벤트 핸들러
• 비동기 작업(fetch API, setTimeout, requestAnimationFrame 콜백 등)
• 서버 사이드 렌더링
• 자식이 아닌 에러 바운더리 자체에서 발생하는 에러

이는 자바스크립트와 리액트를 잘 안다면 당연한 결과라 생각할 수 있다.

자바스크립트에서는 코드가 실행되면 실행 컨텍스트가 생성되고, 자바스크립트 엔진의 콜스택에 순차적으로 쌓여 실행이 끝나면 pop이 되어 없어진다.

이때 하나의 컨텍스트에서 에러가 발생하면 에러는 상위 컨텍스트로 전파된다. 상위 컨텍스트에서 에러가 처리되지 않으면 최상위 실행 컨텍스트로 전파되고 전체 애플리케이션이 중돤된다.

try {
    function throwErrorFn(a) {
        throw new Error('error')
    }
    setTimeout(throwErrorFn, 1000);
} catch(e) {
    console.log(e)    
}

위 예제를 보고 다시 정리하면 setTimeout 내의 throwErrorFn 콜백 함수는 1초 후에 실행 컨텍스트에서 실행된다. 하지만 그때는 이미 try-catch 문이 있는 실행 컨텍스트가 pop된 상황이기 때문에 catch할 수 없어 상단에 에러를 전파한다.

즉 try-catch 문의 컨텍스트 내에서 throwErrorFn 함수가 실행되지 않기 때문에 에러를 캐치할 수 없는 것이다.

ErrorBoundary 또한 try-catch와 동일한 원리로 동작한다. ErrorBoundary 실행 컨텍스트안에서 에러가 발생한다면 캐치할 수 있고 그 안에 없다면 캐치할 수 없다. 매우 단순하다.

이벤트 핸들러

이벤트 핸들러 내에서 발생한 에러는 에러 바운더리가 캐치하지 못한다. 자바스크립트에서는 보통 addEventListenr를 이용하여 DOM node에 직접 이벤트를 등록한다.

document.getElementById("main_button").addEventListener("click", callbackFn)

하지만 리액트에서의 모든 이벤트는 root element에서 핸들링된다.

getEventListeners(document.getElementById('root'))

위 코드를 콘솔에 찍어보면 모든 이벤트가 root에 등록되어 있는 것을 알 수 있다.

root는 최상위 Html tag이고, 이곳에서 모든 이벤트 핸들링이 발생한다. 그렇기 때문에 이벤트 핸들링 과정에서 에러가 발생한다면, 이 코드는 ErrorBoundary 바깥에 있을 것이기 때문에 에러를 캐치하지 못한다.

이벤트 핸들러에서 에러를 핸들링하고 싶다면 try-catch 문을 사용하여 의도적으로 내부에서 에러를 캐치해야 한다.

비동기 작업

이는 위에서 본 setTimeout 예제와 같은 예시이다. setTimeout의 콜백함수는 1초 후에 실행되며, 이 시점은 이미 ErrorBoundary의 실행 컨텍스트가 끝난 시점이다. 그래서 ErrorBoundary는 비동기 작업의 에러를 캐치하지 못한다.

ErrorBoundary를 이용하여 비동기 작업의 에러를 처리하기 위해서는 별도의 에러 상태를 선언하고, 비동기 작업 내에서 에러 상태를 업데이트시킨다. 이를 통해 리렌더링이 발생하고 에러 바운더리 컨텍스트 내에서 에러를 동기적으로 throw 한다.

const [error, setError] = useState(null)

const handler = async () => {
 try {
     const response = await fetch('url')
 } catch(e) {
    setError(e)
 } 
}

if(error) throw error

tanstack query와 같은 비동기 작업 라이브러리에서 제공해주는 throwOnError 옵션을 true로 사용하면 비동기 작업 실패시 에러를 던지기 때문에 별도의 상태 처리 없이 비동기 작업에서 발생하는 에러를 에러 바운더리에서 캐치할 수 있다. tanstack query throwOnError

서버 사이드 렌더링

ErrorBoundary는 상태값을 변경하는 getDerivedStateFromError 메서드를 기반으로 동작한다.

해당 메서드는 에러 인자를 받아, 해당 ErrorBoundary에서 처리할 에러인지 판단하고 처리할 에러라면 hasError와 같은 상태값을 true로 변경시켜 fallback UI를 렌더링한다.

이와 같이 상태값을 변경하는 메서드는 상태 변화가 존재하는 클라이언트 환경에서만 실행되고 서버 환경에서는 실행되지 않기 때문에 서버 사이드 렌더링에서 발생하는 에러는 당연히 캐치할 수 없다.

자식이 아닌 ErrorBoundary 자체에서 발생하는 에러

ErrorBoundary에서 에러를 받고 다시 에러를 throw 한다면 해당 에러는 상위 ErrorBoundary로 전파되기 때문에 ErrorBoundary 자체에서 발생하는 에러는 캐치할 수 없다.

출처 및 참고자료

Suspense for data fetching react docs Error Boundary react docs 보아즈, 에러 바운더리가 캐치, 캐치 못하는 에러 토스, 프론트엔드에서 우아하게 비동기 처리하기 error와 error handling 리액트 앱이 에러를 처리하는 방법 테코톡, 아인노아 에러핸들링 테코톡, 밧드 에러핸들링 테코톡, 티케 에러핸들링 테코톡 클린 서스펜스와 에러바운더리 유인동, 비동기 프로그래밍 및 실전 에러 핸들링 sentry를 이용한 에러 추적 Learn React Error Boundary In 7 Minutes React에서 선언적으로 비동기 다루기 프론트엔드 에러 핸들링에 대한 고민 React의 Error Boundary를 이용하여 효과적으로 에러 처리하기 React 18의 Suspense에 대해서 알아보자 React 대수적 효과 Conceptual Model of React Suspense Algebraic Effects of React Suspense Suspense Deep Dive (Code Implementation) Suspense for Data Fetching의 작동 원리와 컨셉 (feat.대수적 효과) 추상화를 위한 대수적 효과(Algebraic Effect)와 React Suspense 선언적인 코드 작성하기 Declarative React, and Inversion of Control Suspense의 동작 원리 ErrorBoundary가 포착할 수 없는 에러와 그 이론적 원리 분석

테스트 코드의 목적 및 종류

테스트란?

테스트는 우리가 작성한 코드가 예상대로 작동하는지 확인하는 과정을 의미한다.

가장 기본적이고 확실한 테스트 방법은 기능을 직접 사용하여 기능이 의도한대로 제대로 작동하는지 확인하는 것이다. 그러나 코드가 수정될 때마다 직접 테스트를 수행하는 것은 시간이 많이 걸리고, 실수할 가능성이 있다.

그래서 테스트 코드를 작성하여 테스트 과정을 자동화한다.

프론트엔드에서의 테스트

프론트엔드 테스트는 일반적인 테스트와 다르다.

비즈니스 로직을 담은 함수의 입출력(I/O)을 검증하거나 세부 구조 및 동작을 검증하는 것과 달리, 프론트엔드 테스트는 사용자 경험에 초점을 맞춘다.

즉 사용자가 발생시키는 이벤트(click, scroll, focus 등)에 대한 화면의 반응을 확인하는 과정이다. 이를 통해 적절한 화면이 출력되었는지 테스트한다.

이벤트 트리거는 react testing library와 같은 도구를 사용해 쉽게 수행할 수 있지만, 출력된 화면을 확인하는 것은 간단하지 않다. 사람이 직접 확인할 때는 화면이 기대와 동일한지 눈으로 확인하지만, 컴퓨터는 픽셀 단위로 비교해야 하며 이는 많은 시간을 소요하고 거짓 음성을 발생시킬 수 있다.

거짓 음성(false nagetive)이란 실제 결과는 성공했지만 테스트는 실패한 경우이다. 이는 사람의 눈에는 원하는 화면이 출력되었지만 픽셀에서 차이가 발생하기 때문에 발생한다.

따라서 픽셀 비교 대신 기능의 중요한 내용을 비교 단위로 삼는 방식이 존재한다. 예를 들어, 버튼을 누르면 특정 텍스트가 추가되는지 확인하는 것이다. 이는 픽셀 비교 방식보다는 정확성이 떨어질 수 있지만, 시간 소요와 거짓음성 문제를 해결할 수 있다.

픽셀 비교는 시각적 테스트, 기능 비교는 기능적 테스트라고 한다.

시각적 테스트에는 스냅샷 테스트와 시각 회귀 테스트가 있고, 기능적 테스트에는 단위 테스트, 통합 테스트, E2E 테스트가 있다.

테스트 코드의 목적

자동화된 검증

• 신규 기능 개발 시, 이를 검증하기 위한 QA 과정에 많은 시간과 노력이 소요된다.
• 또한 기존 코드와 연관된 새로운 기능을 개발하거나 리팩토링할 때, 테스트 코드가 없으면 반복적인 QA 과정을 거쳐야 한다.
• 서비스의 안정성을 보장할 수 있는 테스트 코드가 있다면 QA 과정에서 에러 발생 확률이 줄어들고, 자유롭게 리팩토링하거나 새로운 기능을 추가할 수 있다.

제품에 대한 신뢰성 확보

테스트 코드를 작성하기 전에 지원하는 기능을 명확히 정의함으로써 사용자가 사용하는 기능이 제대로 작동할 것이라는 신뢰성이 생긴다.

TDD를 제안한 켄트 벡은 테스트 코드 작성을 불안함을 지루함으로 바꾸는 과정이라 했다.

협업 효율성 증가

애플리케이션이 지원하는 기능을 명확히 정의하여 테스트 코드를 정의하기 때문에 팀원이 어떤 기능을 개발하고 테스트하는지 한 눈에 확인할 수 있다. 즉 테스트 코드 파일 자체가 잘 작성된 개발 문서로 활용될 수 있다. 이는 협업에 있어 소통의 안정성을 더해준다.

테스트 코드의 종류

단위 테스트(Unit test)

• 단위테스트란 애플리케이션 안에 있는 개별적인 코드 단위를 테스트하는 방식이다.

• 보통 함수, 리액트 컴포넌트, 커스텀 훅을 테스트한다.

• 다른 코드의 유닛과 상호작용하는 것을 테스트하지 않는다.

• 입력값만을 이용해 출력값을 결정짓는 순수함수이면 좋다.

  • 순수함수의 경우 오로지 입력값만으로 출력값이 정해지기 때문에 외부 상태값을 가짜로 만들어내지 않아도 되어서 테스트하기 쉽고, 가짜 값을 만들지 않다보니 가짜 값이 유효한 값인지 신경쓰지 않아도 되기 때문이다.
  • 외부에 의존성이 있다면 의존성을 mocking(가짜로 대체)한다. 외부 의존성의 실패가 아닌 특정 유닛의 실패임을 단정하기 위함
  • 격리된 unit test에서 실패를 쉽고 정확하게 파악할 수 있다.

• 근데 이는 사용자가 소프트웨어와 상호작용하는 방식과는 거리가 멀다.

• 또한 리팩토링하는 과정에서 실패할 수 있다. => 동작은 그대로이나 구현의 변경이 테스트 실패의 원인이 될 수 있다.

• 도메인과 관련이 높고, 의존성이 낮으면서 로직이 복잡한 함수가 최고의 대상이다.

• 지나치게 복잡한 코드는 리팩토링의 신호이다.

• 컨트롤러와 같이 외부의존성만을 다루는 코드는 테스트의 우선순위가 낮다.

unit test 예시

// 컴포넌트 테스트 예시
const TextField = ({ title, onChange }) => {
  return (
    <div>
      <label htmlFor={title}>{title}</label>
      <input id={title} onChange={onChange}></input>
    </div>
  )
}

// 테스트
test("label을 클릭하면 input이 foucus 됩니다", async () => {
  const title = "일련번호"
  const onChange = jest.fn()

  render(<TextField title="일련번호" onChange={onChange} />)

  userEvent.click(screen.getByText("일련번호"))

  expect(screen.getByLabelText(title)).toHaveFocus()
})

test("input에 값을 넣은 만큼 onChange 핸들러가 호출 됩니다", async () => {
  const title = "일련번호"
  const onChange = jest.fn()

  render(<TextField title={title} onChange={onChange} />)

  userEvent.click(screen.getByText(title))
  userEvent.type(screen.getByLabelText(title), "hello")

  expect(onChange).toHaveBeenCalledTimes(5)
})

// 커스텀 훅
export const useCarousel = (initialIndex: number, carouselLength: number) => {
  const [step, setStep] = useState(
    initialIndex < carouselLength ? initialIndex : 0
  )

  const prevStep = () => {
    if (step === 0) return setStep(carouselLength - 1)
    setStep(step - 1)
  }

  const nextStep = () => {
    if (step === carouselLength - 1) return setStep(0)
    setStep(step + 1)
  }

  return { step, prevStep, nextStep }
}

// 테스트
it("초기값이 캐러샐 길이보다 긴 경우 첫번째 step을 0으로 설정한다", () => {
  const { result } = renderHook(() => useCarousel(5, 3))

  expect(result.current.step).toBe(0)
})

})

통합 테스트(Integration test)

• 통합 테스트는 여러 유닛을 통합하여 함께 동작하는 방식을 테스트하는 것을 의미한다.

• 유닛(컴포넌트)을 통합한 결과는 페이지가 될 수도 있고 페이지 내의 특정 영역이 될 수도 있다.

• 통합테스트가 시간이 좀 오래걸리더라도 단위테스트보다 어플리케이션의 신뢰성을 확보하는데 훨씬 효과적이다.

• 통합 테스트 단계에서는 실제 Api를 사용하게 되면 시간이 오래 걸리는것 뿐만 아니라 테스트가 백엔드에 의존성을 가져서 백엔드의 문제 때문에 실패하는 상황이 발생 할 수 있다. Api의 경우 테스트를 위해 모킹을 하는것이 좋다.

• 통합테스트를 위한 API 모킹시에는 msw라는 라이브러리가 유용하다.

  Integration test 예시

  it("검색어 입력후 검색 버튼을 클릭하면 검색 결과를 보여준다.", async () => {
  render(<App />)
  
  const inputBox = screen.getByRole("textbox")
  const searchButton = screen.getByRole("button")
  
  act(() => {
    userEvent.type(inputBox, "테스트")
    userEvent.click(searchButton)
  })
  
  await waitFor(() => {
    expect(screen.getAllByText("테스트", { exact: false }).length).toBe(20)
  })
  })
  

it("검색어 입력후 검색 버튼을 클릭하였을때 결과가 없을 경우 결과가 없음을 보여준다", async () => { render()

const inputBox = screen.getByRole("textbox") const searchButton = screen.getByRole("button")

act(() => { userEvent.type(inputBox, "검색 결과 없는 검색어") userEvent.click(searchButton) })

await waitFor(() => { expect(screen.getByText("검색 결과가 없습니다")).toBeInTheDocument() }) })

#### E2E 테스트
- E2E 테스트는 End To End 테스트의 약자로 cypress, playwrite와 같은 E2E 테스트 도구를 이용하여 애플리케이션의 흐름을 처음부터 끝까지 테스트하여 애플리케이션의 무결성을 검증하는 테스트를 의미한다.
- 실제 브라우저 환경에서 실제 api를 사용하기 때문에 테스트 하는데 매우 오랜 시간이 걸린다. 보통 배포 직전에 테스트한다.

##### E2E 테스트 예시(Cypress)
```javascript
it("사용자가 로그인 페이지에 진입해 아이디 비밀번호입력후 엔터키를 눌러 로그인에 성공하는경우 홈으로 이동해 유저 프로필을 확인한다", function () {
  // destructuring assignment of the this.currentUser object
  const username = "test"

  const password = "1234"

  // 로그인 페이지 진입
  cy.visit("/login")

  // 아이디 입력 input에 username 입력
  cy.get("input[name=username]").type(username)

  // 패스워드 입력 input에 password 입력 및 enter 입력
  cy.get("input[name=password]").type(`${password}{enter}`)

  // home으로 리다이렉션
  cy.url().should("include", "/home")

  // home에 username이 있는지 확인
  cy.get("h1").should("contain", username)
})

시각적 테스트

• 앞서 설명한 기능적 테스트 만으로 우리가 만든 애플리케이션이 정상 동작함을 보장할 수 없다.

• 기능은 동작할지 몰라도 글자가 너무 작아서 보이지 않거나 혹은 색상이 의도와 달라 눈에 잘 안 들어올 수 있다.

• 이를 위해 프론트엔드에서는 시각적 테스트를 수행해야 한다.

• 시각적 테스트에는 크게 스냅샷 테스트와 시각적 회귀 테스트가 있다.

  스냅샷 테스트

• 스냅샷이란 특정 시점의 컴포넌트 혹은 함수의 결과를 직렬화하여 텍스트 형태로 저장해두고 매 테스트 마다 변경되었는지를 확인하여 변경이 실제 의도한것인지 확인하는 것이다.

• 스냅샷 테스트를 사용하여 간단하게 컴포넌트의 출력을 검증할 수 있지만 html 속성이 아닌 css 속성이 달라진경우를 잡아낼수 없고, 스냅샷이 html태그로 구성된 텍스트 데이터를 보여주기 때문에 비교에 실패하더라도 실제 의도한 출력이 맞는지 확인하기 어려우며, 스냅샷 실패시 테스트를 성공상태로 만들기 매우 쉬워 실제 의도한 출력이 아니더라도 기대하는 테스트 결과로 저장되면 이후 거짓 음성이 나오게되어 테스트에대한 신뢰도가 떨어질 수 있다.

시각적 회귀 테스트

• 앞서 설명한 스냅샷 테스트의 상위 버전이라고 부를수 있으면서 실제 프론트엔드에서 테스트와 가장 유사한 테스트 이다.
• 많은 비용이 드는 테스트 이므로 주로 CI환경에 테스트 플로우를 세팅해두어 사용한다.
• 플로우는 다음과 같은데, 매 커밋시마다 테스트 대상의 화면과 저장된 화면을 비교하여 차이가 있는지 파악하고, 차이가 존재한다면 사용자의 approve 혹은 코드 수정을 통해 테스트를 통과시키는 방식이다.
• 시각적 회귀 테스트는 여러 도구로 수행할수 있다. storybook과 chromatic의 조합으로 사용 하는 방식이 있다.
• 시각적 회귀 테스트를 수행하지 않더라도 storybook을 이용하면 개별 컴포넌트를 시각적으로 확인하기 용이하기 때문에 만약 시각적 회귀 테스트 비용이 부담된다면 storybook을 이용해 매 코드 변경시 컴포넌트의 UI를 확인하거나 혹은 개발시 UI를 확인하면서 작업할때 용이하다.

기능 테스트(Functional test)

• 위에서 언급한 테스트 종류와 별개로 기능 테스트라는 것이 있다.
• 우리가 지향해야 하는 테스트가 바로 기능 테스트이다.
• 기능 테스트는 소프트웨어의 특정 기능이 명세서나 요구사항에 맞게 동작하는지를 확인한다.
• 소프트웨어가 실제 사용자 경험과 유사하게 작동하는지를 테스트하여, 사용자와 소프트웨어의 상호작용 방식을 평가한다.
• 코드가 아닌 실제 사용자의 소프트웨어 사용 경험을 중점으로 테스트한다.
  • 코드가 리팩토링되더라도 동작이 동일하면 테스트는 통과한다.
  • 테스트가 통과하면 사용자 경험상 문제가 없음을 보장한다.
  • 장점: 사용자의 실제 소프트웨어 사용 방식을 반영하기 때문에, 사용자의 입장에서 소프트웨어가 제대로 동작하는지를 확인할 수 있다.
  • 단점: 테스트가 실패할 경우 디버깅이 어려울 수 있다.
  • RTL 철학과의 유사성: 기능 테스트는 내부 코드 구현보다는 사용자의 소프트웨어 사용을 테스트하는 것을 중시합니다. 이는 테스트 도구인 RTL(React Testing Library)의 철학과 일치한다.

    Kent C. Dodds

• 신뢰성 확보
  • 사용자가 애플리케이션을 사용할 때 제대로 작동할 것이라는 신뢰성을 위해 테스트를 작성한다.
  • 테스트는 소프트웨어 사용 방식과 유사할수록 신뢰도가 높아진다.
  • 코드를 테스트하기보다는 서비스가 지원하는 기능인 Use Case를 테스트해야 한다.
  • 구현 세부 사항을 테스트하면 딴 길로 새기 쉽다.
  • 즉 코드 내부의 동작 방식을 테스트하는 것이 아니라 코드가 사용자에게 제공하는 기능을 테스트하는 것에 초점을 맞춰야 한다.
  • unit test 든 integration test 든 테스트의 종류와 상관없다.
• 테스트 대상 선정 방법
  • 테스트 코드 커버리지는 크게 신경써야 할 지표가 아니다.
  • 대신 use case 커버리지가 중요하다. 이는 우리가 수동으로 작성해야 한다.
  • 테스트 코드 작성하기 전에 모든 use case를 생각해야 한다.
  • 즉 애플리케이션이 지원하는 기능의 목록을 작성하고 이 기준에 따라 우선순위를 정하는 것이 좋다.
    • 애플리케이션에서 에러가 발생하면 큰일이 나는 부분부터 테스트 코드를 우선해야 한다.
    • 회의를 통해 모든 프론트엔드 개발자들이 테스트의 중요성을 이해하고 우선순위를 확립하도록 한다.
  • use case 커버리지를 작성하고 이를 기반으로 테스트 코드를 작성하고, 구현 코드를 작성한다. 이 과정으로 인해 테스트 파일 자체가 기능 명세서가 될 수 있다.
  • 즉 코드를 테스트하는 것이 아니라 use case를 테스트해야 한다.
• 리팩토링
  • 리팩터링은 기존에 의도한 동작은 유지하면서 구현만 변하는 것을 의미한다.
  • 구현 세부사항 테스트에 집중하면 false positive, false negative가 발생할 수 있다.
  • false negative는 동작은 성공하지만 테스트 코드가 실패하는 경우이다.
    • 리팩터링 시 false negative를 줄 수 있다.
    • 즉 기존 동작은 변경하지 않으면서 구현만 변경을 했음에도 불구하고 테스트가 실패한다.
    • 그 결과 유지 관리가 어렵고 성가신 테스트 코드가 많이 생성된다.
  • false positive는 테스트는 성공했지만, 원래는 실패했어야 한다는 뜻이다.
    • 이를 방지하기 위해 구현 세부 사항을 테스트하지 않도록 API를 제한하면서 모든 테스트를 다시 작성해야 한다.
    • RTL을 사용하면 그의 철학으로 인해 구현 세부 사항을 테스트하는 것이 아니라 기능 자체를 테스트할 수 있다.

TDD와 테스트 코드 작성 가이드라인

테스트 주도 개발(TDD)

TDD란 Test Driven Development의 약자로 켄트 벡이 1999년 익스트림 프로그래밍의 일부로 제안하며 널리 알려졌다. 동작하는 코드 작성 이전에 테스트를 먼저 작성하고 그 테스트를 통과하는 코드를 작성함으로써 테스트된 동작하는 코드를 얻는 개발 방법이다.

흐름

• 테스트 코드를 작성한다. (빨간 막대)
  • 구현하려는 동작을 설명하는 테스트 코드를 작성한다.
    • 동작을 구현하는 코드는 아직 작성하지 않았으니 당연히 실패해야 한다.
• 실행 가능하게 만든다. (초록 막대)
• 올바르게 만든다. (리팩토링)

  TDD와 use case 커버리지 작성

• Kent C. Dodds이 말한 테스트 코드 작성 이전 use case 커버리지 작성은 TDD와 궁합이 잘 맞는다.
• use case 커버리지 작성 이후, 테스트 코드를 작성하고 구현 코드를 작성한다.

테스트 코드 작성 프로세스

1. 개발 회의를 통해 애플리케이션 기능의 우선순위를 정한다.
2. 기능을 배정받은 개발자는 각 기능의 use case coverage를 작성한다.
3. 각 use case마다 테스트 코드를 작성한다.
4. 테스트 코드에 맞게 구현 코드를 작성한다.
5. 리팩토링한다.

가이드라인

• 제목을 알아보기 쉽게 설정한다. 다른 개발자가 보고 즉시 의미를 알아챌 수 있어야 한다.
• 하나의 테스트에는 하나의 기능만 테스트한다.
• 가독성을 위해 AAA 패턴을 지킨다.
• 내부 구현을 테스트하는 것이 아니라 사용자가 실제로 사용하는 방식으로 소프트웨어를 테스트하는 것이 목표이다.
• 단위 테스트(Unit Test), 통합 테스트(Integration Test), E2E 테스트 등 여러 테스트의 종류가 있지만 이들 모든 테스트의 목적은 특정 기능이 올바르게 작동하는지를 검증하는 것이다.
• 보통 통합 테스트를 먼저 작성하고, 단위 테스트나 E2E 테스트를 작성하는 방식으로 한다.
• 새로운 기능 추가 또는 리팩토링시 코드 구현이 변경되어도 의도된 동작이 그대로 수행되어 테스트가 통과되어야 한다.
• 테스트 코드는 중복이 다소 발생하더라도 직관적이고 명확하게 이해되도록 테스트 코드를 작성해야 한다.
• 100% Code Coverage를 목표로 삼지 말아야 한다. 그럴 가치가 없다.
• 테스트 코드는 완벽하지 않아도 된다.
• E2E 테스트는 비용이 많이 들기 때문에 비즈니스적으로 중요한 영역에 적용한다.
• 시각적 테스트는 시각적 요소가 중요한 페이지에만 적용한다.
• 모킹이 많은 것은 이상적이지 않다.
• 스냅샷 테스트보다는 시각적 회귀 테스트를 사용하는 것이 좋다.
• 정기적인 코드리뷰를 통해 테스트 코드에 대한 피드백을 제공하고 개선점을 논의한다. 이를 통해 모든 팀원이 테스트 코드를 작성하는 문화가 자리잡음으로써 전체적인 코드 품질과 안정성 향상을 도모할 수 있다.

  AAA 패턴

• Arrange
  • 테스트가 목표로 하는 시나리오에 대한 시스템을 제공하기 위한 모든 설정 코드 작성
• Act
  • 테스트 실행, 필요시 결과 저장
  • 테스트 대상 시스템 메서드 호출하고 결과, 출력값을 저장.
• Assert
  • 받은 예상값이 충족하는지 검증

사용 테스트 도구

React Testing Library

https://testing-library.com/docs/react-testing-library/intro/

가상 DOM 제공

브라우저 없이 테스트하기 위해 시뮬레이션된 DOM을 생성하고, 이를 활용하여 DOM과 상호작용할 수 있는 유틸리티를 제공한다.

렌더링 이후, react testing library의 전역 객체 screen을 통해 시뮬레이션된 DOM에 액세스할 수 있다.

사용자 중심의 테스트

사용자가 실제로 소프트웨어를 사용하는 방식과 동일하게 테스트할 수 있도록 돕는다.

테스트에서 사용자가 버튼 클릭과 같은 작업을 하고 버튼을 클릭한 후 DOM이 어떤 모습인지 확인할 수 있다.

모범 사례 지향

구현 세부 정보보다는 구성 요소의 동작을 테스트하는 데 중점을 두며, HTML 태그를 최대한 활용하여 테스트한다.

RTL이 공식문서에서 강조하는 원칙은 다음과 같다.

"테스트 코드를 작성하고 테스트를 수행함에 있어서 테스트가 서비스의 사용 방식과 유사할수록 더 많은 신뢰를 얻을 수 있다"

이는 즉 우리가 추구하는 테스트 목표와 동일하다.

RTL이 요소를 찾는 방법

1. 접근성 높은 메서드
   • getByRole: 접근성 트리에 노출된 모든 요소를 조회하며, 가장 접근성과 사용자 경험을 고려하는 메서드이다.
   • getByLabelText: form 필드 내부 요소들을 각자의 label로 찾는다.
   • getByPlaceholderText: placeholder를 대체자로 사용한다.
   • getByText: 텍스트로 요소를 찾는다.
   • getByDisplayValue: form 내부에서 이미 값이 입력된 요소를 찾는다.
2. ARIA 관련 props 사용 메서드
   • getByAltText: 요소 내에 alt 속성을 조회한다.
   • getByTitle: Title 속성을 조회한다.
3. Test-id
   • getByTestId: 위의 방법이 모두 불가할 때 최후의 수단으로 사용한다.

Vitest

https://vitest.dev/ 테스트를 찾고, 실행하며, 통과 여부를 결정하는 도구이다. Jest와 문법이 동일하고 빌드 도구인 vite와 호환성이 좋다. RTL은 시뮬레이션된 DOM을 리턴하며, Vitest와 같은 테스트 러너를 사용하여 테스트를 실행한다.

MSW(Mocking Service Worker)

MSW 공식 문서 MSW는 브라우저 및 Node.js 환경에서 사용 가능한 API 모킹 라이브러리이다.

사용 배경

• 프로덕션 코드에서 백엔드 API 개발 속도와 프론트엔드 개발 속도가 맞지 않아 프론트엔드 개발 진행에 어려움이 있을 수 있다.
• 테스트 코드를 작성하고 실행할 때 실제 API 요청을 할 경우 비용, 속도 및 의존성 문제가 발생할 수 있다.
• MSW 라이브러리를 이용하면 Mock 서버를 구축하지 않아도 API를 네트워크 수준에서 Mocking 할 수 있다.
• MSW는 네트워크 요청 과정에서 Request에 대한 Mocking이 가능한 라이브러리이며 네트워크 요청을 가로채서 모의 응답을 보내주는 역할을 한다.

  특징

• 독립성 라이브러리나 프레임워크에 영향을 받지 않게 설계되었다. 별도의 플러그인 설치 없이 모든 브라우저와 Node.js 환경에서 사용 가능하다.
• 실제 네트워크 요청 모킹 fetch와 같이 네트워크 요청 함수를 mocking하는 것에 그치지 않고 실제로 보내진 네트워크 요청을 가로챈다.
• 재사용성 프로덕션 코드 및 테스트 코드에서 모두 사용 가능하다.

  원리

  

브라우저에서는 브라우저에서 제공하는 Service Worker를 이용해서 mocking 한다. (Node.js 환경에서는 http, XMLHttpRequest와 같은 네트워크 프로토콜을 mocking 한다.)

• Service Worker는 웹 애플리케이션의 메인 스레드와 분리된 별도의 백그라운드 스레드에서 실행시킬 수 있는 기술 중 하나이다. Service Worker 덕분에 애플리케이션의 UI Block 없이 연산을 처리할 수 있다.
• locoahost가 아닌 환경에서는 HTTPS가 기본적으로 제공되는 환경에서만 사용할 수 있다.

브라우저에서의 원리

1. 브라우저가 요청을 한다.
2. Service Worker가 이를 인지한다.
3. Service Worker는 요청을 실제 서버로 보내지 않고 요청을 복사하여 클라이언트 사이드에 있는 MSW 라이브러리로 보낸다.
4. MSW는 해당 요청에 대한 handler를 찾아서 등록된 모의 응답값을 Service Worker를 통해 브라우저에게 전달한다.
5. 이를 통해 실제 서버 존재 여부와 상관없이 실제 요청으로 이어지지 않고 예상할 수 있는 요청에 대해 Mocking이 가능해진다.

개발 흐름

• 기획자 요구 전달.
• 프론트엔드 개발자와 백엔드 개발자가 API 스펙 합의.
• 프론트엔드 개발자는 MSW를 통해 네트워크 레벨에서의 Mocking을 진행한 후 앱 개발.
• API 없이도 프론트엔드 개발자는 높은 완성도를 갖고 있는 수준에서 기획자와 미리 프론트엔드 애플리케이션 확인하며 피드백 주고받고 그 사이 백엔드 개발자는 API 개발을 진행.
• 백엔드 개발자가 실제 API를 개발하면, 프론트엔드 개발자는 MSW를 스위치 오프하여 production으로 배포할 수 있는 형태의 개발을 진행.

출처 및 참고 자료

https://github.com/goldbergyoni/javascript-testing-best-practices/blob/master/readme.kr.md

https://techblog.woowahan.com/17721/

https://techblog.woowahan.com/17404/

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

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

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

https://www.jbee.io/articles/developments/%ED%85%8C%EC%8A%A4%ED%8A%B8%EC%97%90%20%EB%8C%80%ED%95%9C%20%EC%98%A4%ED%95%B4%EC%99%80%20%EC%82%AC%EC%8B%A4

https://tech.kakaopay.com/post/implementing-tdd-in-practical-applications/

https://tech.kakao.com/posts/458

https://blog.lemonbase.team/%EC%9A%B0%EB%A6%AC-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%ED%8C%80%EC%97%90%EB%8A%94-%EC%96%B4%EB%96%A4-%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A5%BC-%EC%A0%81%EC%9A%A9%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C-a3ea48207cd4

https://tech.madup.com/mock-service-worker/

https://tech.madup.com/front-test-tips/

https://developer-bandi.github.io/post/frontend-testing/

// kent c. dodds 글 번역 https://soojae.tistory.com/74 https://soojae.tistory.com/82?category=1010060 https://soojae.tistory.com/83?category=1010060 https://soojae.tistory.com/84?category=1010060 https://jaehyeon48.github.io/testing/avoid-nesting-when-youre-testing/ https://jymini.tistory.com/73

https://yozm.wishket.com/magazine/detail/2435/ https://yozm.wishket.com/magazine/detail/2483/

https://im-developer.tistory.com/226

https://velog.io/@sehyunny/a-compilation-of-outstanding-testing-articles

https://musma.github.io/2023/07/24/front-end-test-code.html

https://team.modusign.co.kr/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C%EC%97%90%EC%84%9C-%EC%9D%98%EB%AF%B8%EC%9E%88%EB%8A%94-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%ED%95%98%EA%B8%B0-4992409c7f2d

https://ykss.netlify.app/translation/unit-testing-with-jest-react-and-typescript/

https://github.com/ssi02014/react-test-reference-documentation?tab=readme-ov-file

https://techblog.pet-friends.co.kr/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-%EB%8F%84%EC%9E%85%EA%B8%B0-c3a1865250ee

AHA 법칙 Avoid Hasting Abstraction https://jaehyeon48.github.io/testing/avoid-nesting-when-youre-testing/ https://kentcdodds.com/blog/aha-testing

MSW 사용 방법

1. Main 브랜치 준비

   • main 브랜치는 항상 배포 가능한 상태를 유지합니다.
   • 모든 변경 사항은 Pull Request(PR)를 통해 main 브랜치에 병합됩니다.

2. 새로운 브랜치 생성

   • 새로운 작업을 시작할 때 main 브랜치에서 새로운 브랜치를 생성합니다.
   • 브랜치 이름은 작업 내용을 잘 나타낼 수 있도록 명확하게 짓습니다.

     git checkout -b feature-branch

3. 커밋 및 작업
   • 작업을 진행하면서 변경 사항을 로컬 브랜치에 커밋합니다.
   • 커밋 메시지는 간결하고 명확하게 작성하여 변경 사항을 쉽게 이해할 수 있도록 합니다.

     git add .
     git commit -m "Add new feature"

4. 원격 저장소에 푸시

   • 로컬 브랜치의 변경 사항을 GitHub의 원격 저장소에 푸시합니다.

     git push origin feature-branch

5. Pull Request 생성

   • GitHub 웹사이트에서 PR을 생성하여 코드 변경 사항을 검토받습니다.
   • PR에서 변경 사항에 대한 설명을 추가하고 리뷰어를 지정합니다.
   • PR 제목과 설명은 변경 사항의 목적과 내용을 명확하게 전달하도록 작성합니다.

6. 코드 리뷰 및 피드백

   • 다른 팀원들이 PR을 리뷰하고 피드백을 제공합니다.
   • 필요시 수정사항을 로컬 브랜치에 커밋하고 다시 푸시합니다.

     git add .
     git commit -m "Address review feedback"
     git push origin feature-branch

7. PR 병합

   • 모든 리뷰어가 PR을 승인하면, main 브랜치에 병합합니다.
   • 병합은 GitHub 웹사이트에서 수행합니다.
   • 병합 후 로컬 main 브랜치를 업데이트합니다.

     git checkout main
     git pull origin main

8. 브랜치 삭제

   • 병합된 브랜치는 더 이상 필요하지 않으므로 삭제합니다.

     git branch -d feature-branch
     git push origin --delete feature-branch

GitHub Flow 예제

예제 시나리오: 새로운 기능 개발

1. 메인 브랜치로 이동하고 최신 상태로 업데이트

   git checkout main
   git pull origin main

2. 새로운 브랜치 생성

   git checkout -b add-login-feature

3. 코드 작업 및 커밋

   # 작업 수행
   git add .
   git commit -m "Add login feature"

4. 원격 저장소에 푸시

   git push origin add-login-feature

5. GitHub에서 PR 생성

   • GitHub 웹사이트로 이동하여 새로운 PR을 생성합니다.
   • PR 제목과 설명을 작성하고 리뷰어를 지정합니다.

6. 코드 리뷰 및 피드백 반영

   • 리뷰어의 피드백을 반영하여 코드 수정

     git add .
     git commit -m "Fix issues from code review"
     git push origin add-login-feature

7. PR 병합

   • 리뷰어가 PR을 승인하면 main 브랜치에 병합합니다.
   • 병합 후 로컬 main 브랜치를 업데이트합니다.

     git checkout main
     git pull origin main

8. 브랜치 삭제

   git branch -d add-login-feature
   git push origin --delete add-login-feature

eslint는 자바스크립트 코드에서 발견된 문제 패턴을 식별하기 위한 정적 코드 분석 도구이다.

vite 프로젝트를 생성하면 아래와 같이 eslint가 기본적으로 설치된다. 에디터에서 사용하기 위해 vscode eslint extension을 설치한다.

// .eslintrc.cjs
module.exports = {
  root: true,
  env: { browser: true, es2020: true },
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:react-hooks/recommended',
  ],
  ignorePatterns: ['dist', '.eslintrc.cjs'],
  parser: '@typescript-eslint/parser',
  plugins: ['react-refresh'],
  rules: {
    'react-refresh/only-export-components': [
      'warn',
      { allowConstantExport: true },
    ],
  },
}

// package.json
"devDependencies": {
    "@types/react": "^18.3.3",
    "@types/react-dom": "^18.3.0",
    "@typescript-eslint/eslint-plugin": "^7.13.1",
    "@typescript-eslint/parser": "^7.13.1",
    "@vitejs/plugin-react": "^4.3.1",
    "eslint": "^8.57.0",
    "eslint-plugin-react-hooks": "^4.6.2",
    "eslint-plugin-react-refresh": "^0.4.7",
    "typescript": "^5.2.2",
    "vite": "^5.3.1"
  }

eslint-config-airbnb

eslint 규칙을 직접 설정할 수도 있지만 airbnb 스타일 가이드를 사용하고자 한다.

사용 이유

• Airbnb 스타일 가이드는 코드 품질을 보장하기 위해 포괄적인 규칙 세트를 제공한다.
• Airbnb는 대규모 소프트웨어 프로젝트에서 널리 사용되며, 많은 회사들이 Airbnb의 스타일 가이드를 자체 프로젝트에 적용한다.
• Airbnb 팀은 스타일 가이드를 지속적으로 업데이트하고 유지보수한다.
• Airbnb 스타일 가이드는 자바스크립트 뿐만 아니라 리액트 규칙도 함께 있다.
• ESLint와 쉽게 통합될 수 있으며, Prettier와 같은 다른 도구와 함께 사용하기에도 용이하다.
• 문제 해결이나 설정에 관한 정보를 쉽게 찾을 수 있다.

  사용 방법

  https://www.npmjs.com/package/eslint-config-airbnb eslint-config-airbnb 라이브러리는 기본적으로 ECMAScript 6+와 리액트를 포함하는 airbnb ESLint 규칙을 제공하고 아래 5개의 패키지들을 필수로 한다.
• eslint
• eslint-plugin-import : ES6의 import, export 구문을 지원하는 필수 플러그인
• eslint-plugin-react : react 규칙이 들어있는 플러그인
• eslint-plugin-react-hooks: react hook 규칙이 들어있는 플러그인
• eslint-plugin-jsx-a11y: JSX 요소의 접근성 규칙에 대한 정적 검사 플러그인

설치

npm install -D eslint eslint-config-airbnb eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react eslint-plugin-react-hooks

타입스크립트

https://www.npmjs.com/package/eslint-config-airbnb-typescript 타입스크립트 사용하면 eslint-config-airbnb-typescript도 사용해준다. npm install -D eslint-config-airbnb-typescript @typescript-eslint/eslint-plugin@ @typescript-eslint/parser

eslint 적용

다음과 같이 extends를 설정해준다.

// .eslintrc.cjs
extends: [
    'airbnb',
    'airbnb-typescript',
    'airbnb/hooks',
    'plugin:react/recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:prettier/recommeded'
  ],

Prettier

prettier는 일관성 있는 코드 스타일을 유지할 수 있게 도와주는 도구이다.

사용

• npm i -D prettier
• prettier extension 설치
• vscode prettier 적용

  prettier 설정

  // .prettierrc
  {
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 80,
  "tabWidth": 2,
  "semi": true,
  "bracketSpacing": true,
  "arrowParens": "always",
  "endOfLine": "auto"
  }

  eslint와 prettier 동시 설정

  eslint는 prettier의 formatting 기능도 포함되어 있어 충돌 발생 가능성이 있다. 이를 해결하기 위해 추가적인 plugin을 설치해준다.

eslint-config-prettier는 prettier와 충돌 가능성이 있는 옵션을 모두 off해주는 역할을 한다.

eslint-plugin-prettier는 prettier에 위반된 부분을 eslint error로 걸리도록 하는 역할을 하는데, 에러메시지가 지나치게 많아지고 느려지는 문제때문에 사용하지 않는 것을 권장한다.

설치

npm i -D eslint-config-prettier

// .eslintrc.cjs
extends: [
    'airbnb',
    'airbnb-typescript',
    'airbnb/hooks',
    'plugin:react/recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:prettier/recommeded'
  ],

husky

https://typicode.github.io/husky/ 협업 과정에서 개발자들끼리 합의한 eslint나 prettier 등 지켜야 하는 규칙들이 존재하는데, 이런 코드 스타일은 개개인의 에디터에서 적용한다.

개인 사용자가 error나 warning을 무시한 채, 협업 프로젝트에 코드를 커밋하고 푸시하는 것에 제한이 필요하다. 이를 제한하지 않으면 규칙없이 작성된 코드가 머지되고 배포될 가능성이 생긴다.

git에는 hook 기능이 존재하는데, 특정 이벤트(add, commit, push 등)를 실행할 때, 그 이벤트에 hook을 설정하여 hook에 설정된 스크립트를 실행할 수 있다.

git hook을 관리할 수 있게 해주는 husky라는 패키지가 있다. 쉽게 말해서 git 명령어가 실행되면 미리 지정해놓은 스크립트가 실행되도록 관리해주는 도구이다. 여기서는 commit 전에 eslint와 prettier를 작동하게 하고자 한다.

설치

// 설치
npm install husky --save-dev

// git hook 활성화
npx husky init

npx husky init 명령어 실행하면 package.json 파일에 아래와 같은 스크립트가 생성된다.

"scripts": {
  "prepare": "husky install" 
}

// 새로운 hook 추가
npx husky add .husky/pre-commit "npm lint --fix"

이제 커밋을 하면 lint 스크립트 실행 후 커밋이 진행된다.

추가적으로 협업 개발자가 npm install할 때 husky도 install하게 해주는 스크립트도 추가해준다. postinstall은 npm install 직후 자동으로 실행된다.

"scripts": {
  "prepare": "husky install",
  "postinstall": "husky install"
}

lint-staged

https://github.com/lint-staged/lint-staged 위 작업에서 끝내면 모든 파일을 대상으로 lint 스크립트가 실행된다. 프로젝트 파일 수가 많아질수록 실행 속도도 늘어날 것이다. 그래서 변경된 소스에서만 hook이 동작되도록 설정하는 것이 필요하다. 이를 해결하기 위해 lint-staged 패키지를 사용한다.

설치

npm install lint-staged --save-dev

설치 이후 package.json에 원하는 스크립트를 추가한다. 나는 아래의 스크립트를 추가했다. 커밋시에 lint와 prettier를 동시에 진행할 수 있다.

// package.json
"lint-staged": {
    "*.{ts, tsx}": [
      "eslint --fix"
    ],
    "*": [
      "prettier --write --ignore-unknown"
    ]
 },

Same-Origin Policy는 웹 보안 메커니즘 중 하나로 실행중인 애플리케이션의 출처와 다른 출처의 리소스를 요청하는 것을 제한하는 정책이다.

브라우저는 Same-Origin Policy(동일 출처 정책)에 따라 실행중인 애플리케이션의 출처와 다른 출처의 리소스를 요청하면 차단한다. 여기서 말하는 출처는 프로토콜, 호스트, 포트 번호를 말하며, 이 세 가지 요소가 모두 동일한 경우 두 리소스가 동일한 출처를 가지고 있다고 판단한다.

XMLHTTPRequest, Fetch API, 쿠키, 로컬 스토리지 등과 같은 웹 API에 적용된다.

하지만 서로 다른 출처를 아예 차단해버리는 SOP(Same-Origin Policy)를 곧이 곧대로 따르면 상당히 불편할 수 있다.

출처가 서로 다른 요청도 가능하게 하면서 보안상의 문제도 해결하기 위해서 등장한 것이 바로 CORS이다.

CORS

CORS는 Cross Origin Resource Sharing의 약자이며, 교차 출처 리소스 공유를 의미한다.

동작 흐름

1. 브라우저는 다른 출처의 리소스를 요청할 때 Origin 헤더에 요청 출처를 기록한다.
2. 서버는 Access-Control-Allow-Origin 헤더에 허용할 출처를 기록하여 응답 헤더에 담아 보낸다.
3. 브라우저는 Origin 의 출처와 Access-Control-Allow-Origin 헤더의 출처를 비교하여 동일하지 않은 출처로 판단하면 CORS 에러를 발생시킨다.

여기서 중요한 점은 서버가 응답값과 상태코드 200을 보내도, 브라우저가 CORS 위반 사실을 확인하면 애써 받은 응답값을 버린다는 점이다. (대부분의 요청은 사전 요청 방식(preflight)으로 이루어져, 실제 요청이 이루어지기 전 CORS 위반 에러를 만날 수 있다.)

즉 에러 발생 주체는 서버가 아니라 브라우저라는 사실을 알아야 한다.

요청 종류

단순 요청

아래 조건을 충족하는 단순 요청은 사전 요청을 트리거하지 않는다. 하지만 대부분의 경우 조건을 충족하지 못하고 사전 요청을 한다.

• GET, POST, HEAD 메서드 중에 하나 사용
• 자동 설정 헤더를 제외하고 아래의 헤더값만 수동으로 설정된 것
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type(헤더 값이 아래 값 중 하나일 때)
    • application/x-www-form-urlencoded
    • multipart/form-data
      • text-plain

        사전 요청(preflight)

        사전 요청이란 실제 요청을 보내기 전, 해당 출처 리소스에 접근 권한이 있는지 브라우저와 서버가 서로 확인하기 위한 요청을 의미한다. 사전 요청은 일반적인 상황에서는 브라우저에서 자동으로 발생한다.

        흐름

1. 브라우저에서 서버로 예비 요청 전송

• 브라우저는 OPTIONS 메서드로 요청을 보낸다.
• Origin에 요청 출처를 기입한다.
• 지원하고자 하는 메서드는 Access-control-Request-Method 헤더에 기입한다.
• 사용자 정의 헤더를 설정했을 경우 Access-Control-Request-Headers 헤더에 기입한다.

2. 서버는 어떤 것을 허용하고 금지하는지 헤더에 담아서 응답한다.

• Access-Control-Allow-Origin 헤더에 허용 출처를 기입한다.
• Access-Control-Allow-Methods 헤더에 허용 메서드를 기입한다.
• Access-Control-Allow-Headers 헤더에 허용 헤더를 기입한다.

  캐시

  매번 사전 요청을 보내는 것은 본 요청만 보내는 단순 요청에 비해 네트워크 비용이 더 크다. 이를 해결 하기 위해 서버의 승인 하에 브라우저가 사전 요청을 생략할 수 있다. 서버는 Access-Control-Max-Age 헤더에 초단위로 캐시 사용 기한을 설정할 수 있다.

자격 증명 포함 요청

기본적으로 브라우저는 보안상의 이유로 교차 출처 요청에 자격 증명을 포함하지 않는다. 여기서 말하는 자격 증명은 쿠키 또는 Authorization 헤더를 의미한다. 이를 가능하게 하기 위해서 프론트와 서버 양측에서 CORS를 설정해야 한다.

프론트

Fetch API를 사용할 경우 credentials 옵션을 설정한다.

• same-origin(기본값): 같은 출처 사이에만 인증 정보를 담는다.
• include: 모든 요청에 인증 정보를 담는다.
• omit: 모든 요청에 인증 정보를 담지 않는다.

Axios를 사용할 경우 withCredentials 옵션을 설정한다.

• 기본값은 false이다.
• 자격 증명 요청을 위해서 값을 true로 설정한다.

  서버

1. 응답 헤더에 Access-Control-Allow-Credentials : true 를 추가한다.
2. 응답 헤더의 Access-Control-Allow-Origin 을 정확하게 설정한다. 즉, 와일드카드(*)를 사용하지 않는다.
3. 응답 헤더의 Access-Control-Allow-Methods의 값을 지정해야 할 경우 와일드카드 문자(*)는 사용할 수 없다.
4. 응답 헤더의 Access-Control-Allow-Headers의 값을 지정해야 할 경우 와일드카드 문자*)를 는 사용할 수 없다.

예외적으로 사전 요청은 credential 정보를 포함할 수 없다. 하지만 응답 헤더에는 Access-Control-Allow-Credentials : true 를 넣어줘야 한다.

레퍼런스

https://developer.mozilla.org/ko/docs/Web/HTTP/CORS https://developer.mozilla.org/ko/docs/Glossary/CORS https://jeonghwan-kim.github.io/2023/12/12/cors https://evan-moon.github.io/2020/05/21/about-cors/#sopsame-origin-policy https://velog.io/@garcon/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-CORS%EC%99%80-credentials https://junglast.com/blog/http-ajax-withcredential https://codingmoon.io/posts/interview-questions/describe-cors/ https://codingmoon.io/posts/interview-questions/describe-same-origin-policy/ https://velog.io/@cszzi1006/%EC%B0%A9%ED%95%98%EA%B3%A0-%EC%A2%8B%EC%9D%80-%EC%B9%9C%EA%B5%AC-CORS?utm_source=oneoneone

• 모든 자바스크립트 코드는 자바스크립트 런타임에서 실행된다.
• 자바스크립트 런타임은 자바스크립트 코드를 실행하는 데 필요한 모든 부품이 포함된 컨테이너이다. 자바스크립트 런타임 정리글
• 런타임의 핵심은 단연 자바스크립트 엔진이다. 이곳이 바로 코드가 실제로 실행되고 객체가 메모리에 저장되는 곳이다.
• Web API는 엔진이 사용할 수 있는 API로 자바스크립트 언어와는 구별된다.
• Callback queue는 이벤트에 부착된 모든 실행준비가 끝난 콜백함수를 갖고 있는 데이터 구조이다.
• Event loop
  • 엔진의 call stack이 비면 이벤트 루프가 콜백큐의 첫 번째 콜백함수부터 차례대로 하나씩 콜스택에 넣어 실행한다. 이러한 작업을 event loop tick이라 한다.
  • 이벤트 루프가 자바스크립트에서 비동기 작업을 가능하게 하는 핵심 부품이다.

비동기 코드가 백그라운드에서 실행되는 방법

자바스크립트는 single threaded 언어로 한 번에 한 가지 일만 할 수 있는데, 어떻게 비동기 코드를 실행할 수 있을까?

• DOM 관련된 모든 것은 자바스크립트 언어가 아니고 Web API의 일부이다.
• 즉 DOM 관련 비동기 작업은 자바스크립트 엔진의 call stack이 아니라 브라우저의 Web API 환경에서 실행된다. (DOM, Timer, AJAX, fetch 호출 등)
• 예를 들어 이미지 로딩은 call staack이 아니라 Web API 환경에서 비동기적으로 발생하고, load 이벤트가 끝나면 이벤트에 부착된 콜백함수가 콜백큐로 들어간다. 그리고 콜스택이 빌 경우, 이벤트 루프에 의해 순서에 맞게 콜스택으로 들어가 실행된다.
• 즉 load 이벤트에 부착된 콜백함수는 load 이벤트가 끝날 때까지 Web API 환경에 등록되어 이벤트가 끝나기를 기다리다가 이벤트가 끝나면 콜백큐에 들어간다.
• 콜백큐의 데이터 구조는 말 그대로 큐이기 때문에 FIFO(First In First Out) 원칙을 지킨다. 그래서 가장 먼저 들어간 콜백함수가 먼저 콜스택에 들어감으로써 실행순서를 보장한다.

즉 Web API 환경과 콜백큐, 이벤트 루프를 이용하여 비동기 코드가 single threaded 환경에서도 non-blocking하게 실행될 수 있다.

Timer 사용 관련

• Web API에서 setTimeout과 같은 timer API를 사용할 때 약간의 문제가 발생한다.
• 시간을 5초로 설정해두었을 때, 5초 이후에 콜백함수가 무조건 실행된다고 보장할 수 없기 때문이다.
• 타이머에 부착된 콜백함수는 5초 동안 Web API에서 대기하다가 콜백큐도 들어가는데, 콜백큐에 많은 수의 콜백함수가 대기하고 있을 경우 곧바로 실행하지 못하는 상황이 발생한다.
• 즉 콜백함수가 5초 이후에 실행된다는 것은 보장하지만, 정확히 5초가 끝나자마자 실행된다는 것은 보장할 수 없다.

그렇다면 다른 콜백함수보다 우선순위를 높일 수 있는 promise를 사용해보자.

promise callback

• promise 관련 콜백함수는 콜백큐에 들어가지 않는다. 대신 promise의 콜백이 들어가는 특별한 큐가 있다.
• 이를 Microtasks Queue라 한다.
• 이것이 특별한 이유는 콜백큐보다 높은 우선순위를 가지기 때문이다.
• 즉 이벤트 루프는 콜백큐에 있는 콜백함수를 실행하기 전에 마이크로태스크 큐에 콜백함수가 있는지 확인하고, 있으면 마이크로태스크 큐에 있는 콜백을 모두 실행하고 정규 콜백큐로 넘어간다.

즉 promise 콜백이 다른 콜백보다 우선순위가 높다.

예시

• 비동기 작업을 제외한 작업을 순서대로 실행하고, promise callbakc을 실행된 뒤에야 setTimeout이 실행된다.
• 0초 타이머라고 해서 0초 이후에 바로 실행된다는 것을 보장하지 않음을 증명한다.
• 만약 promise의 작업이 5초 이상 걸리는 작업이라면 0초 타이머라 해도 5초 이후에 실행된다.
• 때문에 타이머로 정밀한 작업을 하려면 promisify 해서 사용하는 것이 좋다.

참조

https://dkrnfls.tistory.com/362 https://www.udemy.com/course/the-complete-javascript-course/

AJAX는 자바스크립트를 이용하여 웹 서버와 브라우저가 비동기적으로 통신할 수 있는 개발 기법이다. AJAX 통신을 사용하면, 페이지의 새로고침 없이도 URL에서 데이터를 가져올 수 있어서 페이지의 일부분만 업데이트가 가능하다.

흐름

• 클라이언트는 데이터를 가지고 있는 웹서버에 AJAX로 HTTP 요청을 할 수 있다.
• 서버는 클라이언트가 요청한 데이터를 포함하는 응답을 보낸다.
• 클라이언트와 서버 사이의 작업은 모두 백그라운드에서 비동기적으로 발생한다.

XMLHttpRequest

• XMLHttpRequest는 옛날 AJAX 프로그래밍에 많이 사용되었다.

  const getCountry = (country) => {
  const request = new XMLHttpRequest();
  request.open('GET', `https://restcountries.eu/rest/v2/name/${country}`)
  request.send();
  
  // 비동기 통신 load가 모두 완료되면 실행
  request.addEventListener('load', function() {
    const [data] = JSON.parse(this.responseText)      
  })
  }
  getCountry('south korea')

  Callback Hell

  비동기 작업을 연속으로 실행하기 위해 콜백함수를 중첩하는 것을 의미한다.

• 코드가 지저분해진다.

• 이해하기 어렵기 때문에 유지 및 보수가 어렵다.

  setTimeout(() => {
  console.log('1 second passed');
  setTimeout(() => {
    console.log('2 seconds passed');
    setTimeout(() => {
      console.log('3 second passed');
      setTimeout(() => {
        console.log('4 second passed');
      }, 1000);
    }, 1000);
  }, 1000);
  }, 1000);

  ES6의 promise를 통해 callback hell을 해결할 수 있다.

Promise

promise란 비동기 작업의 미래의 결과가 담길 장소이다.

• 비동기 결과를 처리하기 위해 이벤트와 콜백함수에 의존할 필요가 없다. 그 결과값은 promise에 담길 것이기 때문.
• 비동기 작업의 순서를 위해 chain promises를 사용함으로써 콜백지옥을 피할 수 있다.

  Promise state

  비동기 작업은 시간이 지나변서 값이 변하는 특징이 있다 이를 표시하기 위해 여러 state와 cycle이 존재한다.
• pending(비동기 작업으로 결과의 값을 사용할 수 있기 전의 상태)
• settle(비동기 작업이 끝난 상태, 이제 상태값을 바꾸는 것은 불가능하다.)
  • fulfilled(성공)
  • rejected(실패)

    fetch 함수

• fetch 함수는 promise를 리턴한다.
• then 메서드로 promise를 처리하고 받은 값은 response 객체이다.
• response 객체에서 실제 데이터를 읽기 위해서 json 메서드를 사용한다.
• json 메서드는 또다시 promise를 리턴한다. 다시 then 메서드로 promise를 처리한다.

  const getCountryData = (country) => {
    fetch(`https://restcountries.com/v2/name/${country}`)
          .then(response => response.json());
          .then(data => console.log(data));
  }

  Error Handling

• catch 메서드로 에러를 캐치할 수 있고 catch 또한 promise를 리턴한다.
• finally 메서드는 성공하든 실패하든 무조건 실행하는 메서드이다.

  const getCountryData = (country) => {
    fetch(`https://restcountries.com/v2/name/${country}`)
          .then(response => response.json())
          .then(data => console.log(data))
        .catch(err => console.error(err))
        .finally(() => console.log('finish'));
  }

  Building Promise

• 생성자를 이용하여 promise를 직접 만들 수 있다.
• promise 생성자는 한 개의 인수를 받는다.
  • 그 인수는 promise 생성자 함수에서 바로 실행되는 실행자 함수이다.
  • 이 실행자 함수는 promise의 비동기 결과값을 생성한다.
• 실행자 함수는 두 개의 인수 resolve 함수와 reject 함수를 받는다.
  • 이 두 함수는 promise의 결과값을 처리하는 함수이며 response 객체를 리턴한다.
  • 조건을 충족하면 resolve 함수를 호출하고 state를 fufilled로 바꾼다.
  • 조건이 불충족하면 reject함수를 호출하고 state를 rejected로 바꾼다.

    예시

• 기존의 콜백함수 기반의 비동기 작업을 promise를 이용하여 캡슐화하고 추상화를 쉽게 할 수 있다.
• 즉 기존의 콜백함수를 promisify하여 우선순위를 더 높일 수 있다.
• 예를 들어 콜백함수를 인수로 받는 setTimeout과 같은 비동기작업을 promise를 리턴하는 함수로 캡슐화할 수 있다.
• 보통 fetch 처럼 promise를 리턴하는 함수 형태로 캡슐화를 한다.
• 이를 통해 콜백지옥을 해결할 수 있고 유지보수가 더 쉬워졌다.

  // 콜백지옥, 코드 이해하기 힘들다.
  setTimeout(() => {
    console.log('waited more 1 second');
        setTimeout(() => {
        console.log('waited more 2 second');
            setTimeout(() => {
            console.log('waited more 3 second');
                setTimeout(() => {
                console.log('waited more 4 second');
            }, 1000);
        }, 1000);
    }, 1000);
  }, 1000);
  

// promisify를 통해 콜백지옥 해결 const wait = (seconds) => { return new Promise((resolve) => { setTimeout(resolve, seconds*1000); }) }

wait(1) .then(() => { console.log('Wait for 1 seconds'); // promise를 리턴해서 then 메서드로 처리 return wait(1); }) .then(() => { console.log('waited for 2 seconds'); return wait(1); }) .then(() => { console.log('waited for 3 seconds'); return wait(1); })

### Async Await
- 함수에 async 키워드를 붙이면 그 함수는 백그라운드에서 실행되는 비동기 함수가 된다.
- async 함수는 promise를 리턴한다.
- async 함수 안에서 한 개 또는 그 이상의 await문을 사용할 수 있다.
    - await문은 promise의 상태가 fulfill될 때까지 실행을 멈춘다.
    - **중요한 것은 async 함수는 비동기 함수이기 때문에 백그라운드에서 실행되어 메인 쓰레드의 실제 코드 실행을 멈추지 않는다는 것이다.**
    - 즉 await이 자바스크립트 엔진의 call stack 실행을 막는다는 뜻이 아니다.
    - 이것이 async/await이 특별한 이유다!
    **async 함수이 실행 과정을 보면, await문 때문에 동기적 코드로 보인다. 하지만 함수 자체가 백그라운드에서 실행되는 비동기함수이다.**
    - 작업이 모두 끝나면 await문은 resolve된 값이 되고 그것을 변수에 저장할 수 있다.
    - 동기적 코드처럼 콜백함수 없이 promise의 결과값을 변수에 저장할 수 있기 때문에 코드가 더 쉽고 깔끔해졌다.
- **async/await은 새로운 것이 아니라 예전 then 메서드의 syntax sugar일 뿐이다. 즉 여전히 promise를 사용**한다.

#### Error Handling
- async/await은 try...catch를 통해 error handling을 한다.
- catch block은 try block에서 발생한 error에 권한을 갖는다.
```js
const test = async () => {
    try {
        const data = await getData();
        console.log(data);
    } catch(err) {
        console.error(err);
    }
}

Returning values from async functions

• 일반 promise를 사용하면 then 메서드를 통해 promise를 처리한다.
• async function은 promise를 리턴한다.
• async function과 then 메서드를 섞어 사용하면 불편하다.
• 이럴 경우에는 IIFE(Immediately Invoked Function Expression) 패턴을 사용해보자
• await을 사용하려면 async 함수가 필요하니 한 번 쓰고 사라지는 IIFE 패턴을 사용하면 좋다.

  (async funciton() {
     try {
         const data = await getData();
     } catch(err) {
        console.error(error);
    }
  })();

  Promise Combinator

  all method

• all method를 사용하면 실행순서가 상관없는 Promise를 parallel하게 처리할 수 있기 때문에 로딩 시간을 줄일 수 있다.
• all method는 promise 배열을 받아서 처리한 결과를 배열로 받는다.
• 하나라도 에러가 발생하면 에러가 발생한다.

  const getJSON = function (url) {
    return fetch(url).then(response => {
        return response.json();
    })
  }
  

// 3개의 promise를 동시에 처리하고 3개의 결과를 동시에 받는다. (async function () { const res = await Promise.all([ getJSON(https://restcountries.com/v2/name/italy), getJSON(https://restcountries.com/v2/name/egypt),
getJSON(https://restcountries.com/v2/name/mexico), ]) })()

#### race method
- promise 배열을 받아서 그 중에서 가장 먼저 settle이 된 promise의 결과값을 리턴한다.
- settle은 fulfill이라 reject와는 상관없다. 가장 먼저 settle이 된 promise만 리턴한다.
- 예를 들어서 사용자의 인터넷 연결이 안좋을 경우, 일정 시간이 지나면 reject를 리턴하는 promise를 실행하도록 한다.
```js
// 일정 시간이 지나면 error를 리턴
const timeout = function (sec) {
    return new Promise((resolve, reject) {
        setTimeout(() => {
            reject(new Error('Request took too long!'))'
        }, sec*1000);
    })
}

// 1초 이상 지나면 timeout promise가 실행
Promise.race([
    getJSON(`https://restcountries.com/v2/name/tanzania`),
    timeout(1),
])
  .then(res => console.log(res[0]))
  .catch(err => console.error(err));

allSettled

• promise 배열을 받아서 settle된 promise 결과를 리턴한다.
• all method는 어느 하나라도 reject가 되면 에러가 발생했지만, allSettled method는 결과 상관없이 settle되기만 하면 다 리턴한다.

  Promise.allSettled([
    Promise.resolve('success'),
    Promise.reject('fail'),
    Promise.resolve('success'),
  ]).then(res => console.log(res));

  any

• race method와 비슷하지만 any는 reject는 무시하고 가장 먼저 fulfill된 promise 하나를 리턴한다.
• 만약 모든 promise가 reject되어 리턴할 fulfiil promise가 없다면 error가 발생한다.

  // 가장 먼저 fulfill된 'success2'를 리턴받는다.
  Promise.any([
    Promise.reject('fail'),
    Promise.resolve('success2'),
    Promise.resolve('success1')
  ])
  .then(res => console.log(res))    
  .catch(err => console.error(err));

  참조

  https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Promise https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Statements/async_function https://poiemaweb.com/js-ajax https://poiemaweb.com/js-async https://www.udemy.com/course/the-complete-javascript-course/

생성자 함수와 class를 통해 프로그래밍적으로 객체를 생성할 수 있다.

생성자 함수

• 정규 함수와 같지만, 유일한 차이는 반드시 new 연산자를 사용해 호출한다는 것이다.
• 함수 이름의 첫글자는 대문자여야 한다.
• 화살표 함수는 고유의 this keyword가 없기 때문에 함수 선언식과 함수 표현식으로만 가능하다. this keyword 정리
• new 연산자로 생성자 함수를 호출하면 함수 기능뿐만 아니라 그 이상의 일을 한다.
  1. 생성자 함수 타입의 빈 객체를 즉시 생성한다.
  2. 함수가 호출되면, 함수 안의 this keyword가 새로 생성된 객체를 가리킨다. 생성자 함수 내에서 console.log(this) 로 확인해보면 빈 객체가 나온다. (this = {})
  3. 새로 생성된 객체가 생성자 함수의 프로토타입과 연결된다.(아래 예시에서는 객체가 Person.prototype과 연결된다.)
  4. 생성자 함수 내에서는 입력받은 값을 this keyword의 property로 설정한다.
  5. 생성자 함수는 this 객체를 리턴한다.
  6. 리턴된 객체가 바로 생성자 함수로부터 생성된 객체이다.

const Person = function(firstName, lastName) {
    console.log(this); // {}
    this.firstName = firstName;
      this.lastName = lastName;
}

const oort = new Person(cloud, oort);
// Person {firstName: 'cloud' , lastName: 'oort'}

// oort는 Person의 instance이다.
console.log(oort instanceof Person); // true

• 자바스크립트에는 전통적인 OOP의 클래스가 없다. 하지만 생성자 함수를 통해 만든 객체를 인스턴스라 한다.
• 생성자 함수 내에서 property를 받는 것은 좋지만, method를 정의하는 것은 매우 비효율적인 일이다. method를 가지고 있는 생성자 함수가 1000개의 인스턴스를 만들면 1000개의 함수 복사본을 만드는 것과 같기 때문에 코드 실행에 최악이다.

  이 문제를 해결하기 위해 prototypal inheritance를 이용한다.

  Prototypal Inheritance(프로토타입 상속)

• 프로토타입 상속은 method를 공유할 때 강점을 드러낸다.
• 특정 생성자 함수로 생성된 모든 객체는 생성자 함수의 prototype과 연결되어 있다.
• 그렇기 때문에 생성자 함수를 통해 생성된 객체는 생성자 함수의 prototype에 정의된 모든 property와 method에 접근할 수 있다.

  즉 생성자 함수의 prototype에 method를 정의해서, 생성자 함수와 연결된 객체가 생성자 함수의 prototype에 정의된 method를 끌어당겨 쓰는 것이 프로토타입 상속이다. 코드를 재사용하는 메커니즘이라 할 수 있다.

  예시

• 자바스크립트의 모든 함수(생성자 함수 포함)는 prototype이라는 propery를 자동으로 가지고 있다.
• 자바스크립트의 모든 객체는 __proto__라는 property를 갖고 있다.
• new 키워드로 생성자 함수를 생성할 때, 함수 내의 this 키워드가 생성자 함수의 프로토타입과 연결된다고 했고 그 this 키워드가 리턴된다고 했다.
• 리턴된 this 키워드가 바로 인스턴스이며 인스턴스의 __proto__ property와 생성자 함수의 prototype은 연결되었기 때문에 값이 같다.

  oort.__proto__은 항상 Person.prototype을 가리킨다.

• 즉 생성자 함수의 property에 method를 한 번만 정의해두면, 그 뒤로 생성된 객체는 생성자 함수의 prototype과 연결된 객체의 __proto__ property를 통해 method를 사용할 수 있다.

프로토타입 체인

• 생성자 함수로 생성한 객체가 자기 자신에 없는 property 또는 method를 사용할 때, 객체의 프로토타입 즉 생성자 함수의 프로토타입에서 property 또는 method를 찾는다.
• 생성자 함수의 프로토타입 또한 객체이기 때문에 프로토타입을 가지고 있다.
• 프로토타입으로 null을 가진 객체에 도달할 때까지 이 연결은 계속되며 이를 프로토타입 체인이라 한다.

주의할 점

• 생성자 함수의 prototype이 생성자 함수의 프로토타입은 아니라는 점을 유의해야 한다.
• 즉 생성자 함수의 prototype property는 생성자 함수의 프로토타입이 아니라 생성자 함수를 통해 생성된 모든 객체와 연결된 프로토타입이다.
• 그래서 생성자 함수로 만든 모든 인스턴스 객체의 __proto__ property는 생성자 함수의 prototype property와 같은 값을 가진다.
• 생성자 함수의 prototype의 constructor가 생성자 함수와 같다.
• 모든 객체는 프로토타입을 가지고 있기 때문에 객체 타입의 생성자 함수의 prototype도 프로토타입이 있는데, 바로 Object.prototype이다. 이 Object는 프로토타입 체인의 최상단이기 때문에 Object의 프로토타입은 null값을 가진다.

생성자 함수와 ES6 class

• 자바스크립트의 ES6 class는 전통적인 OOP의 클래스처럼 동작하지 않으며, 생성자 함수의 syntax sugar일 뿐이다.
• 내부적으로는 생성자 함수와 class 모두 동일하게 프로토타입 상속을 구현하지만 다른 프로그래밍 언어를 사용하는 사람들이 이해하기 쉽도록 class라는 synstax sugar로 표현한 것일 뿐이다. 그렇기 때문에 class는 단지 특별한 형식의 함수일 뿐이다.

차이

• 생성자 함수는 property를 정의할 때, 생성자 함수 안에 정의한다.
• class는 constructor 함수안에 정의한다.

  하지만 둘 다 method는 그 밖에서 정의한다. 이는 위에서 말한 프로토타입 상속과 방법이 일치한다.

• 즉 method를 생성자 함수에서 정의하는 것은 비효율적이기 때문에 => method를 생성자 함수의 prototype에 직접 정의하는 것과 => class를 사용할 때 method를 constructor 함수 바깥에서 정의하는 것은 프로토타입 상속을 이용하는 원리가 같지만 문법적으로만 다르게 보일 뿐인 syntax sugar이다.

  const Person = function(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;
  }
  // method를 생성자 함수의 prototype에 직접 정의하는 것
  Person.prototype.hello = function() {
    console.log('hi')
  }
  

const oort = new Person('cloud', 'oort');

// 위 방법과 아래 방법은 원리상 같지만 문법적으로만 다른 systax sugar임을 잘 보여준다. class ClassPerson { constructor(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } // class를 사용할 때 method를 constructor 함수 바깥에서 정의하는 것 hello() { console.log('hi') } }

const oort = new ClassPerson('cloud', 'oort');

## 정리
- 생성자 함수와 class는 모두 같은 원리로 객체를 생성한다.
- 생성자 함수는 method를 정의할 때 prototype 속성에 직접 정의해야 했지만, class의 경우 constructor 함수 바깥에만 정의하면 클래스의 prototype 속성에 자동으로 정의된다.
- 생성자 함수보다 클래스의 사용이 훨씬 편하지만, 그 이전에 생성자 함수, 프로토타입, 프로토타입 체인을 잘 이해하는 것이 필요하다.

> 즉 생성자 함수와 클래스 모두 사용해도 되지만 프로토타입에 대한 완전한 이해가 뒤따라야 한다.

## 참조

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Operators/new
https://poiemaweb.com/js-object-oriented-programming
https://www.udemy.com/course/the-complete-javascript-course/

• OOP(Object-Oriented Programming, 객체 지향 프로그래밍)란 객체 개념에 기반을 둔 프로그래밍 패러다임을 의미한다.
• 객체를 이용하면 property에 해당하는 데이터와 method에 해당하는 동작을 하나의 큰 블록(객체)에 담을 수 있다.
• 데이터와 동작이 담긴 객체는 독립적인 작은 앱처럼 동작하며 그 객체들끼리 상호작용한다.
• OOP는 더 유연하고 유지 보수하기 쉽도록 코드 조직화를 하기 위해 개발된 프로그래밍 패러다임이며 대규모 소프트웨어 엔지니어링 분야에서 광범위하게 사용되고 있다.
• 전통적인 OOP는 클래스를 사용하지만 자바스크립트는 클래스가 아닌 프로토타입을 사용한다.

  Class and Instance

  OOP에서는 객체 리터럴뿐만 아니라 객체를 프로그래밍적으로 생성할 방법이 필요하다. 전통적인 OOP에서는 클래스라는 것을 이용한다. (클래스 기반 OOP)

  Class

• 클래스는 보통 청사진(blue print)으로 묘사된다.
• 클래스는 단순 설계도이기 때문에 실체가 없다.(데이터와 데이터관련 동작이 있지만 데이터 자체는 아니다.)
• 클래스에 묘사된 청사진에 따라 새로운 객체를 만들 수 있다.
• JavaScript에는 실제 클래스를 지원하지 않는다.(클래스 문법이 있지만 전통적인 클래스와는 다르게 동작한다.)

Instance

• 인스턴스는 클래스라는 청사진을 보고 만든 실제 객체를 의미한다.
• 클래스를 통해 필요한만큼 많은 객체를 생성할 수 있다.(이 과정을 Instanciation이라 한다.)
• 같은 클래스(설계도)를 보고 만든 것이기 때문에 모두 같은 기능을 가지고 있으면서, 서로 다른 데이터를 가질 수 있다.

The 4 Fundatmental OOP Principles

좋은 클래스는 어떻게 디자인되어야 할까. 4가지 고려 사항이 있다.

Abstraction(추상화)

• 추상화란 사용자에게 필요한 정보만 제공하고 부가적인 것은 최소화하는 것을 의미한다. 프로그래밍을 할 때도 우리는 프로그래밍 언어의 사용자이기 때문에 언어를 완전히 이해하거나 직접 구현하지 않아도 추상화를 통해 언어가 제공하는 기능을 간단히 사용할 수 있다.

  Encapsulation(캡슐화)

• 일부 property와 method를 외부에서 접근하지 못하도록 막는 것을 의미한다.
• 외부 코드가 내부의 데이터를 직접 조작할 수 있을 경우 많은 종류의 버그가 발생할 수 있다. 그래서 항상 객체 내의 일부 property와 method를 캡슐화하고 핵심적인 method만 공개한다.
• 공개된 method는 public API라고도 부른다.

  Inheritance(상속)

• 유사한 두 클래스가 있을 때, 중복된 코드를 작성하지 않고 하나의 클래스가 다른 클래스를 상속할 수 있게 한다.
• parent class와 child class가 있고, child class가 부모로부터 상속받게 될 경우 parent class의 모든 property와 method를 물려받는다.
• 상속을 통해 두 클래스 사이에 계층구조가 형성되고, 공통 로직을 재사용할 수 있다.

  Polymorphism(다형성)

• 그리스어에서 유래, '다수의 형태'라는 뜻이다.
• 간단히 말해서 parent class에서 물려받은 method를 바꿔야 하는 경우 원하는대로 커스텀할 수 있다.

OOP in JavaScript

OOP가 Javascript에서 동작하는 원리

자바스크립트에서 OOP는 전통적인 클래스가 아닌 프로토타입을 이용한다.

Prototypal Inheritance(프로토타입 상속) 이용.

• 자바스크립트의 모든 객체는 특정 프로토타입 객체에 연결되어 있다.(즉 모든 객체는 프로토타입이 있다.)
• 프로토타입 객체는 프로토타입에 연결된 모든 객체가 접근하고 사용할 수 있는 property와 method를 가지고 있다.
• 프로토타입 상속은 특정 프로토타입 객체에 연결된 모든 객체는 그 프로토타입에서 정의된 property와 method를 사용할 수 있음을 의미한다.
• 예를 들어 Array.prototype은 자바스크립트에서 만든 모든 배열의 프로토타입 객체이다. 즉 모든 배열은 Array.prototype에 있는 모든 method를 상속받는다.
• 우리가 이때까지 forEach, map과 같은 method를 정의하지 않아도 배열의 method로 사용할 수 있는 동작 원리이다.
• 배열을 선언하고 콘솔로 찍어보면 배열이 우리가 사용했던 methode들이 포함된 prototype에 연결된 것을 볼 수 있다. 저 prototype이 바로 Array.prototype이다.

클래스 상속과 프로토타입 상속의 차이

• 클래스 상속은 클래스가 다른 클래스로부터 상속받는 것을 의미한다.
• 프로토타입 상속은 객체가 자신과 연결된 프로토타입의 property와 method를 사용할 수 있음을 의미한다.
• 전통적인 클래스에서는 method가 인스턴스로 복사되지만, 프로로타입 상속은 프로토타입 객체와 연결된 객체에 method를 위임한다.

  객체 생성 방법

  자바스크립트에는 클래스 개념이 없기 때문에 별도의 객체 생성 방법이 존재한다.
• 객체 리터럴
• 생성자 함수 생성자 함수 정리글
  • 생성자 함수와 new키워드를 통해 인스턴스를 생성할 수 있다.
  • 이때 생성자 함수는 클래스이자 생성자(constructor)의 역할을 한다.
• ES6 Class Class 정리글
  • ES6에 도입된 class는 자바스크립트에서 OOP를 구현하는 현대적인 방법이다.
  • 주의할 점은 도입된 class문법은 우리가 알고 있던 전통적인 class가 아닌 생성자 함수의 syntax sugar라는 사실이다. 생긴 모습만 class이고 실제 동작은 생성자 함수와 같으며 프로토타입 상속을 이용한다.
• Object.create()
  • 객체를 프로토타입 객체에 연결하는 가장 쉽고 직관적인 방법이다.

참고

https://developer.mozilla.org/ko/docs/Learn/JavaScript/Objects/Object-oriented_programming https://poiemaweb.com/js-object-oriented-programming https://www.udemy.com/course/the-complete-javascript-course/

• secureBooking 함수는 로컬 스코프의 passengerCount 변수를 업데이트하는 함수를 리턴한다.
• 전역변수 booker는 secureBooking 함수의 리턴값으로 passengerCount 변수를 업데이트하는 함수를 받는다.
• 그리고 booker 실행하면 결과가 어떻게 될까.

• passengerCount 변수가 업데이트되고 console.log 가 실행된다.

  이미 실행이 끝난 secureBooking 의 함수 내에 선언된 passengerCount 변수를 전역 스코프의booker 함수가 사용할 수 있었던 이유가 무엇일까.

• booker 함수는 전역 스코프에 존재하는 함수이다.

• secureBooking 함수는 실행이 끝났기 때문에 execution context의 변수 환경도 완전히 사라졌다.

• 하지만 booker 함수는 당시 존재했던 passengerCount 변수에 계속 접근할 수 있다.

• booker 함수는 전역 스코프이기 때문에 scope chain으로도 passengerCount 변수에는 접근할 수 없다.

이를 가능하게 한 것은 바로 closure이다.

Closure 동작 원리

• booker 에 할당된 함수는 call stack에서 사라진 secureBooking 함수의 execution context에서 선언되었다.
• 하지만 booker 함수는 자신이 선언된 함수의 execution context가 사라져도 그 execution context의 변수 환경에 항상 접근할 수 있다.
• 이러한 연결고리를 closure라 한다.
• 즉 booker 함수는 closure를 이용하여 자신이 선언된 곳인 secureBooking 함수의 변수 환경에 항상 접근할 수 있다.

다시 정리하면, 함수는 함수 자신의 변수 환경과 자신이 선언된 함수의 변수 환경에 접근할 수 있고 이러한 연결고리를 closure라 한다.

• 더 쉽게 말하면 부모 함수가 사라져도, 부모 함수의 모든 변수에 접근할 수 있게 해주는 것이 closure이다.
• 이러한 closure는 부모 함수의 변수 환경에 접근하는 자식 함수가 존재하는 경우 계속 유지된다. 이때 변수의 복사본이 아니라 실제 변수에 접근한다는 것에 주의하여야 한다.
• 자바스크립트 엔진은 로컬 스코프(자신의 변수 환경) -> closure(자신이 선언된 함수의 변수 환경) -> scope chain 순으로 변수를 탐색한다.

closure 관찰

• closure 관련 작업은 자바스크립트가 내부적으로 처리하기 때문에 우리는 수동으로 closure 관련 작업을 할 수 없다.
• closure는 우리가 접근할 수 있는 객체가 아니고, 명시적으로 closure에 접근할 방법 또한 없다.
• 즉 closure는 실재하는 것이 아니다. 함수의 내부 속성일 뿐이다.

하지만 콘솔을 통해 함수 내부의 closure 속성을 직접 볼 수 있다.

• scopes는 booker의 변수 환경을 나타내는데, closure가 우선인 것을 볼 수 있다.
• closure를 통해 함수가 선언된 execution context가 사라져도 변수 환경을 보존할 수 있다.
• [[]] 로 표시된 것은 내부 속성이기 때문에 코드로 접근할 수 없다는 의미이다.

한 가지 의문

closure는 자신이 선언된 부모 함수의 변수 환경에 항상 접근할 수 있다고 하는데, 부모 함수의 부모 함수, 즉 조부모 함수의 변수 환경에는 어떤 방식으로 접근될까

결과는 다음과 같다

• 조부모 함수에서 선언된 변수 i 와 부모 함수에서 선언된 변수 j 에 정상적으로 접근할 수 있었다.
• 또한 closure는 각각 어느 함수의 변수환경인지 명시적으로 알려주고 있으며, 부모 함수와 조부모 함수 순으로 나열되어 있다. 이를 통해 closure가 하나가 아니라는 사실을 알 수 있었다.
• closure는 함수마다 하나씩 존재*했다.
• 즉 위 상황에서 자바스크립트 엔진이 변수를 찾는 과정이 다음과 같다. 로컬 스코프(자신의 변수 환경) -> closure(부모 함수의 변수 환경) -> closure(조부모 함수의 변수 환경) -> scope chain 순이다.

추가 예시

예시 (1)

• 꼭 함수를 리턴하지 않아도 된다.
• 함수가 변수 자체일때도 closure가 발생한다.
• 또한 변수가 재할당되면 closure 또한 변한다.

  let f;
  const g = () => {
  const a = 4;
  f = function() {
      console.log(a*5)
  }
  }
  

const h = () => { const b = 7; f = function() { console.log(b*2); } }

g(); // 함수 할당 f(); // 20

h(); // 함수 재할당 f(); // 14

### 예시 (2)
- 타이머 또한 함수를 리턴하지 않아도 closure를 볼 수 있는 좋은 예시이다.
- 파라미터 또한 로컬 변수인점을 기억해야 한다.
- 함수 실행이 끝나고 execution context가 사라져도 함수는 자신이 선언된 함수의 변수 환경을 기억하기 때문에 정상 동작하는 것을 알 수 있다.
```js
const boardPassengers = (n, wait) => {
  const perGroup = n / 3;
  setTimeOut(() => {
      console.log(`We are now boarding all ${n} passengers`);
    console.log(`There are 3 groups. each with ${perGroup} 
  }, wait * 1000);
};

boardPassengers(180, 3);

예시 (3)

• IIFE 패턴에서의 이벤트 콜백함수 예시에서도 closure를 볼 수 있다.

• 콜백이 실행될 때쯤이면 IIFE 즉, 즉시 호출된 함수 식은 실행된 후 사라진다.

• 하지만 콜백함수는 자신이 생성된 장소에서 생성된 변수에 여전히 접근할 수 있다.

  (function() {
  const header = document.querySelector('h1');
  header.style.color = 'red';
  
  // 콜백함수는 여전히 header 변수에 접근할 수 있다.
  document.body.addEventListener('click', () => {
      header.style.color = 'blue';
  })
  })()

참조

https://developer.mozilla.org/ko/docs/Web/JavaScript/Closures https://poiemaweb.com/js-closure https://www.udemy.com/course/the-complete-javascript-course/

IIFE는 즉시 실행 함수 표현을 의미한다. 즉시 실행하고 바로 사라진다.

사용

(function() {
    console.log('IIFE');
})()

• 이름 없는 함수 식을 괄호로 래핑하면 함수식(function statement)이 아닌 표현(expression)으로 속일 수 있다.
• 그리고 다른 함수들과 마찬가지로 뒤에 ()를 붙여 호출한다.
• 이는 자바스크립트만의 특징이 아니고 개발자들이 생각해낸 패턴에 가깝다.

등장 이유

• ES6 이전에는 전역 스코프와 함수 스코프만 존재했다. 그래서 if나 for문과 같이 블록(중괄호)안에서 선언된 변수는 외부에서 마음껏 사용할 수 있었다.
• 개발 도중, 블록 안에서 선언한 변수를 외부에서 사용하지 못하게 하고 싶었다.
• 블록 스코프를 인위적으로 만들어내기 위해 IIFE와 같은 패턴이 등장했다.
• 스코프를 만들기 위해 함수를 선언하여 호출했고, 스코프만을 위한 함수였기 때문에 한 번 호출 이후 바로 사라지게 만들었다.
• 하지만 ES6 이후 블록 스코프가 등장했기 때문에 모던 자바스크립트에서는 위와 같은 용도로 IIFE 패턴을 사용하지 않는다.
• 그래도 한 번만 사용하는 함수를 만들 때는 유용하다.
  • 전역 변수 제한
  • 비동기 함수 실행(top-level await 구현 가능)

    참조

    https://developer.mozilla.org/ko/docs/Glossary/IIFE https://www.udemy.com/course/the-complete-javascript-course/

• 함수는 객체의 한 종류이기 때문에 메서드를 가질 수 있다. 일급시민과 고차원함수 정리
• 정규 함수(화살표 함수 제외)에서 this 키워드를 사용하게 되면 strict mode에 한에서 this 값은 undefined이다.
• this 키워드는 호출될 때 값이 정해지는 동적인 값이다. this 키워드 정리
• 여기서 this 키워드를 수동적으로 정의할 수 있는 방법이 있다. 함수에 부착된 메서드인 Call, Apply and Bind method를 이용하면 된다.

Call method

const a = {
  name: 'oort',
  booking(one, two) {
    // 여기서 this는 a를 가리킨다.
      console.log(this.name + `${one} ${two}`
  }
}

// book 변수에 a의 booking 메서드를 재할당
const book = a.booking;

// 여기서 this는 undefined이다.
book(1, 2)

// call 메서드의 첫번째 인수는 this 키워드가 가졌으면 하는 값이다.
// 그리고 뒤에 메서드에 필요한 인수들을 입력한다.
book.call(a, 1, 2);
// 정상동작 => oort12

• 위 예시를 보면 book 이라는 변수에 a 의 메서드인 booking 을 재할당했다.
• 그리고 book 함수를 호출하면 book 의 소유주는 없기 때문에 book에서 사용한 this 키워드는 undefined 가 된다.
• this 키워드를 수동으로 정의해주기 위해 call method를 사용한다.
  • 예시를 보면 book 함수를 직접 호출한 것이 아니다.
    • call 메서드가 a 라는 키워드로 book 함수를 호출한 것이다.
• 모던 자바스크립트에서는 apply 보다는 call 을 사용한다.

  Apply method

• call method와 동작이 같다.
• 다른 점은 뒤에 올 인수를 배열로 받는다는 것이다.

  const a = {
  name: 'oort',
  booking(one, two) {
    // 여기서 this는 a를 가리킨다.
      console.log(this.name + `${one} ${two}`
  }
  }
  const book = a.booking;
  

// 여기서 this는 undefined이다. book(1, 2)

const argu = [1, 2]; book.call(a, argu);

## Bind method
```js
const a = {
    name: 'oort',
    book(num, value) {
          // this === a
        console.log(`${num} ${this.name} ${value}`)
    }
}
const b = {
    name: 'www',
}

// this === undefined
const book = a.book

// this === b
const bookB = book.bind(b)
// 첫번째 키워드는 call과 마찬가지로 this에 할당할 값
// 그 뒤에 인수는 입력이 자유롭다.
// 전부 넣어도 되고, 나중에 넣어도 되고, 일부만 넣어줘도 된다.

// 일부 인수 미리 지정해줄 경우
const bookB = book.bind(b, 12)
bookB('a')

• bind method 또한 call method와 마찬가지로 this 키워드를 수동으로 설정한다.

• 차이점은 call은 즉시 함수를 호출하지만 bind는 즉시 그 함수를 호출하지 않는다는 것이다.

• 대신 원하는 this 키워드가 바인딩된 새 함수를 리턴한다.

  bind 함수에서 인수를 미리 지정해줄 수도 있다. 나머지 인수는 호출할 때 넣어주면 된다.(partial application)

• 이 특성을 활용하여 인수가 미리 지정된 새로운 함수를 만들 때 사용할 수 있다.

  • 아래 예시처럼 this 키워드가 필요없을 때는 null을 넣는 것이 관습이다.

  • 인수의 순서가 중요하다.

  • default parameter와 결과가 비슷해보이지만, bind는 범용 함수에 근거해서 인수를 미리 지정해놓은 새로운 함수를 리턴하는 것이기 때문에 다르다.

    // 범용 함수
    const addTex = (rate, value) => value + rate*value
    
    // 범용함수에 근거해서 인수를 미리 지정해준 새로운 함수
    const addVAT = addTax.bind(null, 0.23);

    외부 객체의 메서드를 이벤트리스너의 콜백함수로 사용하는 경우 유용하다.

• 이벤트리스너의 콜백함수에서 this를 사용할 경우, this는 해당 DOM element를 가리킨다.

  • 때문에 외부 객체의 메서드를 콜백함수로 사용하고자 할 때, this 값을 수동으로 설정할 필요가 있다. => 인수로 입력한 값을 this 키워드로 가지는 함수를 리턴하는 bind 메서드를 사용한다.

    document.querySelector('.buy').addEventListener('click', a.book.bind(b))

    이벤트리스너의 콜백함수에 인수를 추가할 때 유용하다.

• 이벤트리스너의 콜백함수는 실행하면 안되고 함수 자체를 넘겨줘야 한다.

  • 그렇기 때문에 기존 파라미터인 event를 제외하면 추가 인수를 넘기는 것은 불가능하다.

• 하지만 bind 메서드를 이용하여 추가하고 싶은 인수를 this에 할당하는 패턴으로 구현할 수 있다.

  const nav = document.querySelector('.nav')
   // this를 사용하고 싶으면 화살표 함수가 아닌 정규 함수를 사용해야 한다.
   const clickHandler = function(event) {
      console.log(event.currentTarget) // nav element
  
      // 추가하고 싶은 인수를 bind 메서드를 이용하여 this에 할당하여 사용한다. 
    console.log(this) // 20
   }
   // 추가하고 싶은 인수를 this에 할당 => this === 20
   nav.addEventListenr('click', clickHandler.bind(20)                              

  참조

  https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Function/call https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Function/apply https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Function/bind https://www.udemy.com/course/the-complete-javascript-course/