데코레이터는 클래스, 필드, 메소드에 대한 처리를 유연하게 돕는 기능입니다. 제안서에 따르면 데코레이터는 기능 추가, 변경, 접근 등의 처리에 대해 일일이 코드를 수정하는 대신 메타 정보를 입맛에 맞게 추가, 조합해서 구현 하려는 목적이 큽니다. 이는 SOLID 원칙의 SRP와 OCP에도 좋습니다.

단일 책임 원칙 (Single Responsibility Principle, SRP)
 객체는 책임을 한 가지만 가져야 합니다. 한 객체가 여러 책임을 가지면 코드는 번잡해집니다.

개방 폐쇄 원칙 (Open-Closed Principle, OCP)
 객체는 확장에 대해선 개방적이되, 수정에는 폐쇄적이어야 합니다.
즉, 새 기능을 도입할 땐 객체 코드를 수정하지 말고 새 코드를 추가합니다.

유연성과 확장성

 서비스에서 객체들은 처음엔 간단한 기능만 지원합니다. 그러다 서비스가 커질수록 기능은 많아지고 경우의 수는 여러 갈래로 늘어납니다. 예를 들면 옛날 커피 자판기는 전부 메뉴, 맛, 양이 같았습니다. 하지만 오늘날엔 어떤가요? 아래 그림으로 감당이 가능한가요?

문제 1. 메뉴가 많아졌습니다.

대응: 많은 가게가 고급 원두 머신을 사용합니다. 메소드를 대폭 업데이트해야겠군요.

문제 2. 브랜드와 머신 종류가 많습니다.

대응: 인터페이스로 틀을 만들고 각 객체마다 구현을 맡깁시다.

문제 3. 브랜드마다 레시피가 다릅니다.

 카페라떼를 생각해봅시다. 어디는 시나몬, 혹은 시럽을 넣고 들어가는 원두의 종류, 양, 우유의 온도, 양이 각자 다릅니다. 그러나 다들 원두를 분쇄하고 에스프레소를 만들고 데운 우유를 사용합니다. 재사용성이 엿보이는 로직은 데코레이터로 분리할 수 있습니다.

 아까 말했듯이 데코레이터는 내부 로직은 수정하지 않으면서 추가 정보를 덧붙이고 조합하는 형식으로 여러 형태를 구현합니다.

class StarbucksMachine extends VarietyMachine {
  coffeeBeans = 1000; // 머신에 있는 원두의 양
  water = 1000; // 머신에 있는 물의 양
  desiredMilkTemperature = 75; // 우유를 데우는 온도

  @grindCoffeeBeans(20) // 원두를 20g 분쇄합니다.
  @extractEspresso(50) // 에스프레소를 50ml 추출합니다.
  @heatMilk(140) // 우유를 140ml 데웁니다.
  caffelatte() {
    console.log(`Starbucks만의 고유 재료와 비법 레시피를 이용한 카페라떼를 만듭니다...`);
    console.log(`Starbucks 카페라떼가 나왔습니다.`);
  }

  @grindCoffeeBeans(20) 
  @extractEspresso(40) 
  @heatMilk(80) 
  cappuccino() {
    console.log(`Starbucks만의 고유 재료와 비법 레시피를 이용한 카푸치노를 만듭니다...`);
    console.log(`Starbucks 카푸치노가 나왔습니다.`);
  }
}

function grindCoffeeBeans(beanGrams: number) {
  return <Class extends VarietyMachine>(
    target: Function,
    context: ClassMethodDecoratorContext
  ) =>
    function <Args extends any[]>(this: Class, ...args: Args) {
      this.coffeeBeans -= beanGrams;
      console.log(`원두를 ${beanGrams}g 분쇄합니다.`);
      const originReturn = target.apply(this, args);
      console.log(`머신에 원두가 ${this.coffeeBeans}g 남아있습니다.`);
      return originReturn;
    };
}

function extractEspresso(water: number) {
  return <Class extends VarietyMachine>(
    target: Function,
    context: ClassMethodDecoratorContext
  ) =>
    function <Args extends any[]>(this: Class, ...args: Args) {
      this.water -= water;
      console.log(`물을 ${water}ml 사용해서 에스프레소를 추출합니다...`);
      target.apply(this, args);
      console.log(`머신에 물이 ${this.water}ml 남아있습니다.`);
    };
}

function heatMilk(milk: number) {
  return function <Class extends VarietyMachine>(
    target: Function,
    context: ClassMethodDecoratorContext
  ) {
    return function <Args extends any[]>(this: Class, ...args: Args) {
      while (this.milkTemperature < this.desiredMilkTemperature) {
        this.milkTemperature++;
      }
      console.log(`${milk}ml의 우유를 ${this.milkTemperature}도로 데웠습니다.`);
      target.apply(this, args);
    };
  };
}

 우유를 사용하는 메뉴에만 heatMilk를 선택적으로 쓰고 에스프레소, 우유 양도 자유롭게 조정됩니다. 필요한 때에 필요한 것만 가져와 base를 꾸미고(decorate) 어느 브랜드, 어느 머신에도 유연하게 대처할 준비가 됐습니다. 어떤가요?

클래스 데코레이터

 아래와 같이 클래스 자체를 데코레이트할 수도 있습니다.

function withEmploymentDate<Constructor extends { new (...args: any[]): {} }>(
  baseClass: Constructor,
  context: ClassDecoratorContext
) {
  return class extends baseClass {
    employmentDate = new Date().toISOString();
    constructor(...args: any[]) {
      super(...args);
      console.log(`${baseClass.name}에 입사일 속성을 추가했습니다.`);
    }
  };
}

@withEmploymentDate
class Employee {
  calcPay() {}
}

const employee = new Employee(); // Employee에 입사일 속성을 추가했습니다.

accessor 데코레이터

 accessor는 TS 4.9에 추가된 문법으로 내부적으로 해당 속성을 은폐하고 getter, setter로 조회하는 접두사입니다.

// 개발자가 작성한 코드
class Person {
    accessor name: string;
}

// 실제로 작동하는 코드
class Person {
    #__name: string;
    get name() {
        return this.#__name;
    }
    set name(value: string) {
        this.#__name = name;
    }
}

 getter, setter는 그 책임에만 충실해야 합니다. 그렇다면 이런 민감한 속성의 변화는 어떻게 관찰하면 좋을까요? 데코레이터가 이를 돕습니다.

class User {
  @watchChange accessor nickname: string = "John Doe";
  @watchChange accessor password: string = "1234";
}

const user = new User();
user.nickname = "ilovecoffee";
user.password = "22231";

function watchChange<This, Value>(
  accessor: {
    get: (this: This) => Value;
    set: (this: This, value: Value) => void;
  },
  { name }: ClassAccessorDecoratorContext<This, Value>
) {
  return {
    get: function (this: This) {
      return accessor.get.call(this);
    },
    set: function (this: This, value: Value) {
      console.log(
        `${String(name)}이 ${accessor.get.call(
          this
        )}에서 ${value}로 변경되었습니다.`
      );
      accessor.set.call(this, value);
    },
  };
}

 성능 측정이 필요한 메소드가 많으면 측정용 데코레이터를 따로 두는 것도 괜찮을 듯합니다.

function measurePerformance<Class>(
  target: Function,
  { name }: ClassMethodDecoratorContext
) {
  return function <Args extends any[]>(this: Class, ...args: Args) {
    const t0 = performance.now();
    target.apply(this, args);
    const t1 = performance.now();
    console.log(`${String(name)}은 ${t1 - t0}ms가 걸렸습니다.`);
  };
}

class HeavyWorker {
  @measurePerformance
  veryImportantWork() {
    let currentValue = Math.random();
    for (let i = 0; i < 1000000; i++) {
      currentValue += i;
    }
  }
}

const worker = new HeavyWorker();
worker.veryImportantWork();

마치며

 데코레이터는 더 다양하고 복잡한 문제에도 적용하기 좋습니다. 많이 연습해서 익숙해지도록 합시다.

참조

• 안택수(2023.10). AOP in TypeScript. NAVER D2
• Concise Developer(2023.08). TypeScript 5 decorators - full course

satisfies를 이용한 안전한 타입 캐스팅을 이해하고 연습합니다.

 개발자는 빠른 오류 검사를 위해 타입스크립트를 사용합니다. 그런데, 타입은 항상 편하기만 했나요? 우리를 피곤하게 만든 적은 없었나요? 아래 상황을 봅시다.

let bool = false; // ❓ boolean으로 추론하는 것 같지만...

function changeBool() {
  const someCondition = true;
  if (someCondition) bool = true;
}

changeBool();

bool === true; // ❌ ts2367 Error: false와 true는 타입이 다릅니다. 서로 다른 타입끼리 비교하지 마세요.
bool = false as boolean; // 😞 as로 단언
bool === true; // 😓 통과

 위와 같은 상황은 조금 특수한가요? 다음 같은 상황도 생각해봅시다.

 "기간 한정 행사 웹사이트를 만들어주세요. 각 요소마다 마우스 클릭 시에 고유한 알림 메시지를 띄워주세요."

 HTML 엘리먼트는 많은 종류가 있습니다. 모든 요소에 마우스 클릭 이벤트를 등록하려면 아래와 같이 작성해야 합니다.

function onClick1(event: MouseEvent<HTMLAnchorElement>) { printMessage(event...) }
function onClick2(event: MouseEvent<HTMLBodyElement>) { printMessage(event...) }
function onClick3(event: MouseEvent<HTMLButtonElement>) { printMessage(event...) }
function onClick4(event: MouseEvent<HTMLInputElement>) { printMessage(event...) }

 하는 내용은 똑같은데 이벤트 타입은 매번 일일이 지정합니다. 고통스러운 일이네요! (다행히도 위의 코드는 extends와 제네릭으로 해결할 수 있습니다.)
 타입이 최대한 엄격한 게 좋지만은 않다는 사실을 환기했으니 본론으로 들어가봅시다. satisfies의 등장 전후로 무엇이 변했을까요?

safe-downcasting

 타이핑은 엄격해서 귀찮음을 유발하기도 합니다. 아래 코드를 보죠.

type Colors = "red" | "green" | "blue";
type RGB = [red: number, green: number, blue: number];

const palette1: Record<Colors, string | RGB> = {
  red: [255, 0, 0],
  green: "#00ff00",
  blue: [0, 0, 255],
};

palette1.red.map(0); // ❌ Error(ts2339): 타입이 배열로 확정되지 않음. (string 가능성)
palette1.green.toUpperCase(); // ❌ Error(ts2339): 타입이 string으로 확정되지 않음 (배열 가능성)

 타이핑에 따르면 모든 key의 값은 튜플 | string 타입입니다. 따라서 해당 값에서 배열이나 string 메소드를 쓰려면 타입을 좁혀야 합니다.

if(typeof palette1.green === "string") { 
  palette1.green.toUpperCase();
 }

 개발자 입장에선 값이 무슨 타입인지 뻔히 보이기 때문에 타입을 좁히기 귀찮습니다!

const palette2 = {
  red: [255, 0, 0],
  green: "#00ff00",
  blue: [0, 0, 255],
} satisfies Record<Colors, string | RGB>;

palette2.green.toUpperCase(); // ✅ OK: green은 string 타입으로 다운캐스팅 됐으므로 가능.
palette2.red = "#00ff00"; // ❌ Error(ts2322): red은 [number, number, number] 타입으로 다운캐스팅돼서 불가능.

 satisfies는 명시한 타입을 만족할 경우 자동으로 다운 캐스팅을 합니다. 즉, 타입을 좁힙니다. red는 이미 튜플 타입으로 좁혀졌기 때문에 string 재할당이 불가능합니다.

실재하는 속성에만 접근

 객체의 key 타입을 엄격하게 설정하지 않으면 잉여 속성이 허용됩니다. 아래 코드를 보죠.

type Config = Record<string, string>;

const config: Config = {
  name: "hamelln",
  version: "1.0",
  service: "portfolio",
};

config.name223 = "asd"; // 😰 통과. 타입 명세에 따르면 문제는 없다...이래도 되나?

 name223 속성 추가는 제가 원하는 동작이 아닙니다. 그러나 모든 케이스를 완벽하게 대비하기는 현실적으로 어렵습니다. 어떻게 하면 좋을까요?

type Config = Record<string, string>;

const config2 = {
  name: "hamelln",
  version: "1.0",
  service: "portfolio",
} satisfies Config;

config2.name223 = "asd"; // ❌ Error(ts2551): 없는 속성에 접근 금지.

부분적 타이핑

 타이핑은 만능이 아닙니다. 타이핑으로 해결이 쉽지 않은 케이스 중 하나는 부분적 타입입니다. 아래 코드를 보죠.

interface Data {
  a: "A" | "B" | "C";
  b: number;
  c: string;
  d: string[];
}

const baseData1: Partial<Data> = {
  a: "A",
  b: 1,
};

const data1: Data = {
  ...baseData1, // ❌ Error(ts2322): 입력된 값이 타입과 정확히 부합하지 않는다. (baseTata의 타입은 옵셔널)
  c: "foo",
  d: ["asd"],
};

 baseData는 a속성과 b속성이 있지만 타입스크립트는 baseData를 Partial 타입으로만 보기 때문에 값의 유무는 확인하지 않습니다.
 baseData의 타입을 Pick<Data, "a" | "b">로 지정하면 해결할 수 있습니다. 하지만 Data 타입이 변경되면 같이 변경해야 하는 번거로움이 있네요. satisfies는 이 문제를 좀 더 간결하게 해결합니다!

const baseData2 = {
  a: "A",
  b: 1,
} satisfies Partial<Data>;

const data2: Data = {
  ...baseData2, // ✅ 통과! baseData: { a: "A"; b: number; }
  c: "foo",
  d: ["asd"],
};

 위에서 봤듯이 satisfies는 타입이 안전하다고 확인하면 downcasting해서 타입을 좁힙니다. 즉, baseData2는 Partial가 아니라 { a: "A"; b: number; } 타입으로 변환됩니다. 따라서 data2의 타입 체크가 통과됩니다.

안전한 타입 단언

 as는 TypeScript 사용자들이 기피하지만, 어쩔 수 없이 사용할 상황이 발생할 수도 있습니다. 알다시피 개발에 있어 '절대'라는 건 없으니까요.
 외부에서 가져온 데이터가 User 타입인지 점검하고, User 타입으로서 return하려면 어떻게 해야 할까요?
 보통은 is User를 사용하는 게 안전합니다. 하지만 그마저도 여의치 않으면 as User라고 단언해서 보내야할 때가 있습니다.

interface User {
  name: string;
  location: string;
}

const user1 = {
  name: "태현",
  location: "경기",
} as User;

// ...

return user1;

 하지만 as의 고질적인 문제는 '타입 점검을 전혀 안 한다는 것'입니다. 아래 케이스는 심각해지겠죠.

// ❓ 어느 날 User에 major 속성이 추가됐다면?
interface User {
  name: string;
  location: string;
  major: "frontend" | "backend"; // 속성 추가.
}

// ❗ 에러가 날 상황인데 as 때문에 그냥 통과시켜버린다!
const user2 = {
  name: "태현",
  location: "경기",
} as User;

 satisfies는 타입 체크, as는 타입 단언을 합니다. 둘을 섞으면 어떻게 될까요? 타입 체크 ➭ 타입 단언을 합니다!

const user = {
  name: "태현",
  location: "경기",
} satisfies User as User; // ❌ Error(ts1360): major 속성을 입력하시오.

 타입 명시와 일치하는지 확인한 다음에 단언하기 때문에 안전하게 타입을 단언할 수 있습니다!

타입 업캐스팅

 여태까지 satisfies가 타입 다운 캐스팅만 했는데요. 타입 업캐스팅으로 사용할 수도 있습니다.

interface Gamer {
  id: string;
  name: string;
  nickname: string;
  joinDate: string;
  friends: string[];
  gameMoney: number;
  cash: number;
  totalUsedGameMoney: number;
  // 그 외 40개가 넘는 정보들.
}

const gamer281: Gamer = {
  id: "1232-a281",
  name: "이태현",
  nickname: "hamelln",
  joinDate: "2023-03-23",
  friends: ["id1", "id2", "id3"],
  gameMoney: 203022,
  cash: 20000,
  totalUsedGameMoney: 2202200,
  // 그 외 40개 넘는 정보들.
};

 위의 코드를 봅시다. 게이머에게는 많은 정보가 있는데요. 게이머들을 대상으로 이벤트를 진행한다고 가정합시다. 당첨자를 발표하기 위해서 최소한의 정보만 조회하고 그 외에는 참조하지 않아도 되는데요. 이럴 때 타입 업캐스팅을 사용하면 좋습니다.

type EventParticipants = { id: string; name: string; nickname: string, phone: string };

function personalize(gamer: Gamer) {
  return gamer satisfies EventParticipants as EventParticipants;
}

const person = personalize(gamer281);
person.cash // ❌ Error(ts2339): EventParticipants 타입에 없는 속성입니다!

 Gamer는 EventParticipants 타입을 만족하기 때문에 satisfies EventParticipants를 통과합니다. 하지만 gamer에는 EventParticipants 타입 말고도 여러 값들이 실재하기 때문에 EventParticipants 타입으로 바뀌진 않습니다.
 이 때 satisfies EventParticipants as EventParticipants를 사용하면 Gamer 타입은 EventParticipants 타입으로서 참조됩니다. 타입을 체크하고 속성을 적게 만드는 안전한 타입 업캐스팅이 구현됐습니다!

 다른 사용 예시를 생각해봅시다. Jest의 테스트 환경은 Node.js나 Jsdom입니다. BOM을 완벽하게 지원하지 않기 때문에 관련 객체를 모킹해야 하는데요. 이 때 타입 업캐스팅을 사용해서 "필요한 속성만 모킹"하는 수도 있습니다.

마무리

 satisfies는 본래 수 년 전에 '타입 호환성이 적절한지 판단'하고 싶어서 제안이 되었지만 스테이지가 진행되면서 추가적인 변화를 거쳤습니다. 멋진 기능이니 연습하면서 익숙해집시다!

 타입스크립트 4.1에 도입된 템플릿 리터럴 타입을 알아보고 대수적 타입(Algebraic Data Types, 이후 ADTs)이 왜 정적 타입 언어에 필요한지 이해합니다.

 정적 타입 언어는 런타임 전에 타입을 체크함으로 에러를 미리 발견합니다.
 완벽한 언어는 없습니다. 대부분 정적 타입 언어의 한계점은 ad-hoc 타입 시스템입니다. ad-hoc은 "임시적인, 전용"이라는 뜻입니다. 예를 들어 유저 데이터의 타입을 다루고 싶을 때 우리는 User라는 전용 타입을 만들고 관리합니다.
 만약 아무 곳에나 써도 호환이 되는 만능 타입이 존재한다고 가정해봅시다. 하나의 타입으로 유저, 게임, 음식, 애완동물, 게시물 등 모든 데이터를 다룬다면 서로 어떻게 구분할 수 있을까요? ad-hoc 타입 시스템은 피할 수 없는 운명입니다.

당연한 듯 보입니다. 이게 왜 문제일까요?

 이러한 시스템은 고도의 추상화와 범위 모델링을 어렵게 만들었습니다. 타입이 예측에서 조금이라도 벗어날 것 같으면 정지부터 하는 예민한 시스템은 멋지지 않습니다. 제네릭, 유니온, 튜플이 없는 타입스크립트를 생각해보세요.
 이를 보완하는 연구와 개선이 많습니다. Martin-Löf Type Theory, Generic, C++의 Dependent Types, Rust의 대수적 타입이 좋은 예시입니다.
 대수적 타입은 타입을 수학처럼 더하고 곱해서 문제 해결, 대응에 도움되는 유연한 타입을 만들자는 아이디어입니다. 더하는 타입과 곱하는 타입이 있습니다.

// 더하는 타입
type Direction = "up" | "down" | "right" | "left"
type Params = string | number
// 곱하는 타입
type Person = { name: string, age: number }
type Tuple = readonly [boolean, number, string]

 더하는 타입은 여러 선택지가 있는 타입이고, 곱하는 타입은 하나 안에 여러 타입이 공존합니다. 그게 전부입니다. 지극히 간단한 원리입니다.

템플릿 리터럴 타입?

 템플릿 리터럴 타입은 대수적 타입의 범위 모델링을 강력하게 지원합니다. 템플릿 리터럴 타입이 도입되기 전 코드를 봅시다.

// case 1: 버튼 타입이 추가될 때마다...
type Buttons = "a" | "b" | "x" | "y" | "home" | "zl" | "zr";

// 💔 버튼에 대한 메소드 타입도 일일이 추가해야 한다.
type ButtonsController = {
  onA: () => void;
  onB: () => void;
  onX: () => void;
  onY: () => void;
  onHome: () => void;
  onZl: () => void;
  onZr: () => void;
};

class Controller implements ButtonsController {
  // ... 메소드 구현
}

// case 2: 포커용 카드 타입을 어떻게 만들지?
type CardRank = 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | "J" | "Q" | "K" | "A";
type CardSuit = "♥" | "♠" | "♣" | "◆";
type Card = [CardSuit, CardRank] | "JOKER"; // 🙇‍♂️ 흠...뭔가 별로다.

 case 1: 타입이 추가되거나 타입 이름이 변경될 때마다 메소드 타입을 정의하는 코드도 매번 고쳐야 합니다. 번거로울 뿐더러 실수할 수도 있습니다.
 case 2: 튜플 | "JOKER" 타입이라 통일감이 떨어지고 보기 안 좋습니다.

 상술했던 ad-hoc 타입 시스템의 단점을 명확히 보여줍니다. 타입이 너무 구체적이면 바꾸려고 할 때마다 관련된 것들을 일일이 고쳐야 하고, 복잡한 타입에 적용하기도 힘듭니다.

 템플릿 리터럴 타입으로 위 코드를 개선해봅시다.

// case 1: 버튼에 대한 타입만 추가하거나 변경합니다.
type Buttons = "a" | "b" | "x" | "y" | "home" | "zl" | "zr" 
type CapitalizedButtons = Capitalize<Buttons> // 📘 Capitalize: TS 4.1에 추가된 타입. string 리터럴 타입의 첫 글자를 대문자로 바꿉니다.
type ButtonHandlers = `on${CapitalizedButtons}` // "onA" | "onB" | "onX" | "onY" | "onHome" | "onZl" | "onZr"

// 🎉 메소드 타입은 버튼 타입에 맞춰서 자동으로 업데이트됩니다!
type ButtonsController = {
  [BH in ButtonHandlers]: () => void;
}

class Controller implements ButtonsController {
  // ... 메소드 구현
}

// case 2: 포커 카드
type CardRank = 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | "J" | "Q" | "K" | "A";
type CardSuit = "♥" | "♠" | "♣" | "◆";
type Card = `${CardSuit}-${CardRank}` | "JOKER"; // 53가지의 문자열 리터럴 타입 생성

 타입을 좀 더 유연하게 선언할 수 있고, 약간의 수정 작업도 넣을 수 있습니다. 이 덕분에 기존에는 할 수 없거나, 번거로웠던 타입 작업을 훨씬 간편하게 구현할 수 있습니다.

마무리

 대수적 타입을 통한 사고방식과 방법은 문제해결에 도움을 줍니다. 템플릿 리터럴 타입으로 강화된 타입스크립트를 즐겨보세요!

프로젝트 빌드

 프로젝트 빌드는 번들링, 트랜스파일, 최적화 등을 하는 과정을 말합니다. 왜 이러한 과정이 필요할까요? 옛날 이야기를 하나 보죠.

 롤러코스터 타이쿤2는 어셈블리어로 개발된 게임입니다. 어셈블리어는 기계어에 매우 가까운 저수준 언어입니다.

 그 시절에도 어셈블리어로 게임을 제작하는 일은 드물었습니다. 성능은 좋지만 사람이 읽고 쓰기엔 어렵기 때문입니다. 롤러코스터 타이쿤2 개발자가 대단하다는 말을 듣는 이유입니다.

 고수준일수록 사람에 친화적이고 저수준일수록 기계 친화적입니다. 즉, 사람이 읽기 쉬울수록 기계는 어려워합니다.

번들링

 우리가 보는 코드는 사람 친화적 코드입니다. 의미있는 변수 이름, 가독성을 위한 띄어쓰기, 세세한 폴더 분류, 클린 코드...중요합니다. 하지만 브라우저한텐 어떨까요?

 브라우저 입장에서 위 구조는 그저 난잡합니다. 의존성이 여기저기 엮여있어 불러오는 비용이 낭비될 뿐입니다. 그래서 브라우저가 읽기 편하도록 재분류하는 번들링 작업이 필요합니다.

 이런 구조는 어떨까요? 코드량과 복잡도가 늘어 개발자는 읽기 어렵겠지만 브라우저에겐 편합니다.
 그림 1을 그림 2로 재분류하는 작업이 번들링이며, 정리된 결과물 단위를 번들이라고 부릅니다.
 대부분의 번들링 도구는 번들링, 최적화, 경량화, 트랜스파일링, 코드 스플리팅 등의 작업을 같이 수행합니다.

코드 스플리팅

 그렇다면 번들은 몇 개로 만들어야 좋을까요? 적을수록 브라우저가 읽기 쉬우니 아래 그림 오른쪽처럼 한 개면 될까요?

 번들 수가 적을수록 번들 당 용량은 커집니다. 브라우저에게 있어 자바스크립트는 렌더링 방해 자원입니다. 번들 용량이 클수록 초기 로딩 속도는 느려집니다.
 따라서 필요한 것을 필요할 때에 불러야 효과적입니다. 번들링은 파일을 줄이되, 적절히 여러 개로 나눌 필요가 있습니다.
 예를 들면 쇼핑몰에서 "거래 완료 페이지"와 "메인 페이지"는 코드를 같이 둘 필요 없으니 독립된 번들로 나눕니다. 그림 왼쪽과 같이 번들을 여러 개로 나누는 처리를 코드 스플리팅이라고 합니다.

코드 스플리팅 방법

 자바스크립트 프레임워크들은 자동으로 코드 스플리팅을 합니다. 예를 들면 Next.js는 pages 폴더(14버전 이후는 app 폴더)에 작성한 코드들을 자동으로 스플리팅합니다. pages의 파일들은 각각의 URI로 라우팅되기 때문에 같은 번들에 묶을 필요가 없기 때문입니다.
 위에 든 예시처럼 거래 완료 페이지와 메인 페이지는 서로 독립적인 페이지이므로 코드 스플리팅을 자동 처리해주는 게 더 편리합니다.
 코드 스플리팅은 수동으로 지정할 수도 있습니다. 예를 들면 동적 import는 코드 스플리팅 대상입니다.
 또한 터미널에서 Next.js 코드를 실행하면 코드 스플리팅을 볼 수 있습니다.

- ready started server on 0.0.0.0:3000, url: http://localhost:3000
- info Loaded env from /Users/projects/beermap-client/.env.development
- info Disabled SWC as replacement for Babel because of custom Babel configuration ".babelrc.json" https://nextjs.org/docs/messages/swc-disabled
- event compiled client and server successfully in 2.5s (26 modules)
- wait compiling...
- event compiled client and server successfully in 857 ms (20 modules)
- wait compiling /page (client and server)...
- info Using external babel configuration from /Users/projects/beermap-client/.babelrc.json
- event compiled client and server successfully in 11.7s (494 modules)

• 로컬 url로 서버가 열리고 3000번 포트로 수신합니다.
• .env.development에서 개발 환경 변수를 읽어옵니다.
• .babelrc.json 파일이 있으므로 기본 SWC 대신 바벨로 컴파일합니다.
• 번들이 복수이므로 여러 차례에 나눠 컴파일을 수행합니다. 이 때 작업에 연관되는 모듈의 수는 제각각이며 작업 시간도 각자 다릅니다. (코드 스플리팅)

트랜스파일링

 브라우저는 타입스크립트나 리액트가 아닌, 오로지 HTML, CSS, JS만 실행하므로 프레임워크, 라이브러리로 만든 코드는 HTML, CSS, JS로 파일 변환해야 합니다. 이것이 트랜스파일링입니다. 보통은 빌드 때 번들링과 트랜스파일링이 같이 처리됩니다.
 최신 문법은 브라우저마다 지원 현황이 다르기 때문에 모두와 호환되는 이전 버전의 문법으로 변환할(필요하다면 폴리필을 만들) 필요도 있습니다. 이러한 것도 트랜스파일링 과정에서 수행됩니다.

타입스크립트의 트랜스파일링

 tsconfig 파일에선 컴파일 옵션을 지정할 수 있습니다. 이 때 컴파일은 타입스크립트를 자바스크립트로 바꾸는 트랜스파일링입니다.

"compilerOptions": {
    "target": "es2016", // 결과물로 만들 자바스크립트의 ECMAScript 버전.
    "module": "CommonJS", // 모듈 시스템 지정.
    "strict": true, // 모든 타입 체킹 옵션 활성화.
    "esModuleInterop": true, // ESM과의 호환성을 높이는 옵션. CommonJS 모듈을 ESM처럼 사용 가능합니다.
    "forceConsistentCasingInFileNames": true, // 파일명의 대소문자가 일치하지 않으면 오류를 발생시킵니다.
    "outDir": "dist", // 컴파일 결과물 저장 폴더. dist는 distribution(배포)의 줄임말입니다. 
    "declaration": true, // 컴파일 후 d.ts(타입 정보를 담은 파일)을 생성합니다. 
    "declarationDir": "types", // d.ts를 저장할 폴더 이름.
    "rootDir": "." 
}

 보통 dist폴더에 컴파일 결과를 저장합니다. 만약 위 옵션을 가지고 npx tsc를 실행하면 dist 폴더와 types 폴더가 생성됩니다.
 개발자는 타입스크립트로 개발하고, 브라우저는 배포 파일의 dist에서 자바스크립트를 사용합니다. 개발할 땐 dist라는 폴더에서 import한 게 없으므로 package.json에서 실행 파일을 지정합니다.

// package.json
{
  "name": "project",
  "version": "1.0.0",
  "main": "dist/index.js",
  "types": "types/index.d.ts"
}

자바스크립트의 트랜스파일링

 타입스크립트 -> 자바스크립트 컴파일은 평범한 자바스크립트로 바꾸지 않습니다. 예를 들면 아래 코드는 코드는 사람이 읽기 쉬운 자바스크립트입니다.

window.addEventListener("DOMContentLoaded", Selection);
window.addEventListener("load", () => {
  const settingButton = document.querySelector(".mode__setting");
  const themeButton = document.querySelector(".mode__theme");
  const muteButton = document.querySelector(".mode__mute");

 이대로 배포할 경우 다른 사람도 읽기 쉽고, 보안에 취약해집니다. 또한 사람이 읽기 편한 구조이므로 브라우저가 읽기엔 불편합니다. 그래서 실제 트랜스파일링을 하면 아래와 같이 변환됩니다.

(()=>{"use strict";var t,e,n=function(t){t.classList.add("focus"),t.focus()},r=function(t){t.classList.remove("focus"),t.blur()},o=document.getElementById("project"),i=(t=o,e=window.innerHeight,t.offsetTop-(e-t.offsetHeight)/2);const a=function(t,e){switch(t){case"about":scrollTo(0,0);break;case"project":scrollTo(0,i),e&&function(t){n(t.querySelector(".focusable"))}(o)}};function c(t){return function(e){for(var n=arguments.length,r=new Array(n>1?n-1:0),o=1;o<n;o++)r[o-1]=arguments[o];t.addEventListener("click",(function(t){t.preventDefault(),e.apply(void 0,r)})),t.addEventListener("keydown",(function(t){"Enter"===t.key&&(t.preventDefault(),e.apply(void 0,r))}))}}var s=!0,u=function(t){f(t),t.muted=s}

 브라우저가 읽는 것에만 집중하기 때문에 개발자가 읽기 어렵습니다. 띄어쓰기도 없고 변수명도 축소, 난수화하며 ECMAScript 문법도 개발자가 설정한 버전에 맞춰 바꿉니다.

번들링 도구

 흔히 웹팩이 쓰였습니다만 근래에 Vite가 주목을 받습니다. 빌드 속도가 웹팩보다 압도적으로 빠르기 때문에 개발 비용을 유의미하게 개선하기 때문입니다. 결과물이 비슷하다면 훨씬 빠른 쪽을 쓰는 게 이득이니까요.

CI/CD

 빌드에 대해 간략하게 살펴봤으니 CI/CD도 살펴보겠습니다.
 CI/CD는 연속되는 통합/연속되는 배포(Continuous Integration/Continuous Deployment)라는 단어입니다.
 먼 옛날에는 변경 사항이 일어날 때마다 개발자가 직접 빌드, 테스트, 배포했습니다. 배포 중에 오류라도 나면 서비스를 정지하고 롤백해야 하는 수도 있습니다. 이는 서비스 공급자와 소비자 모두의 사용 경험을 저하시켰습니다.
 CI/CD는 변경 사항을 통합/배포하는 과정에서 서비스 제공이 연속적이란 얘기입니다. 성공하면 배포하고, 실패하면 기존 버전으로 유지합니다. 개발자는 실패에 대한 배포 리스크를 지지 않아도 됩니다.
 이러한 CI/CD는 도구를 통해 설정과 파이프라인을 만들기만 하면 됩니다. 변경 사항을 등록하면 자동으로 빌드, 테스트, 배포, 에러 처리를 하기 때문에 개발자가 수동으로 처리하던 비용이 획기적으로 감축됩니다.

name: Node.js CI

on:
  push:
    branches: ["main", "develop"]
  pull_request:
    branches: ["main", "develop"]

jobs:
  build-and-test:
    runs-on: ${{ matrix.os }}

    strategy:
      matrix:
        node-version: [18.x]
        os: [ubuntu-latest, windows-latest, macOS-latest]

    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - uses: actions/cache@v3
        id: npm-cache
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
      - if: steps.npm-cache.outputs.cache-hit == 'true'
        run: echo 'npm cache hit!'
      - if: steps.npm-cache.outputs.cache-hit != 'true'
        run: echo 'npm cache missed!'
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm"
      - name: Update NPM
        run: npm install -g npm@latest
      - run: npm ci
      - run: npm run build --if-present
      - run: npm run test:ci
      - name: Publish to Chromatic
        uses: chromaui/action-next@v1
        with:
          projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}

 위와 같은 yaml 파일을 프로젝트에 설정하고 작업 변경을 시행하면 버전 관리 도구는 주어진 환경에 맞춰서 빌드, 테스트한 다음에 모두 성공할 때에만 변경 사항을 서비스에 적용합니다.
 위 예제는 GitHub Actions의 CI 설정입니다. 배포는 Vercel로 했기 때문에 CD 설정은 Vercel에서 할 수 있습니다.

결론

 일반적인 개발자가 회사에 들어가서 CI/CD 파이프라인 조정, 빌드, 트랜스파일링 등에 대해 작업할 일은 별로 없겠습니다만, 저처럼 사이드 프로젝트나 개인 프로젝트를 진행할 땐 기본적인 내용 정도는 알고 한다면 좋습니다.

참조

• 장호승(2022.10). CommonJS와 ESM에 모두 대응하는 라이브러리 개발하기: exports field. toss tech
• Igor Irianto(2019.07). What the heck are CJS, AMD, UMD, and ESM in Javascript?

 프로토타입과 클래스를 이해합니다.

프로토타입

 객체 지향은 클래스 상속을 이용합니다. 자바스크립트도 비슷합니다. 다만 프로토타입이란 방식으로 내부적 구현을 합니다.

const arr = [1,2,3];
arr.map((num) => console.log(num));

 .은 객체의 속성과 메소드를 참조하는 문법입니다. 즉, arr는 객체입니다. map이라는 메소드를 따로 명시하지 않아도 Array의 프로토타입을 상속받았으므로 Array.prototype.map 메소드를 사용할 수 있습니다.
 자바스크립트는 내부적으로 모든 비원시 타입(배열, 함수, 클래스 등)에 프로토타입을 상속시킵니다. 아래와 같은 느낌으로 보면 됩니다.

class Array {
	map(){...}
}
    
const arr = [1,2,3]; // Array의 인스턴스
Object.getPrototypeOf(arr) // arr의 프로토타입은 Array
arr.map() // Array의 map

원시 타입과 프로토타입

// 문자열은 원시 타입이지만 객체처럼 메소드를 사용할 수 있습니다.
"string".charAt("s"); 

 문자열은 원시값이지만 객체처럼 메소드를 참조할 수 있습니다. 자바스크립트는 문자열에서 메소드를 사용할 경우 일시적으로 String의 인스턴스로 변환합니다. 이를 래퍼 객체라고도 부릅니다. 문자열은 런타임에만 객체로서 평가되어 메소드를 참조하고, 코드 평가가 끝나면 다시 문자열로 돌아갑니다.

프로토타입 체인

 생성자 함수는 자신이 상속받은 프로토타입에 프로퍼티와 메소드를 추가할 수도 있습니다. 예를 들면 일반 배열은 Array의 프로토타입을 상속받고, Array는 Object의 프로토타입을 상속받습니다. 이처럼 프로토타입 상속은 여러 단계로 상속됩니다. 이를 프로토타입 체인이라 합니다. 참고로 모든 프로토타입의 최종적인 부모는 Object이고, 이 까닭에 자바스크립트는 원시값을 제외한 모든 게 객체라는 말을 합니다.

Object 프로토타입 { ... }
Array 프로토타입 { ... } // Object 프로토타입을 상속받습니다.
const array = [1,2,3]; // Array 프로토타입을 상속받습니다.

 __proto__ 프로퍼티나, 혹은 Object.getPrototypeOf 로 해당 객체의 부모 프로토타입을 확인할 수 있습니다.

class Person { ... }

const person = new Person();
const proto = Object.getPrototypeOf(person); // Person.prototype
const proto2 = person.__proto__; 

생성자 함수

 자바스크립트에선 객체를 많이 씁니다. 비슷한 역할을 가진 객체를 대량 만들거나, 특수한 목적을 가진 객체를 만들어야 할 때도 있습니다.

function greet(name) {
  console.log(`Hello ${name}`);
}

const user = { name: "user1" };
greet(user.name);

 위처럼 단순한 케이스는 함수와 객체를 분리시켜도 무관합니다. 하지만 유저 정보와 관련 함수가 많아지면 중복과 복잡도가 늘어납니다. 그래서 아래와 같이 생성자 함수를 사용합니다.

function User(name) {
  this.name = name;
  this.greet = function() { ... }; // 인스턴스마다 제각각 생성합니다.
}
User.prototype.greet = function () { ... }; // 모든 인스턴스가 공유합니다.

const user1 = new User("Lee");
const user2 = new User("Kim");
console.log(user1.greet === user2.greet); // true

 greet 함수는 항상 기능이 일정하기 때문에 여러 번 생성할 필요없습니다. 모든 유저가 똑같은 greet 함수를 사용해야 효율적입니다. 위와 같이 프로토타입을 통해 함수를 등록하면 모든 인스턴스가 하나의 greet 함수를 공유합니다.
 요즘은 위와 같이 프로토타입을 작성하는 대신 클래스를 이용합니다. 클래스는 내부적으로 프로토타입을 쓰기 때문에 코드가 간결하고 일반 생성자 함수보다 많은 기능을 지원합니다.

클래스

class User {
  constructor(name) {
    this.name = name;
    // return this;
  }

  greet() {
    console.log(this.name);
  }
}

const user = new User("user1");
// ...
const user = new User("user9547272");

 클래스도 생성자 함수입니다. new 접두사를 붙여 실행 시 constructor가 실행되어 인스턴스를 반환합니다. (constructor는 암묵적으로 this를 반환합니다.) constructor에서 선언하는 this.name 따위는 각 인스턴스들이 개별적으로 가질 속성입니다.
 constructor 바깥에 적는 메소드는 프로토타입에 등록되어 모든 인스턴스가 공유합니다. 또한 constructor도 메소드처럼 프로토타입에 등록됩니다.

class User {
    constructor(name) {
        this.name = name
    }
    // User의 프로토타입에 greet 메소드 등록
	greet() {
        console.log(this.name)
    }
    // User의 인스턴스마다 greet 함수 생성
    greet2 = () => {
        console.log(this.name)
    }
}

const user1 = new User("A");
const user2 = new User("B");
console.log(user1.greet === user2.greet) // true
console.log(user1.greet2 === user2.greet2) // false

 단, 메소드를 화살표 함수로 작성하면 프로퍼티로서 평가됩니다.

const user = {
  greet() { ... }
};

 객체 리터럴에서 작성한 함수도 메소드가 아닌 프로퍼티로 평가됩니다. 객체 리터럴을 생성자 함수로 쓸 일이 없기 때문입니다.
 메소드와 함수의 차이를 묻는 질문이 많은데 자바스크립트에 한정하면, 메소드 축약법(method shorthand)으로 정의해 프로토타입에 등록된 함수를 뜻할 때가 많습니다.

클래스의 정적 요소

 일반적으로 속성과 메소드는 인스턴스를 생성해야만 참조할 수 있습니다. 하지만  static을 쓰면 인스턴스 없이 클래스 자체에서 참조합니다.

class User {
  static greet() {
    console.log("hi");
  }
  greet2() {
    console.log("hello");
  }
}

const user = new User();
user.greet2(); // 일반 메소드
User.greet(); // 정적 메소드

 인스턴스에서 정적 요소에 접근할 일은 없지만 불가능하진 않습니다. 프로토타입을 통해 부모의 정적 요소를 참조할 수 있습니다.

class Person {
  static greet() {
    console.log("hi");
  }
}

const person = new Person();
const proto = Object.getPrototypeOf(person); // Person.prototype
const proto2 = person.__proto__; // Person.prototype
const proto3 = Person.prototype; // Person.prototype
const proto4 = Person.__proto__; // Function.prototype
proto.constructor.greet(); // hi
proto2.constructor.greet(); // hi
console.log(proto === proto2); // true
console.log(proto2 === proto3); // true
console.log(proto2 === proto4); // false

참조

• 이웅모(2020.09). 모던 자바스크립트 Deep Dive: 자바스크립트의 기본 개념과 동작 원리. 위키북스
• ECMAScript® 2023 Language Specification
• The JavaScript this Keyword
• JavaScript - this Keyword
• Arrow function expressions

 타입스크립트의 구조적 타입 시스템 특성을 이해하고 타입 호환과 타입 체크를 연습합니다.

정적 타입 언어의 타입 시스템은 크게 두 가지 방식이 있습니다.

1. 명목적 타이핑. (혹은 이름 기반 타입 시스템)
2. 구조적 타이핑. (혹은 덕 타이핑, 프로퍼티 명 기반 타입 시스템)

 둘의 차이는 아래와 같습니다.

• 명목적 타이핑은 '이름, 단위'를 비교합니다. L와 m는 단위가 다르므로 둘은 다르다고 판단합니다.
• 구조적 타이핑은 '속성, 구조'를 비교합니다. 둘 다 number속성을 가지므로 둘은 똑같다고 판단합니다.

 벌써부터 '구조적 타입이 바보처럼' 보입니다. 객체 타입에선 어떨까요?

// 명목적 타이핑(이름 기반 타이핑): Java, Swift...
type Game = { name: string }
type Animal = { name: string }
let zelda: Game = { name: "zelda" }
let duck: Animal = { name: "gooose" }
zelda = duck; // ❌ Error: zelda는 Game 타입입니다! Animal 타입을 할당하지 마세요!

// 구조적 타이핑(속성 기반 타이핑): TypeScript...
type Game = { name: string }
type Animal = { name: string }
let zelda: Game = { name: "zelda" }
let duck: Animal = { name: "gooose" }
zelda = duck; // ✅ OK: "name" 속성을 만족하니까 할당 가능합니다!

 "게임"과 "동물"은 엄연히 다릅니다. 하지만 둘 다 name 속성을 가졌단 이유만으로 서로 호환됩니다. 이런 특성 때문에 구조적 타이핑은 덕 타이핑이란 이름으로 많이 불립니다.

Q) “오리란 무엇인가?”

1. 오리 같은 부리를 가졌다.
2. 오리 같은 눈을 가졌다.

 동물 협회에서 위 두 조건을 만족하기만 하면 오리로 공인했다고 가정해봅시다. 그럼 아래의 사진은 "합성이 아닌 진짜 오리"라고 인정됩니다.

왜 타입스크립트는 구조적 타입 시스템을 사용할까요?

 구조적 타이핑은 허술하기만 할까요? 왜 이런 시스템을 허용할까요? 다음 상황을 봅시다.

type Food = { carbohydrates: number; protein: number; fat: number };
type Burger = Food & { burgerBrand: string };

// 명목적 타입 시스템에서 이 함수는 Food 타입만 처리합니다.
function calculateCalorie({ carbohydrates, protein, fat }: Food) {
  return carbohydrates * 4 + protein * 4 + fat * 9;
}

const thighBurger: Burger = {
  carbohydrates: 60,
  protein: 28,
  fat: 27,
  burgerBrand: "Mom's Touch",
};

// Swift는 이럴 때 `Foodable protocol`을 `extension`으로 확장해서 사용합니다.  
calculateCalorie(thighBurger); // 타입스크립트는 어떨까요? 함수가 버거 칼로리 계산을 못하게 막는 게 좋을까요?

 직관적으로, 햄버거가 Food 타입은 아닐지언정 탄수화물, 단백질, 지방 정보가 있으니 칼로리 계산이 된다면 멋지지 않을까요? 실제로 타입스크립트는 별도의 처리 없이 칼로리 계산을 허용합니다. 햄버거가 탄수화물, 단백질, 지방이라는 Food의 '속성'을 전부 갖췄기 때문입니다.
 심지어 버거 브랜드라는 잉여 속성도 허용합니다. 허술해보이던 단점을 유연함이라는 장점으로 승화시킵니다. 이런 특징은 다형성과 연계됩니다.

• 명목적 타이핑: 정밀한 타입 체크로 에러 방지. 유연성, 호환성이 부족
• 구조적 타이핑: 타입 체크가 허술하지만, 그래서 유연한 사용이 가능

 구조적 타이핑은 유연함과 허술함이 공존합니다. 타입스크립트에는 허술함을 조심하는 기술이 몇 가지 있습니다. 그 중 하나는 객체 리터럴입니다.
 먼젓번 코드에선 버거 브랜드 속성을 허용했지만 객체 리터럴을 바로 입력하면 에러가 발생합니다. 타입스크립트는 타입이 결정되거나 추론된(변수에 할당되거나 as로 타입 단언한) 객체만 잉여 속성을 허용하기 때문입니다.
 타입스크립트는 객체 리터럴을 신선(fresh)한 객체라고 분류하며, 타입에 기재되지 않은 속성을 발견되면 에러를 던집니다. 이런 케이스를 허용했다간 개발자의 실수로 버그가 발생할 확률이 높기 때문입니다.

// 📒 만약 객체 리터럴에서 잉여 속성도 허용한다면?
// 😡 부작용 1: 다른 개발자는 burgerBrand가 필수 속성이라고 오해할 수 있습니다.
const calorie1 = calculateCalorie({
  protein: 29,
  carbohydrates: 48,
  fat: 13,
  burgerBrand: "버거킹", // ❌ Error: 잉여 속성이 존재함.
});

// 🤬 부작용 2: 잉여 속성에 오타가 있어도 TypeScript는 이를 발견할 수 없습니다!
const calorie2 = calculateCalorie({
  protein: 29,
  carbohydrates: 48,
  fat: 13,
  birgerBrand: "버거킹", // ❌ Error: 잉여 속성이 존재함.
});

아까 봤던 L과 m을 비교하려면 어떻게 할까요?

 1000L와 1000m는 둘 다 number 타입이기 때문에 속성 비교만 하는 구조적 타이핑으론 방법이 없습니다. 이럴 때 개발자들은 브랜딩을 사용합니다. 브랜딩 기법은 명목적 타입 시스템을 구현하는 묘기입니다. 다시금 구조적 타입 시스템의 한계점을 확인해봅시다.

// Nominal Type System
type USD = { value: number };
type EUR = { value: number };

let dollors: USD = { value: 10; }
let euros: EUR = { value: 15; }
dollors = euros; // ❌ Error: USD와 EUR 타입은 다릅니다!

// Structural Type System
type USD = { value: number };
type EUR = { value: number };

let dollors: USD = { value: 10; }
let euros: EUR = { value: 15; }
dollors = euros; // ✅ OK: "value"라는 속성을 가지고 있으니 허용합니다...이러면 안 되는데?

 명목적 타입 시스템에선 이런 케이스가 문제될 일이 없지만 구조적 타입만으론 이 문제를 다루기 쉽지 않습니다. 그래서 타입스크립트는 브랜딩이라는 명목적 타입을 흉내내는 기법을 사용합니다.

type Brand<K, T> = K & { __brand: T };
type USD = Brand<number, "dollors">;
type EUR = Brand<number, "euros">;

let dollors = 10 as USD; // number가 아닌 USD 타입으로 취급합니다.
dollors.__brand; // undefined. 숫자면서 __brand 속성도 가진 특이한 타입.
dollors = 20; // ❌ Error: 일반 숫자는 할당 불가능.
dollors = 1 as EUR; // ❌ Error: 이름이 다른 타입을 USD 타입에 할당할 수 없습니다.
dollors = 100 as USD; // ✅ OK: USD 타입만 재할당 가능

 USD와 EUR은 실제 값은 숫자이면서 as로 EUR, USD라고 단언한 타입만 할당을 허용합니다. TypeScript 5.2.2 playground에서는 보안 위험이 있는 문자열 입력 등 "특별한 문자열, 숫자값을 그냥 처리하면 안 될 때" 쓰면 유용하다고 서술합니다.
 아래는 브랜딩 기법을 활용해서 XSS(Cross-Site Scripting) 처리를 하는 간단한 예시입니다.

type ValidatedInputString = string & { __brand: "User Input Post Validation" };

// 입력 글자에 코드 실행문이 있다면 필터링하고, branding 처리한 string을 return합니다.
const validateUserInput = (input: string) => {
  const simpleValidatedInput = input.replace(/\</g, "≤");
  return simpleValidatedInput as ValidatedInputString;
};

// 검증된 branding 문자열만 받아서 출력합니다.
const printName = (name: ValidatedInputString) => {
  console.log(name);
};

// 코드 실행하는 문자열 
const input = "alert('bobby tables')";

// 검증을 거친 문자열
const validatedInput = validateUserInput(input);

printName(validatedInput); // ✅ OK: 검증 후 브랜딩 처리된 string이므로 정상 처리
printName(input); // ❌ Error: 검증 안 된(브랜딩이 안 된) 일반 string은 실행 거부

마무리

 타입스크립트의 구조적 타입 시스템은 유연한 코드를 돕지만 개발자의 주의를 전제합니다. 많이 사용하면서 익숙해집시다.

참조

• 조현영(2023.08). 타입스크립트 교과서. 길벗
• 김병묵(2022.10). TypeScript 타입 시스템 뜯어보기: 타입 호환성. toss tech
• TypeScript 공식

 HTML에서 캔버스는 애니메이션, 그림 구현에 특화된 강력한 도구입니다.

1. 테마 버튼 구상
   a. 디자인
2. 구현
   a. 기본 상태, hover
   b. 애니메이션 준비
   c. 애니메이션 실행
   d. 결과
3. 테마 변경
4. 파일 구조
5. 마무리
6. 연관 포스팅

1. 테마 버튼 구상

“버튼을 클릭하면 테마가 다크 모드, 라이트 모드로 바뀌고, 애니메이션을 보여주고 싶다.”

a. 디자인

 버튼을 누르면 말풍선이 튀어나오면서 다크 모드 애니메이션과 타이포그래피를 보여주는 건 어떨까?
 → 말풍선은 대화형 상호 작용에 적합하지 않을까? 사용자가 모드 버튼을 통해 대화, 혹은 비슷한 상호 작용을 할 일은 없다. 다른 걸 해보자.

 버튼을 hover하면 화면을 켜는 듯한 효과를 나타내고 클릭하면 시간이 흐르듯 애니메이션을 나타내보자. 복고풍 게임 사용감을 주고 싶다.

2. 구현

a. 기본 상태, hover

 먼저 moon을 그려서 정보만 가져온 뒤, 바로 sun을 그린다. 매우 빠르게 진행하기 때문에 사용자가 moon을 볼 일은 없다. 이렇게 해서 초기 화면이 구성됐다. 이제 애니메이션을 구현해보자.

b. 애니메이션 준비

 가로 140, 세로 80만 해도 픽셀이 11,200다. 원하는 애니메이션을 구현하려면 입자들이 이 공간을 전부 칠할 수 있도록 구상해야 한다. 1개의 입자만으로도 구현할 수 있지만, 여러 개의 입자들로 캔버스를 칠하고 싶다. 이럴 때에는 동일한 로직을 가진 객체를 여럿 만들어야 하므로 클래스가 적합하다.

• 상태: 캔버스 컨텍스트, 캔버스 가로, 세로, 입자를 칠할 각도, 좌표, 색, 속도, 방향, 반지름
• 액션: 상태 변경(update), 캔버스에 그리기(draw)

class Particle {
  constructor(ctx, WIDTH, HEIGHT) {
    this.ctx = ctx;
    this.WIDTH = WIDTH;
    this.HEIGHT = HEIGHT;
    this.fullAngle = Math.PI * 2;
    this.x = Math.random() * this.WIDTH;
    this.y = Math.random() * this.HEIGHT;
    this.r = 5;
    this.speed = 1;
    this.direction = this.x > 63 ? 1 : -1;
    this.px = Math.floor(this.x);
    this.py = Math.floor(this.y);
  }

  update(phaseSign) {
    this.speed = this.speed <= 0.1 ? 0.1 : this.speed - 0.004;
    this.x += this.direction * this.speed;
    this.r = this.r <= 1 ? 1 : this.r - 0.04;

    if (this.x <= 0 || this.x > this.WIDTH) {
      this.x = Math.random() * this.WIDTH;
      this.y = Math.random() * this.HEIGHT;
      this.direction *= -1;
      if (this.speed < 0.2 && phaseSign > 0) {
        this.y = this.HEIGHT / 2 + this.y / 2;
        this.r = 2;
      }
    }
    this.px = Math.floor(this.x);
    this.py = Math.floor(this.y);
  }

  draw(phase) {
    this.ctx.beginPath();
    this.ctx.fillStyle = phase[this.py][this.px];
    this.ctx.arc(this.x, this.y, this.r, 0, this.fullAngle);
    this.ctx.fill();
  }
}

 캔버스 컨텍스트에서 지원하는 getImageData API를 쓰면 이미지를 구성하는 각 픽셀들의 rgba 정보를 알 수 있다.

    const getRgbsFromImageData = (imageArray, WIDTH, HEIGHT) => {
      const colorMap = [];
      for (let y = 0; y < HEIGHT; y++) {
        const row = [];
        for (let x = 0; x < WIDTH; x++) {
          const r = imageArray.data[y * 4 * imageArray.width + x * 4];
          const g = imageArray.data[y * 4 * imageArray.width + x * 4 + 1];
          const b = imageArray.data[y * 4 * imageArray.width + x * 4 + 2];
          const color = `rgb(${r},${g},${b})`;
          row.push(color);
        }
        colorMap.push(row);
      }
      return colorMap;
    };

 이제 애니메이션을 실행할 입자를 몇 개 만들지 정한다.

  const init = (ctx, WIDTH, HEIGHT) => {
    return Array.from(
      { length: WIDTH },
      () => new Particle(ctx, WIDTH, HEIGHT)
    );
  };

 준비가 끝났다. 애니메이션을 구현해보자.

c. 애니메이션 실행

  const animate = () => {
    if (!onAnimate) return;
    particles.map(setParticle);
    requestAnimationFrame(animate);
  };

  const setParticle = (particle) => {
    particle.update(phaseSign);
    particle.draw(phase);
  };

1. onAnimate가 false이면 애니메이션을 멈춘다.
2. true이면 프레임마다 애니메이션을 진행한다.

d. 결과

  이 결과를 얻기까지 과정이 순탄하지만은 않았는데 중간에 에러가 발생했다. 클릭할수록 애니메이션이 너무 빨라지는 현상이었고, 뭐가 원인인지 몰라서 이틀을 헤매다가 자려고 누웠을 때 어떤 생각이 뇌리를 스쳤다.
 ‘이벤트 루프 문제일 수 있겠다.’
 정말로 그런 문제였고, 해결한 내용은 이벤트 루프(스택, 큐, 렌더) 포스팅 rAF 목차에 작성했다.

3. 테마 변경

 내가 아는 방법은 버튼을 클릭할 때 각 엘리먼트들이 클래스가 바뀌면서 CSS가 변경되는 것 뿐이었다. 하지만 다크 모드, 라이트 모드는 여러 엘리먼트 CSS가 바뀌기 때문에 그런 걸 일일이 다크 모드로 지정하기엔 손이 많이 간다.
 프로그래밍에는 여러 원칙이 있지만 요즘 특히 마음에 드는 원칙은 ETC(Easy To Change) 원칙이다. 뭔가를 바꿔야할 땐 노가다가 되어선 안 된다.
 Styled-Components에서 글로벌 theme을 적용하면 해결 가능하듯, 일반 CSS로도 같은 방법이 가능하다. 아래와 같이 작성했다.

:root,
[data-theme="default"] {
  --pale-black: #2d2d2d;
  --pale-gray: #ccc;
  --pale-white: #f8f8f8;
  --font-size-xs: 14px;
  --font-size-s: 16px;
  --font-size-m: 18px;
  --font-size-l: 20px;
  --font-size-xl: 24px;
  --title-size-xl: 32px;
  --title-size-l: 30px;
  --title-size-m: 28px;
  --title-size-s: 26px;
  --border-radius-s: 4px;
  --border-radius-m: 6px;
  --border-radius-l: 8px;
  --border-radius-full: 50%;
  --body-bg-color: #fff;
  --text-color: #333;
  --button-shadow: 2px 2px 4px rgba(20, 20, 20, 0.6);
  --button-background-color: var(--pale-white);
  --button-change-background-color: white;
}

[data-theme="dark"] {
  --body-bg-color: #444352;
  --text-color: #efefef;
  --button-shadow: 2px 2px 4px rgba(233, 230, 59, 0.6);
  --button-background-color: var(--pale-gray);
  --button-change-background-color: rgba(27, 27, 27, 0.4);
}

.mode__frame {
  position: absolute;
  display: flex;
  justify-content: center;
  align-items: center;
  width: 148px;
  height: 92px;
  padding: 4px;
  background-color: var(--body-bg-color);
  border: 2px solid var(--text-color);
  border-radius: var(--border-radius-m);
  animation: display-frame 0.6s ease-in-out;
  transition: background-color 0.4s, border-color 0.4s;
}

 transition-property는 구체적으로 지정하는 게 좋다. 효율도 효율이고 의도하지 않은 효과가 나타날 수도 있다. (이번에 잘 깨달았다.)

 JS는 물론 좋다. 하지만 HTML, CSS도 사용하기에 따라서는 뛰어난 도구이기 때문에 이번 프로젝트에서는 HTML 태그, CSS 효과도 적극 활용하는 방향을 지향한다.

  const setup = () => {
    const light = () => {
      const body = document.querySelector("body");
      body.removeAttribute("data-theme");
    };

    const dark = () => {
      const body = document.querySelector("body");
      body.setAttribute("data-theme", "dark");
    };

    const sunImage = "./public/img/sun.png";
    const moonImage = "./public/img/moon.png";
    const phaseMap = new Map();
    phaseMap.set(1, [sunImage, light]);
    phaseMap.set(-1, [moonImage, dark]);
    return phaseMap;
  };

  const changeTheme = (themeSign) => {
    phaseMap.get(themeSign)[1]();
  };  

  const setThemeSign = (newThemeSign) => {
    if (themeSign !== newThemeSign) {
      themeSign = newThemeSign;
      changeTheme(themeSign);
      changeButtonImage(themeSign);
    }
  };

  const handleThemeSign = () => {
    setThemeSign(-themeSign);
  };

 theme 변경하는 함수는 map의 프로퍼티로 보관했다. map은 key를 여러 타입으로 지정할 수 있다. 원래는 일반 객체를 쓰려고 했는데 객체는 key 값이 문자열이라서 조회가 불편하다는 생각이 들었고, map이 괜찮겠다 싶어서 선택했다.
 버튼이 눌릴 때마다 sign은 -1이 곱해지고, sign이 바뀌면 map에서 sign에 맞는 theme 변경 함수를 호출한다.

4. 파일 구조

// 메인 js

window.addEventListener("load", () => {
  themeButtonSetup();
  const op = document.querySelector(".opening");
  setTimeout(() => op.remove(), 6000);
});

// theme-button 메인 js

const themeButtonSetup = () => {
  const handleClick = () => {
    handleAnimation();
    handleThemeSign();
  };

  const clearCanvas = () => {
    setTimeout(stopAnimation, 300);
    foldCanvas();
  };

  const button = document.querySelector(".mode__button");
  button.addEventListener("click", handleClick);
  button.addEventListener("mouseenter", displayCanvas);
  button.addEventListener("mouseleave", clearCanvas);
};

 선언적으로 알기 쉽도록 작성했다. 자체적으로 쓰는 상태나 함수는 클래스와 클로저를 이용해서 분리했다. 원래는 한 번에 작성했고, 명령형도 섞여있어서 가독성이 엉망이었기 때문에 정리했다.

5. 마무리

 테마 버튼 하나 작성할 뿐이지만 클래스, 클로저, 캔버스, 이벤트 루프, 프로그래밍 원칙, 디자인, CSS, 설계, 자료구조...여러 가지를 되짚고 생각하는 시간이었다.

6. 연관 포스팅

• 이벤트 루프(스택, 큐, 렌더)

 OOP의 창시자 앨런 케이는 생물학을 전공했다. 그는 여러 세포들이 상호작용해 큰 유기체를 만들고, 유지하고, 확장하듯 프로그램도 그럴 순 없을까 고민했다. 그는 프로그램의 개체(Entity)들이 아래와 같이 구성되길 바랬다.

1. 서로 내부 구조는 모르고, 서로의 원리를 함부로 바꿀 수 없고, 각자가 맡은 역할에만 충실하되,
2. 무슨 일이 생기면 서로 소통하고 요청하면서 복합적인 반응을 일으키고,
3. 그러면서 여러 요인, 여러 상황에서 실시간으로 적절한 판단을 할 것.

 케이 박사는 3번의 실현을 위해서는 동적 언어가 적합하다고 생각했지만, 정작 객체 지향으로 정말 유명한 Java는 정적 언어다. 그는 어떤 걸 생각하면서 OOP를 발안했을까? 아래 외국 저자의 포스팅과 요 몇 년 간 케이 박사가 Quora에서 답변한 내용들을 보며 다시금 생각해보자.

 앨런 케이 박사는 60년 대에 "객체"라는 말을 꺼냈습니다.
 그는 프로그래밍 계에서 많은 걸 보고, 많은 기여를 했고, 적절한 표현을 위해 그 단어를 뱉었습니다. 그리고 그는 단어가 잘못됐다고 씁쓸해 합니다.
 "객체"란 단어는 사람들로 하여금 "행동(behavior)"이 아닌 "구현(implementation)"에 집중하게 만들어버렸고, 그것이 내리막길의 시작이었습니다.

 오늘날 많은 개발자들이 OOP를 클래스, 상속이라고 말합니다. 좀 더 나아가면 캡슐화, 다형성을 얘기하죠. 하지만 그 뿐입니다.

 케이 박사는 OOP의 전말이 아래와 같다고 말합니다.

1. 메시징
2. 상태를 지역적으로 보관, 보호, 숨김
3. 최대한 느린 바인딩

 왜 이렇게 말했을까요?
 그는 세포 생물학을 전공했습니다. 소프트웨어가 확장성이 안 좋은 데에 비해 세포는 쉽게 계산하고, 확장하고, 복잡한 것을 만들어내며 스스로를 수정한다는 사실을 눈여겨봤습니다. 매우 정교하다는 컴퓨터 소프트웨어 프로그램은 느리고, 작고, 버그 투성이인데 말이죠. 그의 고민은 여기서 비롯합니다.

“어떻게 해야 소프트웨어가 이런 확장성을 가질까?”

독립성

 먼저 독립성을 말해보죠. "상태를 지역적으로 보관, 보호, 숨김"을 짧게 줄인다면 독립성이라고 하겠습니다.
 세포 안쪽은 어지럽고 복잡하지만 세포막이 이를 깔끔하게 포장해서 내부를 숨깁니다. 우리 몸은 매일 500~700억의 세포가 죽습니다. 하지만 우리는 아닙니다. 세포가 죽는다고 우리가 죽나요? 아닙니다. 세포가 죽을 때 여러분이 안 죽는 건 캡슐화 때문이 아닙니다. 독립성 때문이죠. 다음의 (끔찍한) 예시를 보죠.

class MyExample:
    def reciprocal(self, num):
        return  1.0/num

example = MyExample()
print example.reciprocal(4);
print example.reciprocal(0);

 위 코드는 클래스에서 reciprocal을 캡슐화합니다. 하지만...

0.25
Traceback (most recent call last):
  File "class.py", line 7, in <module>
    print example.reciprocal(0);
  File "class.py", line 3, in reciprocal
    return  1.0/num
ZeroDivisionError: float division by zero

 객체도 죽고, 객체를 소유하는 코드도 죽습니다. 이건 그가 우리에게 전달하고자 한 의도와 정반대입니다.
 그가 말하고자 하는 바는 브라우저 - 서버를 생각하면 좋습니다. 서버(객체 1)가 먹통된다고 브라우저(객체 2)까지 함께 먹통이 된다면 MS IIS는 2.0 버전까지도 못 가고 망했겠죠.
 아파넷(Arpanet)은 30년 만에 규모가 1억 배 커졌습니다. (게다가 확장할 때마다 유지보수를 위해 다운시킬 필요도 없었죠.) 오늘날 인터넷은 케이 박사가 "자신이 제시한 OO 모델의 유일한 성공 사례"라고 말합니다.

최대한 느린 바인딩

 그의 또 다른 핵심 주장은 매우 느린 바인딩입니다. 무슨 말일까요? 코드를 봅시다.

my $order = OrderFactory->fetch(%order_args);
my $invoice = $order->invoice;

 "order" 클래스가 여럿 있다면 어떤 클래스를 호출하고 컴파일 때 어떤 invoice 메소드를 호출하게 될까요?
 OOP 언어는 다형성을 위해 런타임 전에 호출자($order)에 대한 메소드(invoice)를 바인딩하지 않습니다.

 느린 바인딩이란 뭘까요? invoice 메소드의 '존재 여부'를 한 번 볼까요? Java같은 언어는 메소드가 존재하지 않으면 컴파일조차 안 합니다. 최소한 메소드가 존재해야 하고, 호출할 수 있는지 확인합니다.

 많은 동적 언어, 예를 들면 Perl같은 경우 코드를 실행할 때까지 메소드를 호출자에 바인딩하지 않으므로 컴파일 문제가 안 납니다.
 당신은 새벽 2시 경에 배치 프로세스가 실패했다는 당혹스러운 전화를 받습니다. 아까 회사에서 캡슐화는 해뒀는데 독립성 처리를 못했을지도요.
 이런! 이런 게 바로 검사를 거의 거치지 않는 "매우" 느린 바인딩입니다.

 Java같은 정적 언어는 '타입을 식별자에 바인딩'하기 때문에 다른 타입의 값을 할당할 수 없습니다.
 하지만 Perl, JavaScript 같은 동적 언어는 '값 자체에 타입을 바인딩'합니다. 값은 타입을 알지만 변수는 타입을 모릅니다. 이것이 "느린 바인딩"입니다.

// JavaScript
const str = "hello" // str 식별자에는 타입에 대한 정보가 없고 "hello" 값을 통해 타입을 판단합니다.

// Java
int num = 1; // 선언부에 int라고 적음으로서 num 식별자 자체에 타입이 바인딩됩니다. 이를 통해 컴파일이 정교합니다.

 그는 느린 바인딩이 있으면 문제 해결을 위한 "유일한 길"을 미리 확정하지 않고 실행 중간에 변수가 발생해도 시스템이 스스로 판단, 정정하기 때문에 좋다고 말합니다. 프로그램을 변경하면 실행을 정지하고 재시작하고, 복잡한 컴파일을 다시 기다리느라 몇 시간을 허비하던 시절이 기억나나요?

메시징

 독립성과 느린 바인딩은 이제 알 듯합니다. 이제 케이가 가장 중요하다고 강조했으며, 여전히 많은 사람들이 간과하는 "메시징"을 봅시다.
 객체는 자신이 어떤 작업을 했는지 알리고, 다른 객체는 이를 무시하거나 "아주 좋아."라고 맞장구쳐야 합니다.

 많은 개발자들이 공감은 합니다. 하지만 이론만 알기보단 구체적인 증명도 봐야 공감을 사기 좋습니다. 그래서 저는 케이 박사가 조금 모호하게 말했다고 생각합니다. 그가 말하는 객체 지향은 '모든 객체가 컴퓨터 그 자체' 같습니다. 각 객체마다 메시지를 수신하고, 이해하고, 스마트하게 처리합니다.

 다시 말해서, 이름을 부르면 정해진 역할만 실행하는 게 아니라 객체에 메시지를 보내면, 객체는 어떻게 반응할지 고민, 판단합니다. 이러한 알고리즘은 독립성을 강화합니다. 수신하는 측의 객체는 못 알아들을 메시지는 무시하기 때문입니다. 많은 사람들에겐 익숙하지 않은 패러다임이지만, 강력합니다.

 “중요한 건 메시징일세. 훌륭하고, 성장하는 시스템을 만들려면 모듈이 무슨 자원과 동작을 가질지보다, 모듈들이 어떻게 소통하냐를 설계하는 게 핵심이야.
 인터넷이 살아있으려면 두 가지가 필요해.

1. 표준을 넘어서서 여러 종류의 아이디어와 구현을 허용.
2. 아이디어 간 여러 수준의 안전 상호 운용성 허용.

 자네가 메시징에만 집중한다면 (그리고 좋은 메타시스템이 객체에서 쓰는 2nd level 아키텍쳐를 느리게 바인딩할 수 있다는 점을 이해한다면) 이 스레드에서 여러 언어, UI, OS에 기반한 논의는 무의미할 거야.”

 - 앨런 케이가 -

아래부터는 Quora에 올라온 질문에 앨런 케이가 대답한 것입니다.

 “66년 말 대학원 첫 주에, 저는 우연히 Sketchpad와 Simula를 접했고 생물학적 구조와 네트워크 상의 컴퓨터, 같은 시간을 공유하는 프로세스들, 시스템의 각 부분들이 상호작용하는 모습들을 보면서「기본적이고, 보편적인 단위로서의 컴퓨터」에 대한 실마리를 얻었습니다. 그로부터 동적 언어를 고려했고, 어떻게 해야 효율적이고, 간결하고, 보편적으로 프로그래밍할 수 있을지 고민했습니다.

 1960년 대에는 배열보다 복잡한 소프트웨어 복합체를 종종 '객체'라고 불렀습니다. 어느날 누가 뭐하냐고 물었고, 전 별 생각 없이「객체 지향 프로그래밍」이라 대답해버렸습니다. (여러 이유로 매우 나쁜 단어 선택이었지만, 이미 배는 떠나버렸습니다.)

 '객체'는 제 의도와는 다르게 활성적이지 못했고 '데이터'를 연상시키는 나쁜 단어였습니다. Simula는 인스턴스를 '프로세스'라 불렀는데 그게 차라리 낫더군요. "프로세스 지향 프로그래밍, 메시지 지향 프로그래밍, 서버 지향 프로그래밍"이라고 이름 붙이는 게 좋았을 것 같습니다.

 저는 프로세스 내부에서 상태 처리 방식을 은폐하되, 각 프로세스들을 서로를 위한 '서버'처럼 취급하고 싶었어요. 저는 그런 의도를 전달하고 싶었습니다.”

 “"객체"를 이해하려면 각 객체가 아이디어라고 생각해보세요. 요청(명령 X)에 대해 유의미한 반응들을 가진 아이디어요. 차등 권한을 가진 서버처럼요.
 이렇게 하면 큰 시스템을 실행하는 중에도 안전하고 다양하게 확장하고, 재구성을 할 수 있습니다.(문제를 해결하거나 변경하기 위해 시스템을 중단해야 한다면, 시스템 설계가 잘못된 겁니다.)”

 “좋든 나쁘든, 여러 이유로 C++은 큰 인기를 얻었습니다. C++은 "객체 지향 언어"라는 평가를 받았고, 많은 사람들이 그렇게 얘기합니다. 하지만 제가 생각한 OOP와는 많이 동떨어져 있습니다.
 이는 "객체 지향"의 "식민지화" 중 하나였습니다. 80년대 말에 "객체 지향"은 일종의 유행이었습니다. 온갖 분야에서 너무 쓰는 바람에 Parc의 소프트웨어는 "객체 지향"이라는 말로 설명할 수 없어졌고, "진짜 객체 지향"이라는 말까지 써야 했습니다.”

 “(적어도 제 생각에는) OOP는 패러다임에 국한할 게 아닌, 그보다도 더욱 실행성이 좋은 '보편적 정의' 체계이고, 대규모 시스템을 정의할 때 적합합니다. ”

1. '누군가한테' 메시지를 보낼 때, 그 메시지는 어떤 건지 생각해보세요. 명령인지, 요청인지, 제안인지, 협상인지.
2. '누군가한테' 메시지를 보낼 수는 있지만, 도중에 수신자나 송신자의 마음이 바뀔 수도 있습니다.
3. 메시지를 보낼 때, 정말로 특정 대상에게만 보내고 싶은지 다시 생각해보세요. 필요에 따라서는 '요청'을 보내거나, 공동체에 x,y,z를 공급할 수 있다고 시스템에게 알리는 게 나을 수도 있습니다.

 “보호되는 모듈, 명령이 아닌 메시지, 함수형 관계. 이 개념들 사이에선 충돌이 전혀 없어야 함을 유념하세요.
 개인적으로 추천하는 휴리스틱은「시스템을 생각」하지 말고「생물학적으로 생각」해보세요. 세포를 객체라고 생각하면 중요한 원리들이 많이, 금방 떠오릅니다.”

 “객체들이 서로 어떻게 통신할지 생각해보세요. 전송할 메시지의 단순함, 풍부함, 모듈의 무결성, 투명성...이것들을 어떻게 프로그래밍해야 한계를 뛰어넘을 수 있을지 고민해보세요.”

 “느린 바인딩은 유연성과 안전성을 유지하는 선에서 최대한 다양한 방안을 마련하잔 의도입니다. 캡슐화된 객체는 "어떻게(메소드)"를 느리게 바인딩하고 "무엇(의미)"을 사용함으로서 다양한 대안과 투명성을 구현합니다. ”

 “올해는 제가 "비 명령형 메시지로 소통하는 캡슐화된 서버"들로 무엇이든 만들어낼 수 있다는 단순한 생각의 힘을 "인식"한지 50주년이 되는 해입니다.

 “선언적 프로그래밍을 생각할 관점 중 하나는 "어떻게"와 "무엇"을 구분하는 것입니다. 역사적으로 프로그래밍은 "어떻게"에서 시작했고, 프로그램은 주어진 자원과 도구로 원하는 결과를 도출하기 위한 전술이었습니다. 설계도 없이 순서대로 집을 짓는 격이었죠.

 건축 현장에선 거의 항상 "무엇"을 염두에 둡니다. 본 작업을 하기 전에 구현을 먼저 하죠. 예를 들면 집 설계도나, 섬세한 미니 모형이요. 그런 것이 "선언적인 내용"입니다. 사람은 그걸 보면서 목표를 위한 전술을 구성하고요. 그렇게 해서 전술/방법은 전략/계획을 참조하고, 비교하고, 상황을 판단합니다.”

확장성

 소규모 프로젝트에도 자주 마주칠 수 있는 문제 중 하나는 확장성이다. 거의 비슷하거나 흐름은 같은데도, 완전히 동일하지 않으면 재사용이 어려운 코드가 많다. 구현 사항 자체는 같은데도 UI가 다르다는 이유만으로 코드를 새로이 작성해야 하면 입맛이 씁쓸하다.

 이러한 경우, 구현 사항이 똑같기 때문에 변경도 똑같이 시행해야 하는데 실수 확률이 높아진다. UI와 로직을 독립적으로 구분하되, 재사용을 고려해서 설계해야 할 때가 있다. 아토믹 디자인 패턴으로 UI를 잘게 나눠 재사용할 수 있고, 레이어에 따로 함수를 API처럼 모아둘 수도 있다. HoC로 감싸서 경우에 따라 선택적으로 컴포넌트를 표시하도록 설정하는 방법도 있다.
 방법은 가지각색이지만, 이러한 고민과 해결들 속에도 객체 지향의 정신이 포함돼있다고 생각한다.

마무리

 의사, 약사가 각각 한 명 뿐이라면, 그리고 의사나 약사에게 무슨 일이 생겨서 제 일을 못하게 된다면 전체적인 작업 흐름이 끊길 것이다. 그렇기 때문에 의사 B, 약사 B, C에게 찾아갈 수 있도록 그때그때 상황에 맞출 수 있도록 느린 바인딩, 여러 대안이 필요하다.

 소스 코드는 위에서 아래로 순차적으로 흐른다. 고수준에서 결정을 내리고, 저수준에서는 세부적인 처리를 한다.
 앨런 케이는 프로그램이 변화에도 부드럽고 쉽게 적용, 확장되길 바랬고 그의 정신은 로버트 마틴이 제안한 SOLID 원칙에서도 조금이나마 계승됐다고 생각한다.

1. [단일 책임]: 각자가 자기만의 유일한 책임을 가지고,
2. [개방 - 폐쇄]: 확장이 일어날 때에는 변질 없이 양만 늘어나고,
3. [리스코프 치환]: 대체가 가능한 개체들은 서로가 딱 맞게 치환이 되고,
4. [인터페이스 분리]: 불필요한 것 없이, 정말 필요한 것만 요청해서 협력하고,
5. [의존성 역전]: 작은 개체 때문에 전체, 상위가 휘둘리는 일 없이, 상위 개체, 상위 메시지를 중심으로 여러 개체들이 움직이고 소통한다.

참조

• Alan Kay and OO Programming
• Alan Kay On Messaging
• What did Alan Kay mean by, "I made up the term object-oriented, and I can tell you I did not have C++ in mind."?
• Why is object-oriented programming more about messaging than objects?
• I read somewhere that object-oriented programming was coined by Alan Kay circa 1966 or 1967 while he was at grad school. Has anyone influenced/contributed Alan to coin such a term?
• What does Alan Kay think about inheritance in object-oriented programming?
• In object-oriented programming, why is it bad practice to make data members public when the get() & set() public members modify it anyway?
• What is the significance of late binding?
• If one starts with a state of the art object-oriented programming from the late 80s and early 90s (Smalltalk, Self, CLOS), what could have been the next breakthrough in that style of programming, but never happened?
• What's the best way of combining functional and OO programming in practice?
• What is Alan Kay's definition of Object Oriented?

HTML, CSS, JavaScript만으로 간단한 페이지네이션을 구현한다.

페이지네이션을 하려면 무슨 기능들이 필요할까?

• 테이블에 펼칠 데이터 fetch.
• 2번 버튼 클릭 시:
  2번 버튼 색 변경. 1번 버튼 색 원래대로.
  2번 버튼에 적합한 테이블 데이터 호출.
• 드롭다운 클릭 시:
  15를 클릭 시 데이터가 15개씩 보이도록 변경
  5를 클릭 시 데이터가 5개씩 보이도록 변경
  보던 index에 맞춰서 active index 변경

 이 페이지네이션은 프로그래머스에서 제시한 제한시간 4시간짜리 연습 문제다. 요구사항에 맞춰서 구현 중, 고민이 들었다.

 ‘이래도 되나?’

 물론 실전에선 시간 내 요구 사항 충족이 최우선이다. 그러나 그건 기출 문제일 뿐이고, 나는 공부가 필요했다.
 나는 바닐라 자바스크립트로 좋은 코드를 짤 수 있을까? 내가 아는 지식으로 좋은 페이지네이션을 구현할 수 있을까?

 코드를 다시 보니 지식을 어설프게 활용하는데다, 각 함수가 서로 얽혀서 함수 이름에 걸맞지 않는 사이드 이펙트가 여기저기 뒤섞여 있었다.
 화면만 보면 적당히 작동하지만, 코드가 쓸데없이 복잡했다. 계획과 정리가 부족한 채 서두르고 있었다.

 뒤죽박죽이다. 코드를 수정할 때마다 에러가 나기 일쑤였다. 설령 마지막에 잘 동작이 되더라도, 이렇게 하면 안 된단 생각이 들었다. 정리해서 다시 짜보기로 했다.

 handleClick 이벤트 등록은 변경될 일이 없는 부모 노드에 등록했다.

• case 1: 숫자 버튼도 아니고, 화살표 버튼도 아니라서 아무 반응도 해선 안 된다.
• case 2: 숫자 버튼에 맞게 index를 변경한다.
• case 3: 첫 버튼이 눌리면 index를 0으로, 마지막 버튼이 눌리면 마지막 index로 변경.

 case 1을 감수하면서 부모 노드에 이벤트를 등록한 이유는 그게 편했기 때문이다. 내부 숫자 버튼들은 per가 바뀔 때마다 생성해야 하고, 그 때마다 이벤트를 재등록하는 코드를 넣고 싶진 않았다.
 이와 같은 코드는 이벤트 버블링 덕분에 구현할 수 있다.

 실제 이벤트는 버튼에서 일어나지만 버튼 자체에는 아무런 기능이 없다. 하지만 이벤트 버블링을 통해 클릭 이벤트가 상위 노드로 올라가기 때문에 부모 노드가 이벤트 핸들링 함수를 실행한다.

(async () => {
  fetch("./src/data.json")
    .then((res) => res.json())
    .then((result) => {
      data = result;
      setIndex(0);
    });

  let data;
  let index = 0;
  let per = 5;
  const tbody = document.querySelector("tbody");
  const btnBox = document.querySelector(".pagination");
  const select = document.querySelector("#dropdown");

  const lastIndex = () => Math.ceil(data.length / per) - 1;

  //? index에 맞는 데이터, 데이터 길이 반환
  const getDataAndLength = () => {
    let next = (index + 1) * per;
    if (next > data.length) next = data.length;
    const newData = data.slice(index * per, next);
    return [newData, newData.length];
  };

  //? index 변경 => active, table 변경.
  const setIndex = (newIndex) => {
    index = newIndex;
    const [data, length] = getDataAndLength();
    resetTable(length);
    setActive(index);
    setTable(data);
  };

  //? per 비교 변경 => 버튼 컨테이너, 테이블 reset
  const setPer = (newPer) => {
    if (per === newPer) return;
    const newIndex = Math.ceil((per * index + 1) / newPer) - 1;
    per = newPer;
    resetButtons(lastIndex() + 1);
    setIndex(newIndex);
  };

  //? active 버튼 교체
  const setActive = (index) => {
    document.querySelector(".active")?.classList.remove("active");
    const target = document.querySelectorAll(".button")[index];
    target.classList.add("active");
  };

  //? 테이블 내용 주입, 변경.
  const setTable = (data) => {
    const trs = tbody.querySelectorAll("tr");
    for (let i = 0; i < trs.length; i++) {
      const tds = trs[i].querySelectorAll("td");
      const props = Object.values(data[i]);
      for (let j = 0; j < tds.length; j++) {
        tds[j].textContent = props[j];
      }
    }
  };

  //? 테이블 HTML 생성.
  const resetTable = (length) => {
    const tr = "<tr><td></td><td></td><td></td><td></td></tr>";
    const newHTML = tr.repeat(length);
    tbody.innerHTML = newHTML;
  };

  //? 버튼 컨테이너 HTML 생성.
  const resetButtons = (last) => {
    let buttons = "";

    for (let i = 1; i <= last; i++) {
      buttons += `<button class="button">${i}</button>`;
    }

    const newHTML = `<button class="start"><<</button>
  ${buttons}
  <button class="last">>></button>`;

    btnBox.innerHTML = newHTML;
  };

  const handleSelect = (event) => {
    const newPer = Number(event.target.value);
    setPer(newPer);
  };

  //? target이 버튼이면 setIndex
  const handleClick = (event) => {
    const target = event.target.classList.value;
    if (target === "pagination") return;

    switch (target) {
      case "start":
        setIndex(0);
        break;
      case "button":
        const targetIndex = Number(event.target.innerHTML) - 1;
        setIndex(targetIndex);
        break;
      case "last":
        setIndex(lastIndex());
        break;
      default:
        break;
    }
  };

  btnBox.addEventListener("click", handleClick);
  select.addEventListener("click", handleSelect);
})();

 그러나 setIndex, setPer에 여러 함수들을 붙여서 리렌더링하는 모습이 사이드 이펙트와 다름이 없다. 게다가 index, per를 여기저기서 너무 편하게 가져다 쓴다. 내 의도와는 거리가 있다.

(async () => {
  let data;

  fetch("./src/data.json")
    .then((res) => res.json())
    .then((result) => {
      data = result;
      render(data);
    });

  const { getIndex, setIndex, getPer, setPer, isStateUpdated } = (() => {
    let prevState = {
      index: undefined,
      per: undefined,
    };

    let currentState = {
      index: 0,
      per: 5,
    };

    const getIndex = () => currentState.index;
    const setIndex = (newIndex) => {
      setState(newIndex, currentState.per);
    };

    const getPer = () => currentState.per;
    const setPer = (newPer) => {
      setState(currentState.index, newPer);
    };

    const setState = (index, per) => {
      if (currentState.index === index && currentState.per === per) {
        return;
      }

      if (currentState.per !== per) {
        prevState = { ...currentState };
        currentState = { index: 0, per };
      } else {
        prevState = { ...currentState };
        currentState = { index, per };
      }
      render();
    };

    const isStateUpdated = () => {
      if (
        (prevState.index !== currentState.index) |
        (prevState.per !== currentState.per)
      ) {
        return true;
      } else {
        return false;
      }
    };

    return { getIndex, setIndex, getPer, setPer, isStateUpdated };
  })();

  const render = () => {
    if (isStateUpdated()) {
      const [index, per] = [getIndex(), getPer()];
      const [tableData, tableSize] = getTableDataAndSize(index, per, data);
      const buttonIndexes = Math.ceil(data.length / per);
      resetButtons(buttonIndexes);
      resetTable(tableSize);
      setTable(tableData);
      setActive(index);
    } else {
      return;
    }
  };

  //? index에 맞는 테이블 컨텐츠
  const getTableDataAndSize = (index, per, data) => {
    let next = (index + 1) * per;
    if (next > data.length) next = data.length;
    const newData = data.slice(index * per, next);
    return [newData, newData.length];
  };

  //? 버튼 active 업데이트
  const setActive = (index) => {
    document.querySelector(".active")?.classList.remove("active");
    const target = document.querySelectorAll(".button")[index];
    target.classList.add("active");
  };

  //? 테이블 업데이트
  const setTable = (tableData) => {
    const tbody = document.querySelector("tbody");
    const trs = tbody.querySelectorAll("tr");
    for (let i = 0; i < trs.length; i++) {
      const tds = trs[i].querySelectorAll("td");
      const props = Object.values(tableData[i]);
      for (let j = 0; j < tds.length; j++) {
        tds[j].textContent = props[j];
      }
    }
  };

  //? 테이블 HTML 생성.
  const resetTable = (tableSize) => {
    const tr = "<tr><td></td><td></td><td></td><td></td></tr>";
    const newHTML = tr.repeat(tableSize);
    document.querySelector("tbody").innerHTML = newHTML;
  };

  //? 버튼 컨테이너 HTML 생성.
  const resetButtons = (buttonIndexes) => {
    let buttons = "";

    for (let i = 1; i <= buttonIndexes; i++) {
      buttons += `<button class="button">${i}</button>`;
    }

    const newHTML = `<button class="start"><<</button>
  ${buttons}
  <button class="last">>></button>`;

    btnBox.innerHTML = newHTML;
  };

  const handleSelect = (event) => {
    const newPer = Number(event.target.value);
    setPer(newPer);
  };

  //? target이 버튼이면 setIndex
  const handleClick = (event) => {
    const target = event.target.classList.value;
    if (target === "pagination") return;

    switch (target) {
      case "start":
        setIndex(0);
        break;
      case "button":
        const targetIndex = Number(event.target.innerHTML) - 1;
        setIndex(targetIndex);
        break;
      case "last":
        const lastIndex = document.querySelectorAll("button").length - 3;
        setIndex(lastIndex);
        break;
      default:
        break;
    }
  };

  const btnBox = document.querySelector(".pagination");
  const select = document.querySelector("#dropdown");
  btnBox.addEventListener("click", handleClick);
  select.addEventListener("click", handleSelect);
})();

 코드 수는 늘어났지만 원하는 모습에 많이 가까워졌다. 각 함수들이 주석과 이름에 맞춰서 역할에 집중한다.
 이게 최고라는 생각은 안 한다. 하지만 내 수준에선 정성과 고민을 들였다.

• index, per 는 각 함수들이 공용으로 사용. 그러나 함부로 수정 불가능.
• 실시간 데이터 업데이트가 발생할 일은 없으므로 data는 처음에 한 번만 받는다.
• 사이드 이펙트 지양, 의존성 주입, 함수 외부에 변수 선언 최소화
• 함수는 제 할 일에 집중.
  (에러가 나더라도 해당 영역에서만 에러. 다른 곳까지 여파가 안 미침)
• 최적화는 신경을 덜 씀.
  (섣부른 최적화는 독만 된다. 정상 작동과 괜찮은 가독성에 초점을 맞췄다.)

 작년에 페이지네이션을 구현할 땐 도저히 모르겠어서 남들이 구현한 페이지네이션 코드를 따라해야만 했다. 이번엔 검색 없이 순전히 내 지식과 생각으로만 구현했다.
 프로그래머스에선 리액트 비스무리하게 만드는 것을 유도하는 듯하다. index.js와 App.js, 그리고 각 컴포넌트 파일들을 통해 새로 렌더링하는 코드를 해설로 제공한다.

마무리

 배움은 의문에서 비롯한다. 특정 패러다임을 염두한 건 아니지만 "어떻게 해야 이 프로그램이 더 원활하게 작동하고, 쉽게 추가하고, 쉽게 고칠 수 있을까?"를 고민하고, 머릿속으로 그려보면서 구현도 구현이지만 설계가 중요하단 느낌을 많이 받았다. 패러다임, 디자인 패턴 등은 이러한 고민에서 시작했고, 지금도 꾸준히 태어나고, 연구된다.

 왜 설계를 알아야 하고 많이 고민해야 할까? 예전부터 중요하다는 이야기는 많이 들었지만 그걸 "제대로" 실감하진 못했다.
 이번 연습 문제는 매우 간단한 구현을 할 뿐인데 가장 많이 든 생각은 이랬다.

 ‘이거 정말, 설계가 필요한데.’

 단순히 구현만 해놓고 끝낼 것이면 모르겠으나 그 구현체를 계속 관리하고, 남에게 서비스하고, 규모를 넓힐 예정이 있다면 얘기는 달라진다.

 학원에서 팀 프로젝트를 할 때, 우리에게 주어진 시간은 적었고, 우리는 급한 나머지 기획과 설계를 얼렁뚱땅 얼버무린 채 코드 더미를 쏟아냈다. 진척은 느렸고 분위기는 혼란스러웠다.
 코치는 우리가 정말로 충분히 이야기를 나눴는지, 모두가 공감했는지, 밑준비를 했는지 돌아보게끔 조언을 줬다. 우리는 정신을 차리고 처음부터 다시 기획하고 준비를 해서 짧은 기간에 (나름대로는) 만족스러운 결과물을 만들어냈다.

 테스트도 그렇다. 테스트는 "내가 구현해둔 게 의도대로 작동하는지 재확인"하는 게 아니다. "무엇"을 할 때마다 테스트는 내 설계를 검증한다. 내 설계도를 돌아보고, 더 나은 설계를 고민하게 만든다. 그래서 테스트를 작성하며 프로그래밍하길 권장하는 것이고, 그래서 TDD가 주목받았다.

 프로그래밍은 설계가 매우 중요하다. 충분한 설계를 하고 쌓아 올리는 단계에서도 수시로 설계를 확인하며 상황에 맞는 판단을 내려야 한다. HTML, CSS, JS만으로 무언가를 만들 일이 얼마나 있겠냐마는, 이번 연습 문제를 통해서 여러 고민을 머릿속에 담아본다.

 이 글은 함수 컴포넌트와 훅을 다룹니다.

 페이스북은 심각해지는 사용자 경험과 개발자 경험을 해소하느라 리액트를 만들었지만 그 뒤에도 문제가 생겼습니다. 바로 클래스 컴포넌트입니다.

 클래스 컴포넌트를 만들려면 많은 보일러 플레이트 코드를 써야 합니다. 신규, 중견 개발자들이 클래스 컴포넌트는 복잡하고 짜증난다는 말을 많이 해요.
...
 클래스 컴포넌트는 사람들한테만 어려운 게 아니라 기계들도 어려워해요. 컴파일도 길어지고 복잡해지거든요.
...
 (클래스 컴포넌트의) 문제는 상태나 생명 주기 코드를 추가할 때 쓸만한 쉽고 가벼운 원리가 없었어요.
 - 2018 리액트 컨퍼런스 -

 함수 컴포넌트는 초보 개발자들을 위한『옵션』이 아니라 개선 목적으로 나왔습니다.

2. useState

“useState는 클로저를 활용하고 setState는 비동기 실행이다.”

 클래스 → 함수형으로 바뀐 게 얼마나 다행인지 잠시 보겠습니다.

class Counter extends Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 0,
    };
    this.handleClick = this.handleClick.bind(this);
  }

  handleClick() {
    this.setState({ count: this.state.count + 1 });
  }

  render() {
    return (
      <>
        <span>{this.state.count}</span>
        <button onClick={this.handleClick}>Click me</button>
      </>
    );
  }
}

class Counter extends Component {
  state = { count: 0 };

  handleClick = () => {
    this.setState({ count: this.state.count + 1 });
  };

  render() {
    return (
      <>
        <span>{this.state.count}</span>
        <button onClick={this.handleClick}>Click me</button>
      </>
    );
  }
}

const Counter = () => {
  const [count, setCount] = useState(0);
  const handleClick = () => {
      setCount(count + 1);
  }

  return (
      <>
        <span>{count}</span>
        <button onClick={handleClick}>Click me</button>
      </>
  );
}

2-1. 상태로 업데이트.

 클래스형의 render, 함수형의 return은 컴포넌트를 렌더링합니다.
 가상 DOM은 무슨 일이 발생하면 상태 변경을 기준으로 전후 객체를 얕게 비교하고 업데이트를 결정하는데, 그 때문에 상태 값이 객체라면 주의가 필요합니다.

  const [obj, setObj] = useState({ name: "React", like: 1299 });
  const handleClick = () => {
    obj.name = "hahaha";
    setObj(obj);
    console.log(obj);
  };

  return (
    <>
      <button onClick={handleClick}>{obj.name}</button>
    </>
  );

객체는 가변성이어서 값만 바꾸면 참조값이 유지된다.
→ 가상 DOM은 상태에 변화가 없다고 생각하고 무시한다.
→ 이럴 땐 새 객체를 만들어서 할당한다.

  const [obj, setObj] = useState({ name: "React", like: 1299 });
  const handleClick = () => {
    const name = "hahaha";
    const newObj = { ...obj, name };
    setObj(newObj);
    console.log(obj);
  };

  return (
    <>
      <button onClick={handleClick}>{obj.name}</button>
    </>
  );

3. useEffect

“비동기라서 많이 쓰는 이펙트 훅.”

  componentDidMount() {
    document.title = `You clicked ${this.state.count} times`;
  }
  componentDidUpdate() {
    document.title = `You clicked ${this.state.count} times`;
  }

  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });

3-1. 의존성 배열

  useEffect(() => {
    document.title = `You clicked ${count} times`;
  },[]);

  useEffect(() => {
    document.title = `You clicked ${count} times`;
  },[count]);

3-2. 이벤트 등록 및 회수

useEffect(() => {
  function 마우스감지(e) {..}
  window.addEventListener("scroll", 마우스감지);
    return function cleanup() {
      window.removeEventListener("scroll", 마우스감지);
    };
}, []);

useEffect(() => {
  function 마우스감지(e) {..}
  window.addEventListener("scroll", 마우스감지);
    return () => {
      window.removeEventListener("scroll", 마우스감지);
    };
}, []);

3-3. 실행 타이밍

 “useEffect는 layout, paint가 끝나고 지연된 이벤트들을 처리할 때 실행합니다.”

 useEffect는 대체로 아래 타이밍에 실행합니다.

• 첫 렌더링(마운트) 이후
• 리렌더링 이후
• 컴포넌트 제거 후

 컴포넌트는 마운트 직후 paint도 순식간에 해서 화면에 나옵니다. 그 후로 useEffect가 비동기 실행됩니다.

 useEffect와 useLayoutEffect는 비슷하지만 미묘한 차이가 있는데 아래에서 자세히 쓰겠습니다.

4. useLayoutEffect

 “모든 DOM 변화가 끝나면 동기적으로 실행합니다. DOM에서 레이아웃을 읽어내 리렌더링하고 싶을 때만 쓰세요. componentDidMount(컴포넌트가 DOM 트리에 삽입된 직후), componentDidUpdate(브라우저가 repaint하기 전)과 동일한 시점에 발생합니다.”

“useLayoutEffect는 정말 필요할 때 쓰세요.”
- React -
“SSR, SSG에선 useLayoutEffect 사용에 주의하세요.”
- Next.js -

 useEffect와 useLayoutEffect는 거의 비슷하면서 다릅니다.

window.addEventListener("DOMContentLoaded", () => {
  console.log("DOM 트리 생성");
  console.log(window.document.documentElement);
});

window.addEventListener("load", () => {
  console.log("자원 로드");
  console.log(window.document.documentElement);
});

root.render(<App />);

function App() {
  const [effect, setEffect] = useState("App");
  const [layout, setLayout] = useState("App layout");
  console.log(`App 읽는 중...\n effect: ${effect},\n layout: ${layout}`);

  useLayoutEffect(() => {
    setLayout("App layout effect");
    console.log(
      `App useLayoutEffect 실행 \n effect: ${effect},\n layout: ${layout}`
    );
  }, []);

  useEffect(() => {
    setEffect("App side effect");
    console.log(`App useEffect 실행 \n effect: ${effect},\n layout: ${layout}`);
  }, []);

  return (
    <>
      <Child />
      {effect}
    </>
  );
}

const Child = () => {
  const [effect, setEffect] = useState("Child");
  const [layout, setLayout] = useState("Child layout");
  console.log(`Child 읽는 중... \n effect: ${effect},\n layout: ${layout}`);

  useLayoutEffect(() => {
    setLayout("Child layout effect");
    console.log(
      `Child useLayoutEffect 실행 \n effect: ${effect},\n layout: ${layout}`
    );
  }, []);

  useEffect(() => {
    setEffect("Child side effect");
    console.log(
      `Child useEffect 실행 \n effect: ${effect},\n layout: ${layout}`
    );
  }, []);

  return <div>{effect}</div>;
};

1. window, document에 이벤트 등록
2. DOMContentLoaded 실행
3. root.render 실행
4. App → Child 순으로 이펙트 훅은 등록만 하고 나머진 읽어낸다.
5. 다 읽은 잎 노드(Child)는 마운트, paint.
   잎 노드: 아래로 더 내려갈 게 없는 최하층 노드.
6. 모든 paint가 끝나면 useLayoutEffect 실행(자식 → 부모)
7. 모든 useLayoutEffect가 끝나면 useEffect 실행(자식 → 부모)
8. useLayoutEffect에서 등록했던 setState들 적용(부모 → 자식)
9. useEffect에서 등록했던 setState들 적용(부모 → 자식)
10. load 이벤트 fire

useEffect는 비동기 실행이라 타이밍이 유동적임을 염두합니다.
┖ useEffect로 UI 변경한다고 무조건 깜빡이진 않는다.
┖ 우선 작업 많으면 useEffect가 늦게 실행된다.

const Colorful = () => {
  const [isMount, setIsMount] = useState(true);
  useEffect(() => {
    setIsMount(false);
  }, []);

  return (
    <div className={isMount ? styles.red : styles.green}>안녕하세요</div>
  );
};

 useEffect로 UI 변경해도 문제 없이 작동할 때는 많습니다.

const Colorful = () => {
  const [isMount, setIsMount] = useState(true);

  useLayoutEffect(() => {
    queueMicrotask(() => {
      for (let i = 0; i < 20000; i++) {
        console.log(i);
      }
    });
  }, []);

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

  return <div className={isMount ? styles.red : styles.green}>안녕하세요</div>;
};

 이렇게 useEffect로는 도저히 방법이 없을 때에만 useLayoutEffect를 씁니다.

const Colorful = () => {
  const [isMount, setIsMount] = useState(true);

  useLayoutEffect(() => {
    for (let i = 0; i < 20000; i++) {
      console.log(i);
    }
  }, []);

  useLayoutEffect(() => {
    setIsMount(false);
  }, []);

  return <div className={isMount ? styles.red : styles.green}>안녕하세요</div>;
};

 렌더는 비동기 작업이므로 동기적 코드가 있으면 렌더를 무시하고 코드를 실행합니다.

 mount → paint → useLayoutEffect → update, repaint

 브라우저는 싱글 스레드이며 렌더링 과정에서 동기적 코드를 만나면 화면을 멈추고 코드 실행에 집중합니다.
 비록 컴포넌트를 마운트하고 빨간색으로 초기 paint를 했어도 뒤에 동기적으로 처리할 코드들이 대기중이면 브라우저는 판단을 합니다.

 →코드를 실행하자. O
 화면에 컴포넌트를 띄우자. X

 예를 들면 paint - composite 사이에 화면 색이 100만 번 바뀐다고 가정해봅시다. 일일이 렌더하면서 사용자에게 과정을 다 보여줄 필요가 있을까요? 차라리 최종 화면만 사용자에게 표시하는 게 합리적입니다.
 이런 이유로 useLayoutEffect는 사용자에게 초기 컴포넌트를 숨깁니다.

• 리액트: 마운팅 시 모든 코드를 읽고 처리하느라 초기 로딩이 늦다.
• Next.js: 각 컴포넌트를 순회하면서 컴포넌트 이름으로 조회하여 서버에서 만들어둔 HTML을 빠르게 가져온다. 이후 다시 순회하면서 클라이언트 코드 실행.

5. useInsertionEffect

 “useInsertionEffect는 리액트가 DOM을 바꾸기 전에 발생합니다. CSS-in-JS 라이브러리로 동적 CSS를 할당합니다.”

 동적으로 CSS를 할당할 일은 많지 않을 뿐더러, 공식 문서에서도 사용에 신중을 기하라고 주의를 합니다. 렌더링을 지연시키기 때문입니다.

6. useRef

 바닐라 JS로 DOM 노드를 조작할 땐 아래와 같이 작성합니다.

const button = document.querySelector("button");
button.addEventListener("click", ()=>{..});

 가끔 리액트로도 엘리먼트를 가져올 일이 있습니다. (엘리먼트 크기를 잰다던지)
 querySelector 대신 useRef를 쓰면 엘리먼트를 가져올 수 있습니다.

  const target = useRef<HTMLDivElement>(null);

  useEffect(() => {

// 'target.current' is possibly 'null'.
    const width = target.current.offsetHeight; 

// 정상 작동.
    if(target.current){
      const width = target.current.offsetHeight; 
    }
  });

  return (
    <>
      <div ref={target}>this is div box</div>
    </>
  );

 useRef를 쓰고, 엘리먼트에 ref를 등록하면 됩니다.
 ref는 null이었다가 코드 실행중, 마운트 전에 업데이트됩니다.(생명 주기 그림 참고)
 타입스크립트 개발 코드에선 ref가 null로서 인식됩니다. (런타임 전에는 참조된 게 없기 때문) 그래서 if문 등으로 ref.current가 있다고 가정해야 경고가 안 뜹니다.

6-1. 다른 용도

 useRef는 변수 담을 때에도 씁니다.
특징: 값을 바꾼다고 리렌더링 X, 리렌더링 때 값을 다시 할당 X.
원리: 내부적으로 참조값을 유지하는 객체를 쓰기 때문.

 '리렌더링마다 할당하긴 좀 그런 변수.'에 씁니다. 이미 비용이 드는 값을 캐시하는 훅 useMemo가 있으므로 구분해서 씁시다.

7. 참조

• React Docs Beta
• React
• React Today and Tomorrow and 90% Cleaner React With Hooks

 우리가 사이트에서 회원 가입 버튼을 누르면 브라우저는 서버에게 보내기 위한 회원 정보를 포장합니다.

 "데이터 포장은 왜 하지?"

 친구에게 택배 보내는 상황을 떠올려보면 쉽습니다. 책을 힘껏 던져서 친구 집 창문 틈새로 절묘하게 떨어지면 좋겠지만, 누구도 그렇게 할 초능력은 없습니다. 그래서 우리는 택배를 이용합니다.

 데이터도 마찬가지입니다. 여러 포장을 씌워야 정상적으로 보낼 수 있습니다. 이런 포장을 패킷이라 부르고, 패킷은 여러 가지가 있습니다.
 옛날엔 업체들이 자기들만의 통신법을 써서 타사, 타기종 간 통신 호환이 엉망이었습니다. 그래서 국제 표준 협회에서 표준 통신 규약 (OSI 참조 모델 7계층)을 만들었고, 요즘은 간소화한 TCP / IP 4계층 표준을 많이 씁니다.
 이름은 TCP/IP 4계층 모델이지만 FTP, SMTP 등 여러 프로토콜도 포함됩니다. (TCP, IP는 데이터를 처리 절차지만 패킷을 가리킬 수도 있습니다.)

TCP

 TCP에선 데이터 흐름(순서)를 제어하며 정확성을 검사합니다.

1. 접속되는지 확인(SYN)
2. 접속 가능하면 서버는 응답 & 정보 보내라고 요청한다.(ACK, SYN)
3. 클라이언트는 요청을 수락하고, 정보를 보낸다.

 만약 데이터에 오류가 있으면 상호 소통해서 데이터를 재전송, 재결합한다.
 TCP는 데이터 신뢰를 보장하는 절차다. 단점은 확인 절차 때문에 시간이 조금 걸린다.

3-2. TCP/IP 4계층

1. 데이터 생성(어플리케이션 계층)
   예: 쇼핑몰(어플리케이션)에서 회원 정보(데이터)를 입력
2. TCP, 혹은 UDP로 포장(전송 계층)
   TCP: 정확한 전송과 피드백. 데이터 신뢰 부여.
   UDP: 빠른 전송. 미디어 통신 등 빠르게 전송하기만 하면 되는 곳에 사용.
3. IP 헤더 추가. IP 주소가 있고 데이터 보내는데 중점. (인터넷 계층)
4. 네트워크 접속 계층에선 물리적 주소(Media Access Control 주소)를 담는다. MAC 주소는 회사에서 호스트를 구별하려고 개별적으로 할당하는 고유한 식별 번호다. 이더넷처럼 물리적인 주소로 통신할 때 쓰기 때문에 일반적으로 MAC 주소를 쓰는 경우는 많지 않아서 생략되는 단계이기도 하다.

 서버의 인터넷 계층은 IP 패킷을 검사하고 전송 계층에 보낸다.
 전송 계층은 데이터 정확성 등을 체크(TCP)

3-3. IP와 PORT

 IP는 한 개 뿐이라서 여러 서비스를 이용하기 힘들다. 그래서 port를 추가
 유명한 포트 번호는 443(https, 보안)
 IP가 도시라면 port는 항구다. 도시에서 교역을 하려면 1번 항구로 가고, 배를 수리하려면 2번 항구로 가는 식이다.

3-4. 도메인

 IP는 123.100.001.211 이런 식으로 구성되어있는데 저렇게 주소를 입력해서 접속하려면 일일이 기억하기가 힘들다.
 DNS(Domain Name System)를 이용하면 도메인이 IP 주소로 변환되어서 접속한다.
 1. 클라이언트가 도메인을 입력하면 로컬 DNS에 캐시를 확인
 2. 없으면 Root 서버에 확인
 3. TLD 서버 등 여러 서버를 거쳐서 도메인에 매핑되는 IP 수령
 4. 해당 IP에 접속

3-5. URI

Uniform: 구분한다.
Resource: 자원을,
Identifier: 식별자로.

 URI는 보통 아래와 같은 형식을 가진다.(port라던지, 생략되는 부분도 있다.)
schema://host/path?query=...
  coffee png라고 검색하면 구글은 아래와 같은 URI로 검색한다.

https://www.google.com/search?q=coffee+png&tbm=isch&ved=2ahUKEwj69szC3Zj2AhUEJqYKHfzXCPEQ2-cCegQIABAA&oq=coffee+png&gs_lcp=CgNpbWcQAzIICAAQgAQQsQMyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQ6BwgAELEDEEM6BAgAEEM6CggAELEDEIMBEENQ_gNY5Qxg2w1oAXAAeACAAdYBiAGJCJIBAzItNZgBAKABAaoBC2d3cy13aXotaW1nwAEB&sclient=img&ei=Xa4XYrrUAoTMmAX8r6OIDw&bih=856&biw=1381&hl=en

 만약 개발하다가 URI를 작명한다고 하면 리소스를 기준으로 하면 좋다.

• /create/user... [X]
• /user [O]

 모든 URI를 리소스 기준으로만 만들기란 생각보다 쉽진 않다. 위의 구글 예시도 그렇다. /search같은 건 컨트롤 URI다. 동사로 만드는 편.
 똑같은 URI에서 회원 가입도 하고, 회원 조회도 하길 원하면 HTTP 메소드(GET,POST 등)를 사용한다.

4. HTTP 메소드

안전성(Safe) : 해당 메소드를 호출해도 리소스는 변하지 않는다.
멱등성(Idempotent) : 해당 메소드를 몇 번 호출해도 결과는 동일하다.
캐시 가능(Cacheable) : 해당 메소드는 호출했을 때 캐싱 가능하다.

• GET : 데이터 조회할 때 사용.
• POST : 리소스 신규 등록(URI 몰라도 됨. 서버가 알아서 URI 등록), 정보를 가지고 작업하거나 처리, 조회, 수정할 때 등 다용도
• PUT : 리소스 신규 등록(클라이언트가 URI를 알고 입력해야 됨), 정보 수정(일부 내용 변경할 때엔 PATCH가 더 취지에 맞음. PUT은 기존의 데이터를 다 날려먹기 때문.)

POST처럼 서버가 URI를 만들고 관리하는 디렉토리는 Collection,
PUT처럼 클라이언트가 URI를 알고 관리하는 디렉토리는 Store라 부른다.

4-1. REST API, RESTful API

 REST는 REpresentational State Transfer의 줄임말로 개발자가 HTTP 통신 기반으로 API를 만들 때 염두하길 권장하는 규칙이다. IBM에선 아래와 같이 알려준다.

1. 균일한 인터페이스. 요청이 어디에서 오는지와 무관하게, 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 합니다. REST API는 사용자의 이름이나 이메일 주소 등의 동일한 데이터 조각이 오직 하나의 URI(Uniform Resource Identifier)에 속함을 보장해야 합니다. 리소스가 너무 클 필요는 없지만, 이는 클라이언트가 필요로 하는 모든 정보를 포함해야 합니다.
2. 클라이언트-서버 디커플링. REST API 디자인에서, 클라이언트와 서버 애플리케이션은 서로 간에 완전히 독립적이어야 합니다. 클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI이며, 이는 다른 방법으로 서버 애플리케이션과 상호작용할 수 없습니다. 이와 유사하게, 서버 애플리케이션은 HTTP를 통해 요청된 데이터에 전달하는 것 말고는 클라이언트 애플리케이션을 수정하지 않아야 합니다.
3. Stateless. REST API는 stateless입니다. 이는 각 요청에서 이의 처리에 필요한 모든 정보를 포함해야 함을 의미합니다. 즉, REST API는 서버측 세션을 필요로 하지 않습니다. 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없습니다.
4. 캐싱 가능성. 가급적이면, 리소스를 클라이언트 또는 서버측에서 캐싱할 수 있어야 합니다. 또한 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 합니다. 이의 목적은 서버측의 확장성 증가와 함께 클라이언트측의 성능 향상을 동시에 얻는 것입니다.
5. 계층 구조 아키텍처. REST API에서는 호출과 응답이 서로 다른 계층을 통과합니다. 일반적으로는, 클라이언트와 서버 애플리케이션이 서로 간에 직접 연결된다고 가정하지 마세요. 통신 루프에는 다수의 서로 다른 중개자가 있을 수 있습니다. REST API는 엔드 애플리케이션 또는 중개자와 통신하는지 여부를 클라이언트나 서버가 알 수 없도록 설계되어야 합니다.
6. 코드 온디맨드(옵션). REST API는 일반적으로 정적 리소스를 전송하지만, 특정한 경우에는 응답에 실행 코드(예: Java 애플릿)를 포함할 수도 있습니다. 이러한 경우에, 코드는 요청 시에만 실행되어야 합니다.

 REST 원칙을 잘 지키지 않더라도 HTTP 통신 기반으로 작성한 API는 REST API라고 부르곤 한다. 한 편으로, REST 원칙을 준수해서 작성한 API는 RESTful API라고 구분해서 부른다.

 RESTful API는 쉽고 프론트엔드와 백엔드를 분리하기 때문에 편리하고 새 기능을 추가할 때에도 확장하기 쉽다. 그리고 URI 즉, 리소스에 초점을 맞춰서 처리하기 때문에 특정 언어나 기기 등의 환경 변화에 결과가 영향을 받지 않는 등 장점이 많다.

 그러나 CRUD에만 집중하는 점, 보안은 고려 않는 점, 자유도가 너무 높고, 불편한 문서 관리로 인한 문서 신뢰 하락 등 한계점도 여럿 있다. 그렇기에 GraphQL 같은 IDL 즉, 인터페이스 정의 언어들도 관심을 많이 받고 있다.

 어떤 개발을 하든 절대적 왕도는 없다. 상황마다 적용할 기술, 디자인 패턴, 기술은 제각각이며, REST API는 여전히 중요한 개념 중 하나다.

5. HTTP 상태

 HTTP 요청을 보내면 여러 응답이 발생한다. 상태를 표현하는 코드도 많다.

200번대: 정상 처리

• 200 : 정상 처리됨.
• 201 : 정상처리가 됐고, 서버에서 리소스를 만듦.
• 202 : 요청 접수는 됐는데 처리는 안 됨.
• 204 : 요청은 정상처리됐는데 payload가 비어있음.

300번대: 리디렉션 관련

• 300 : 요청을 완료하려면 웹 브라우저에서 추가 조치가 필요.
• 301 : 영구적인 리다이렉트. 서버가 URI 주소를 바꿨을 때 리다이렉트시킴.(HTTP 메소드를 GET으로 바꾸는 편이고, 내가 작성한 것들이 날아감)
• 308 : 301이랑 비슷.
  (HTTP 메소드 유지, 내가 작성한 것들 유지. 하지만 쓸 일은 별로 없음)
• 302 : 일시적 리다이렉트. HTTP 메소드가 GET으로 변할 수 있음.
• 303 : 일시적 리다이렉트. HTTP 메소드가 GET으로 변함.
• 307 : 일시적 리다이렉트. HTTP 메소드에 변경 없음.
• 304 : 캐시 목적 리다이렉트.

400번대: 클라이언트 잘못

• 400 : 요청 구문, 메시지 등의 오류. (파라미터가 잘못됐거나 API 스펙에 안 맞음. 숫자를 보내야 하는데 문자를 보내는 등)
• 401 : 인증 에러. 응답에 www-Authenticate 헤더와 함께 인증법을 줘야함.
  인증: Authentication. 본인 확인.
  인가: Authorization. 해당 유저의 권한 확인.
• 403 : 요청은 맞는데, 권한이 안 맞음.
  예: 일반 사용자가 관리자 권한으로 요청
• 404 : 해당 리소스를 못 찾음.
  예: 없는 주소를 입력함. 혹은 해당 리소스가 숨겨진 상태.

500번대: 서버 잘못

서버 잘못이라서 요청을 재시도하면 성공할 가능성이 있다.

• 500 : 서버 내부 문제. 애매할 땐 500
• 503 : 서버의 일시적 과부하, 혹은 점검용 서버 다운 등.
  (Retry-After로 언제 복구될 지 작성할 수도 있음.)

6. HTTP 헤더

 HTTP 헤더는 요약문이다

• Content-Type : payload의 타입.
  text/html
  charset=UTF-8
  application/json
  image/png....
• Content-Language : 표기할 언어.
  ko(한국어)
  en(영어)
• referer : 내가 어떤 URI에서 들어왔는지 표시(뒤로 가기 누르면 보이는 사이트)
• user-agent : 클라이언트의 앱 정보(브라우저 등)
• server : origin 서버의 정보
  origin 서버란 최종적으로 응답을 주는 진짜 서버를 말한다.
  HTTP로 요청과 응답을 주고받을 때엔 중간에 여러 서버를 경유한다.
• location : 리다이렉트 주소
• HTTP 네고: Accept~: ~~ 요청을 보내면 서버는 그 요청에 최대한 응한다.
  예: Accept-Language: ko-KR, ko;q=0.9, en-US,en;q=0.7, ja;q=0.6
  한국어로 사이트를 표기해달라는 요청. 안 되면 영어, 일본어로 표기해달라는 것.
• 쿠키: 따로 서술
• 캐시: 따로 서술

6-1. 쿠키

 HTTP는 무상태(Stateless) 프로토콜. 요청, 응답만 하면 됨.
자체적으로 정보 기억하진 못해서 쿠키 활용

Set-Cookie: sessionID=abc123; Expires=Thu, 30 Jun 2023 12:00:00 GMT; Path=/; Domain=.example.com; Secure
Set-Cookie: userID=12345; Expires=Thu, 30 Jun 2023 12:00:00 GMT; Path=/; Domain=.example.com; Secure
Set-Cookie: theme=dark; Expires=Thu, 30 Jun 2023 12:00:00 GMT; Path=/; Domain=.example.com; Secure
Set-Cookie: language=en; Expires=Thu, 30 Jun 2023 12:00:00 GMT; Path=/; Domain=.example.com; Secure

• 쿠키는 서버가 발급.
• 클라이언트는 쿠키 저장하고 요청마다 전송
• 쿠키에 세션ID 등이 적혀있음
• 사용자는 쿠키 주고, 서버는 쿠키로 사용자 식별

대충 쿠키 플로우 요약
1. 아이디, 비번으로 접속
2. 서버가 ID 담은 쿠키 생성, 발급
3. 요청마다 쿠키 전송
4. 서버는 쿠키의 ID 정보로 유저 식별, 로그인 유지, 정보 저장
그 외) 세션ID는 세션 종료하면 소멸, 일반 쿠키는 저장되기에 자동 로그인 가능

• 옛날엔 쿠키에 아이디랑 비번 정보가 있었음
  + 근데 쿠키 훔쳐보는 거 너무 쉬움
  -> 해킹 너무 쉬움
  -> 쿠키에 아디, 비번 대신 세션 ID만 담기로 변경
  -> 세션 하이재킹(로그인된 상태 훔치기) 유행
  -> 보안 대응은 필수

쿠키 옵션 요약: 도메인, 경로, 기한, 보안

• Domain : 지정 도메인의 서브 도메인에서도 쿠키 사용 가능
  안 하면 오로지 정확한 도메인에서만 쿠키 사용 가능
• Path : 지정 경로의 하위 경로에서도 쿠키 사용 가능
• expires : xxxx년 xx월 xx일 xx시 xx분 xx초까지 유효
• Max-Age : 발급일로부터 xx초 동안 유효
• secure : https만 쿠키 전송
• HttpOnly : XSS 공격 방지. JS로 쿠키 접근 불가능
• SameSite : XSRF 공격 방지. 요청 도메인 = 쿠키 도메인일 때만 쿠키 전송

6-2. 캐시

 3mb 이미지를 요청하고, 10초마다 같은 이미지를 재요청하면 어떻게 될까?
원래는 매번 다운로드.
캐시 쓰면? 저장했다가 재사용.

장점

• 성능: 재요청 때 시간, 자원 절약(가장 중요)
• 오프라인 작업 : 인터넷 끊겨도 캐시는 볼 수 있음
• 물리적 효율 : 배터리 절약 등

단점

• 성능: 많이 쌓이면 용량 부담
• 손상된 캐시 : 캐시에 손상 생기면 에러
• 오래된 캐시 : 최신 버전 나와도 캐시 때문에 구버전 볼 수 있음

캐시 기한 끝나면?

1. last-modified
   최근 업데이트 일자로 판단
   업데이트가 없었으면 서버는 캐시 재사용하라고 304 응답(빈 body)
   요청하려면 if-modified-since: 를 사용한다
   한계: 가볍게 업데이트해도 재다운로드해야 함
2. ETag(Entity Tag)
   캐시에 붙인 etag만 비교해보고 판단
   요청할 땐 if-none-match 사용

캐시 쓰기 싫으면?
 안 쓰겠다고 명시. 안 그러면 브라우저가 자동으로 캐시함.

• no-cache : 매 요청마다 캐시 검증받고 갱신 or 일회성 재사용
• no-store : 캐시 자체를 금지
• must-revalidate : 기한 끝났으면 검증
  접근 실패 시 반드시 오류 발생시켜야 함
• no-cache & must-revalidate: 프록시에서 검증
• 서버 연결이 고장나면?
  no-cache: 옛날 캐시 반환. (2월 25일 요청인데 1월 11일 결과로 응답)
  must-revalidate: 504 에러

웹 캐시(프록시 서버)?
 외국 서비스 빠르게 이용 가능한 이유:
 각지에 프록시가 요청을 캐치하고 사용자들한테 캐시를 줌.

리버스 프록시?
 프록시: 클라이언트 대신 요청, 클라이언트를 익명화.
 리버스 프록시: 서버 대신 수신, 오리진 서버를 익명화, 로드 밸런싱(트래픽 고루 분산), 실험 기능 테스트 등등

CDN(Content Delivery Network)?
 프록시로 사용자들에게 컨텐츠를 빠르게 제공하는 서비스

7. 마무리

 HTTP 통신에 대해 가볍게 알아봤다.

8. 참조

• HTTP 위키피디아 문서
• MDN representation 헤더
• MDN HTTP 헤더
• MDN HTTP 헤더에 들어가는 것들
• MDN 컨텐츠 네고
• 웹 캐시에 관한 이야기
• XSS 공격과 HttpOnly
• XSRF 공격과 SameSite
• 10분 테코톡 - cache
• 캐시
• OSI 7계층과 TCP/IP 4계층
• REST API란?
• RESTful API 이란
• [B4] 프런트엔드를 위한 API 프로토콜, REST만이 답은 아니다. (with. gRPC, GraphQL)

A라는 처리 결과에 대한...
    B라는 처리 결과에 대한...
        C라는 처리 결과에 대한...
            D라는 처리 결과에 대해
        코드를 작성하면...
    콜백 지옥이...
탄생한다...

doSomething(function(result) {
  doSomethingElse(result, function(newResult) {
    doThirdThing(newResult, function(finalResult) {
      console.log('Got the final result: ' + finalResult);
	// 에러용 failureCallback 콜백 함수를 여러 차례 붙이는 모습.
    }, failureCallback);
  }, failureCallback);
}, failureCallback);

콜백 지옥의 문제점.

• 가독성 bad
• 실행 순서 보장 X
  자원을 받아오는 시간이 3초, 자원을 활용하는 콜백 함수를 실행하는 코드까지 도달하는데 1초 걸린다고 하면?
• 종속성
  콜백 함수들이 얽히고설키면 하나 고칠 때 여럿 고친다.
• 에러 처리 난해
  에러 처리를 꼬박꼬박 붙여야 한다.

 그러면 모두가 저렇게 괴로운 코드를 썼을까요? 일단, 여러 노력이 있었습니다.

document.querySelector('form').onsubmit = formSubmit

function formSubmit (submitEvent) {
  var name = document.querySelector('input').value
  request({
    uri: "http://example.com/upload",
    body: name,
    method: "POST"
  }, postResponse)
}

function postResponse (err, response, body) {
  var statusMessage = document.querySelector('.status')
  if (err) return statusMessage.value = err
  statusMessage.value = body
}

module.exports.submit = formSubmit

function formSubmit (submitEvent) {
  var name = document.querySelector('input').value
  request({
    uri: "http://example.com/upload",
    body: name,
    method: "POST"
  }, postResponse)
}

function postResponse (err, response, body) {
  var statusMessage = document.querySelector('.status')
  if (err) return statusMessage.value = err
  statusMessage.value = body
}

 var fs = require('fs')

 fs.readFile('/Does/not/exist', handleFile)

 function handleFile (error, file) {
   if (error) return console.error('Uhoh, there was an error', error)
   // otherwise, continue on and use `file` in your code
 }

 그러나 이 노력들도 근본적인 해결책은 아닙니다. 코드량은 많아지고 신경 써야할 부분은 많았습니다. 그래서 나온 해결책이 프로미스입니다.

Promise

 프로미스는 선언 당시 확정 못한 값에 대한 중개인으로서 성공, 실패에 대한 처리를 합니다. 일반 함수처럼 최종값을 즉시 반환하지 않고 나중에 주겠다는 약속을 반환합니다.

위 콜백 지옥 코드를 프로미스로 바꿔보겠습니다.

// before
doSomething(function(result) {
  doSomethingElse(result, function(newResult) {
    doThirdThing(newResult, function(finalResult) {
      console.log('Got the final result: ' + finalResult);
    }, failureCallback);
  }, failureCallback);
}, failureCallback);

// after
doSomething()
.then(result => doSomethingElse(result))
.then(newResult => doThirdThing(newResult))
.then(finalResult => {
  console.log(`Got the final result: ${finalResult}`);
})
.catch(failureCallback);

• then의 콜백 함수는 이벤트 루프가 콜 스택 작업을 마치기 전까지는 절대 호출되지 않습니다.
• then을 여러 번 써서 콜백 함수를 계속 추가할 수 있습니다. 각 콜백 함수는 순서대로 실행됩니다.

상태와 운명

 프로미스는 3가지 상태(state)와 2가지 운명(fate)를 가집니다. 번외로 확정(settled)이라는 표현도 있습니다.

 대기중(pending)만 아니면 확정입니다. 확정은 상태(state)를 뜻하진 않고 편의상의 표현입니다.

• 상태
  fulfilled : 성공 (then 콜백을 당장 작업 큐에 집어넣을 수 있는 상태)
  rejected : 실패 (catch 콜백을 당장 작업 큐에 집어넣을 수 있는 상태)
  pending : 대기 (성공도 실패도 아닌 상태)
• 운명
  resolved : 해결 (성공, 실패를 다루는 함수를 사용함)
  unresolved : 미해결 (해결을 안 함)

1. 코드를 실행하고 pending 프로미스를 초기화한다.
2. 프로미스가 확정(성공 or 실패)된다.
3. 성공: 결과를 캐시하고(나중에 재사용하기 위함) then 콜백을 실행.
   실패: catch에서 에러 처리.
4. 새로운 pending 프로미스 객체를 초기화한다.
5. 추가 작업시 위의 알고리즘을 반복한다.

미해결과 미확정

 해결 안 된 프로미스는 계속 대기 상태입니다. 해결된 프로미스는 대기, 성공, 실패 중 하나입니다.
 프로미스는 성공용 함수, 실패용 함수를 호출하면 해결(resolved)했다고 말합니다. 성공용, 실패용 함수에 또다른 프로미스를 전달해도 해결됩니다. 하지만 '아직은' 확정됐다고 말할 수 없습니다.

let p0 = new Promise((resolve, reject) => {
  resolve(123);
});

let p1 = p0.then((result) => {
  return result + 1;
});

console.log(p1); // pending

setTimeout(() => {
  console.log(p1); // fulfilled 124
}, 10);

 비동기 작업은 응답이 언제 올 지는 예측할 수 없습니다.

의도대로 안 나오는 결과

let p0 = new Promise((resolve, reject) => {
  resolve(123);
});

let p1 = p0.then((result) => {
  setTimeout(() => {
    console.log("this callback returns undefined, not 404");
    return 404;
  }, 1000);
});

setTimeout(() => {
  console.log(p1); // undefined
}, 10);

 then은 콜백 함수 실행 직후 바로 프로미스를 반환합니다. 일반 함수처럼, return 문이 없으면 undefined (프로미스)를 반환합니다. 이는 성공됐다고 간주합니다.
 위 코드는 setTimeout 내부에 return을 작성했으므로 의도하는 404 대신 undefined가 return됩니다.

부실한 에러 처리

promise1
  .then(
    (value) => {
      console.log(value);
    },
    (reason) => {
      console.log(reason);
    }
  )
  .catch((reason) => {
    console.log(reason);
  });

 then에는 두 개의 콜백을 작성할 수 있는데 첫 번째는 성공에 대한 처리, 두 번째는 실패에 대한 이유(reason)를 작성합니다. 하지만 보통은 catch문으로 처리하길 권합니다. 가독성도 더 나을 뿐더러, then(reason)은 then(value)에서 발생하는 에러를 처리 못하지만 catch는 그것까지 처리하기 때문입니다.

프로미스 지옥

loadSomething()
.then(something => {
  loadAnotherthing()
  .then(another => {
    DoSomethingOnThem(something, another);
  });
});

 이런 코드는 가독성이 나쁘기에 보통은 Promise.all로 해결합니다. Promise.all은 모든 프로미스가 성공하면 배열을 반환합니다.

Promise.all([loadSomething, loadAnotherThing])
    .then(values => {
        DoSomethingOnThem(values);
});

function promised() {
  return new Promise(resolve => {
    getOtherPromise().then(result => {
      getAnotherPromise(result).then(result2 => {
        resolve(result2);
      });
    });
  });
}

 하지만 연쇄적으로 프로미스를 처리해야 하는 경우는 프로미스 지옥을 해소할 수 없습니다. 이 경우 async / await를 사용합니다.

async / await

async function promised() {
   const result =  await getOtherPromise();
   const result2 = await getAnotherPromise(result);
   return result2;
}

• 간결한 가독성
• then / catch 대신 try / catch 사용
• 에러가 발생한 위치를 구체적으로 알려줌 (편한 디버깅)
• 프로미스 지옥 해소

 async & await를 쓸 땐 아래 특징을 염두합니다.

• async가 반환하는 것은 프로미스.
• await로 응답을 받으면 이후 코드는 then의 콜백 함수처럼 마이크로태스크로 처리된다.

async 함수

 async는 promise보다 짧고 쉽습니다.

async function foo() {
   return 1
}

function foo() {
   return Promise.resolve(1)
}

 단, async와 Promise는 소소한 차이가 있습니다.

const p = new Promise((res, rej) => {
  res(1);
})

const asyncReturn = async () => p;
const basicReturn = () => Promise.resolve(p);

console.log(p === basicReturn()); // true
console.log(p === asyncReturn()); // false

await

function wait() {
  return new Promise((res) => {
    setTimeout(() => {
      res(10);
    }, 10);
  });
}

function foo() {
  return Promise.resolve(wait()).then((result) => result);
}

async function foo() {
  const result = await wait();
  return result;
}

 위 코드와 이벤트 루프를 생각해서 아래 코드의 출력 순서를 맞혀봅시다.

const fetchData = async (url) => {
  console.log("데이터 가져오는 중...");
  const data = await fetch(url);
  return data;
};

const doSomething = async () => {
  console.log("데이터를 가져옵니다.");
  const url = "https://jsonplaceholder.typicode.com/posts/1";
  const data = await fetchData(url);
  console.log("데이터를 가져왔습니다.");
  return data;
};

queueMicrotask(() => {
  console.log("microtask 1");
});

doSomething();

queueMicrotask(() => {
  console.log("microtask 2");
});

console.log("stack");

미해결된 프로미스, timeout

 미해결 프로미스는 안티 패턴 중 하나입니다.

async function createUnresolvedPromise() {
  return new Promise((resolve, reject) => null);
}

async function notWorking() {
  let p0 = await createUnresolvedPromise();
  // 실행 안 됨
  p0 = resolvedPromise;
  console.log(`this promise is ${p0}`);
}

notWorking();

 createUnresolvedPromise 함수는 성공도, 실패도 아닌 프로미스를 만듭니다. 아무 반응이 없기 때문에 계속 대기합니다. 일부러 저렇게 작성할 일은 없지만, 아래처럼 비슷한 케이스를 경험할 수는 있습니다.

const timeout = (ms = 6000) => {
  return new Promise((reject) => {
    setTimeout(
      () => reject(new Error(`데이터 요청 후 ${time / 1000}초가 지났습니다.`)),
      ms
    );
  });
};

const data = Promise.race([
  fetch("https://jsonplaceholder.typicode.com/posts"),
  timeout(1),
])
  .then(console.log)
  .catch((error) => {
    console.error("데이터를 가져올 수 없습니다.", error);
  });

const timeout = (ms = 6000) => {
  return new Promise((reject) => {
    setTimeout(
      () => reject(new Error(`데이터 요청 후 ${time / 1000}초가 지났습니다.`)),
      ms
    );
  });
};

const fetchData = async () => {
  try {
    const data = await Promise.race([
      fetch("https://jsonplaceholder.typicode.com/posts"),
      timeout(1),
    ]);
    return data;
  } catch (error) {
    console.error("데이터를 가져올 수 없습니다.", error);
  }
};

const data = await fetchData();
console.log(data);

 데이터를 가져오는 시간이 너무 오래 걸리거나 무응답일 경우를 대비해 timeout을 처리할 필요가 있습니다.

• Promise.all : 모든 프로미스가 '성공'하면 배열 반환. 하나라도 실패하면 에러.
• Promise.allSettled : 모든 프로미스가 '확정'되면 배열 반환.
• Promise.race : 가장 빨리 '확정'된 프로미스 반환.
• Promise.any : 가장 빨리 '성공'한 프로미스 반환.

마무리

 async / await는 프로미스보다 나중에 나왔지만 무조건 어느 쪽이 더 좋다고 할 순 없기에 상황에 따라 적절히 쓰면 좋습니다.

6. 참조

• Callback Hell
• Promise - JavaScript | MDN
• Using promises - JavaScript | MDN
• Promise() constructor - JavaScript | MDN
• Promise.all() - JavaScript | MDN
• Promise.race() - JavaScript | MDN
• promises-unwrapping
• Finding unresolved promises in JavaScript
• Promise | PoiemaWeb
• The JavaScript Promise Anti-patterns
• 자바스크립트의 Async/Await 가 Promises를 사라지게 만들 수 있는 6가지 이유
• Top-level await
• ECMA-262, 12th edition