For Remind.io

TypeScript HandBook 번역 문서

Wikipedia

TypeScript 알아보기 (6)

Sun, 07 Jan 2024 13:25:50 GMT

Chapter 6. 클래스

학습 목차

1. 소개 (Introduction) 2. 클래스 (Classes) 3. 상속 (Inheritance) 4. Public, private 그리고 protected 지정자 (Public, private, and protected modifiers) 5. 읽기전용 지정자 (Readonly modifier) 6. 접근자 (Accessors) 7. 전역 프로퍼티 (Static Properties) 8. 추상 클래스 (Abstract Classes) 9. 고급 기법 (Advanced Techniques)

1. 소개 (Introduction)

기존 JavaScript는 재사용할 수 있는 컴포넌트를 만들기 위해 함수와 프로토타입-기반 상속을 사용했지만, 객체 지향 접근 방식에 익숙한 프로그래머의 입장에서는 클래스가 함수를 상속받고 이런 클래스에서 객체가 만들어지는 것에 다소 어색함을 느낄 수 있다.
ECMAScript 6로도 알려진 ECMAScript 2015를 시작으로 JavaScript 프로그래머들은 이런 객체-지향적 클래스-기반의 접근 방식을 사용해서 애플리케이션을 만들 수 있습니다.
TypeScript에서는 다음 버전의 JavaScript를 기다릴 필요 없이 개발자들이 이러한 기법들을 사용할 수 있게 해주며, 기존의JavaScript로 컴파일하여 주요 브라우저와 플랫폼에서 동작하게 한다.

2. 클래스 (Classes)

class Greeter {
    greeting: string;
    constructor(message: string) {
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
}

let greeter = new Greeter("world");

C# 이나 Java를 사용해봤다면, 익숙한 구문일 것이다.
새로운 클래스 Greeter 를 선언했습니다.
이 클래스는 3개의 멤버를 가지고 있다. greeting 프로퍼티, 생성자 그리고 greet 메서드 이다.
클래스 안에서 클래스의 멤버를 참조할 때 this. 를 앞에 덧붙이는 것을 알 수 있다. 이것은 멤버에 접근하는 것을 의미한다.
마지막 줄에서, new 를 사용하여 Greeter 클래스의 인스턴스를 생성한다.
이 코드는 이전에 정의한 생성자를 호출하여 Greeter 형태의 새로운 객체를 만들고, 생성자를 실행해 초기화한다.

3. 상속 (Inheritance)

TypeScript에서는, 일반적인 객체-지향 패턴을 사용할 수 있다.
클래스-기반 프로그래밍의 가장 기본적인 패턴 중 하나는 상속을 이용하여 이미 존재하는 클래스를 확장해 새로운 클래스를 만들 수 있다는 것이다.

class Animal {
    move(distanceInMeters: number = 0) {
        console.log(`Animal moved ${distanceInMeters}m.`);
    }
}

class Dog extends Animal {
    bark() {
        console.log('Woof! Woof!');
    }
}

const dog = new Dog();
dog.bark();
dog.move(10);
dog.bark();

상속 기능을 보여주는 가장 기본적인 예제이다. 클래스는 기초 클래스로부터 프로퍼티와 메서드를 상속받는다.
여기서, Dog 은 extends 키워드를 사용하여 Animal 이라는 기초 클래스로부터 파생된 파생 클래스이다.
파생된 클래스는 하위클래스(subclasses), 기초 클래스는 상위클래스(superclasses) 라고 불리기도 한다.
Dog 는 Animal 의 기능을 확장하기 때문에, bark() 와 move() 를 모두 가진 Dog 인스턴스를 생성할 수 있다.

class Animal {
    name: string;
    constructor(theName: string) { this.name = theName; }
    move(distanceInMeters: number = 0) {
        console.log(`${this.name} moved ${distanceInMeters}m.`);
    }
}

class Snake extends Animal {
    constructor(name: string) { super(name); }
    move(distanceInMeters = 5) {
        console.log("Slithering...");
        super.move(distanceInMeters);
    }
}

class Horse extends Animal {
    constructor(name: string) { super(name); }
    move(distanceInMeters = 45) {
        console.log("Galloping...");
        super.move(distanceInMeters);
    }
}

let sam = new Snake("Sammy the Python");
let tom: Animal = new Horse("Tommy the Palomino");

sam.move();
tom.move(34);

이 예제는 앞에서 언급하지 않은 몇 가지 기능을 다룬다. 이번에도 extends 키워드를 사용하여 Animal 의 하위클래스를 생성한다: Horse 와 Snake.
이전 예제와 한 가지 다른 부분은 파생된 클래스의 생성자 함수는 기초 클래스의 생성자를 실행할 super() 를 호출해야 한다는 점이다.
더욱이 생성자 내에서 this 에 있는 프로퍼티에 접근하기 전에 super() 를 먼저 호출해야 한다.
이 부분은 TypeScript에서 중요한 규칙이다.
또한 이 예제는 기초 클래스의 메서드를 하위클래스에 특화된 메서드로 오버라이드하는 방법을 보여준다.
여기서 Snake 와 Horse 는 Animal 의 move 를 오버라이드해서 각각 클래스의 특성에 맞게 기능을 가진 move 를 생성한다.
tom 은 Animal 로 선언되었지만 Horse 의 값을 가지므로 tom.move(34) 는 Horse 의 오버라이딩 메서드를 호출힌다.

Slithering...
Sammy the Python moved 5m.
Galloping...
Tommy the Palomino moved 34m.

4. Public, private 그리고 protected 지정자 (Public, private, and protected modifiers)

4-1. 기본적으로 공개 (Public by default)

예제에서는, 프로그램 내에서 선언된 멤버들에 자유롭게 접근할 수 있다.
다른 언어의 클래스가 익숙하다면, 위 예제에서 public 을 사용하지 않아도 된다는 점을 알 수 있다.
예를 들어, C#에서는 노출 시킬 각 멤버에 public 을 붙여야 한다.
TypeScript에서는 기본적으로 각 멤버는 public 입니다.
명시적으로 멤버를 public 으로 표시할 수도 있다.
이전 섹션의 Animal 클래스를 다음과 같은 방식으로 작성할 수 있다.

class Animal {
    public name: string;
    public constructor(theName: string) { this.name = theName; }
    public move(distanceInMeters: number) {
        console.log(`${this.name} moved ${distanceInMeters}m.`);
    }
}

4-2. ECMAScript 비공개 필드 (ECMAScript Private Fields)

TypeScript 3.8에서, TypeScript는 비공개 필드를 위한 JavaScript의 새로운 문법을 지원한다.

class Animal {
    #name: string;
    constructor(theName: string) { this.#name = theName; }
}

new Animal("Cat").#name; // 프로퍼티 '#name'은 비공개 식별자이기 때문에 'Animal' 클래스 외부에선 접근할 수 없다.

이 문법은 JavaScript 런타임에 내장되어 있으며, 각각의 비공개 필드의 격리를 더 잘 보장할 수 있다.
현재 TypeScript 3.8 릴리즈 노트에 비공개 필드에 대해 자세히 나와있다.

4-3. TypeScript의 private 이해하기 (Understanding TypeScript’s private )

TypeScript에는 멤버를 포함하는 클래스 외부에서 이 멤버에 접근하지 못하도록 멤버를 private 으로 표시하는 방법이 있다.

class Animal {
    private name: string;
    constructor(theName: string) { this.name = theName; }
}

new Animal("Cat").name; // 오류: 'name'은 비공개로 선언되어 있습니다;

TypeScript는 구조적인 타입 시스템이다.
두개의 다른 타입을 비교할 때 어디서 왔는지 상관없이 모든 멤버의 타입이 호환 된다면, 그 타입들 자체가 호환 가능하다고 말한다.
그러나 private 및 protected 멤버가 있는 타입들을 비교할 때는 타입을 다르게 처리한다.
호환된다고 판단되는 두 개의 타입 중 한 쪽에서 private 멤버를 가지고 있다면, 다른 한 쪽도 무조건 동일한 선언에 private 멤버를 가지고 있어야 한다.
이것은 protected 멤버에도 적용된다.

class Animal {
    private name: string;
    constructor(theName: string) { this.name = theName; }
}

class Rhino extends Animal {
    constructor() { super("Rhino"); }
}

class Employee {
    private name: string;
    constructor(theName: string) { this.name = theName; }
}

let animal = new Animal("Goat");
let rhino = new Rhino();
let employee = new Employee("Bob");

animal = rhino;
animal = employee; // 오류: 'Animal'과 'Employee'은 호환될 수 없음.

이 예제에서는 Animal 과 Animal 의 하위클래스인 Rhino 가 있다.
Animal 과 형태가 같아보이는 Employee 라는 새로운 클래스도 있다.
이 클래스들의 인스턴스를 생성하여 할당하고 어떻게 작동하는지 살펴보면 Animal 과 Rhino 는 Animal 의 private name:string 이라는 동일한 선언으로부터 private 부분을 공유하기 때문에 호환이 가능하다.
하지만 Employee 경우는 그렇지 않다.
Employee 를 Animal 에 할당할 때, 타입이 호환되지 않다는 오류가 발생한다.
Employee 는 name 이라는 private 멤버를 가지고 있지만, Animal 에서 선언한 것이 아니기 때문이다.

4-4. protected 이해하기 (Understanding protected)

protected 지정자도 protected 로 선언된 멤버를 파생된 클래스 내에서 접근할 수 있다는 점만 제외하면 private 지정자와 매우 유사하게 동작한다.

class Person {
    protected name: string;
    constructor(name: string) { this.name = name; }
}

class Employee extends Person {
    private department: string;

    constructor(name: string, department: string) {
        super(name);
        this.department = department;
    }

    public getElevatorPitch() {
        return `Hello, my name is ${this.name} and I work in ${this.department}.`;
    }
}

let howard = new Employee("Howard", "Sales");
console.log(howard.getElevatorPitch());
console.log(howard.name); // 오류

Person 외부에서 name 을 사용할 수 없지만, Employee 는 Person 에서 파생되었기 때문에 Employee 의 인스턴스 메서드 내에서는 여전히 사용할 수 있다.
생성자 또한 protected 로 표시될 수도 있다.
이는 클래스를 포함하는 클래스 외부에서 인스턴스화 할 수 없지만 확장 할 수 있음을 의미한다.

class Person {
    protected name: string;
    protected constructor(theName: string) { this.name = theName; }
}

// Employee는 Person을 확장할 수 있습니다.
class Employee extends Person {
    private department: string;

    constructor(name: string, department: string) {
        super(name);
        this.department = department;
    }

    public getElevatorPitch() {
        return `Hello, my name is ${this.name} and I work in ${this.department}.`;
    }
}

let howard = new Employee("Howard", "Sales");
let john = new Person("John"); // 오류: 'Person'의 생성자는 protected 입니다.

5. 읽기전용 지정자 (Readonly modifier)

readonly 키워드를 사용하여 프로퍼티를 읽기전용으로 만들 수 있다.
읽기전용 프로퍼티들은 선언 또는 생성자에서 초기화해야한다.

class Octopus {
    readonly name: string;
    readonly numberOfLegs: number = 8;
    constructor (theName: string) {
        this.name = theName;
    }
}
let dad = new Octopus("Man with the 8 strong legs");
dad.name = "Man with the 3-piece suit"; // 오류! name은 읽기전용 입니다.

5-1. 매개변수 프로퍼티 (Parameter properties)

마지막 예제의 Octopus 클래스 내에서 name 이라는 읽기전용 멤버와 theName 이라는 생성자 매개변수를 선언했다.
이는 Octopus 의 생성자가 수행된 후에 theName 의 값에 접근하기 위해서 필요하다.
매개변수 프로퍼티를 사용하면 한 곳에서 멤버를 만들고 초기화할 수 있다.
다음은 매개변수 프로퍼티를 사용한 더 개정된 Octopus 클래스이다.

class Octopus {
    readonly numberOfLegs: number = 8;
    constructor(readonly name: string) {
    }
}

생성자에 짧아진 readonly name: string 파라미터를 사용하여 theName 을 제거하고 name 멤버를 생성하고 초기화했다.
즉 선언과 할당을 한 곳으로 통합했다.
매개변수 프로퍼티는 접근 지정자나 readonly 또는 둘 모두를 생성자 매개변수에 접두어로 붙여 선언한다.
매개변수 프로퍼티에 private 을 사용하면 비공개 멤버를 선언하고 초기화한다.
마찬가지로, public , protected , readonly 도 동일하게 작용한다.

6. 접근자 (Accessors)

TypeScript는 객체의 멤버에 대한 접근을 가로채는 방식으로 getters/setters 를 지원한다.
이를 통해 각 객체의 멤버에 접근하는 방법을 세밀하게 제어할 수 있다.
간단한 클래스를 get 과 set 을 사용하도록 변환해보자.

class Employee {
    fullName: string;
}

let employee = new Employee();
employee.fullName = "Bob Smith";
if (employee.fullName) {
    console.log(employee.fullName);
}

사람들이 임의로 fullName 을 직접 설정할 수 있도록 허용하는 것은 매우 편리하지만, 우리는 fullName 이 설정될 때 몇 가지 제약 조건이 적용되는 것을 원할 수 있다.
이 버전에서는 백업 데이터베이스 필드의 최대 길이와 호환되는지 확인하기 위해 newName 의 길이를 확인하는 setter 를 추가한다.
만약 최대 길이를 초과한다면, 클라이언트 코드에 문제가 있다는 것을 알리기 위해 오류를 발생시킨다.
기존의 기능을 유지하기 위해, fullName 을 수정하지 않는 간단한 getter 도 추가한다.

const fullNameMaxLength = 10;

class Employee {
    private _fullName: string;

    get fullName(): string {
        return this._fullName;
    }

    set fullName(newName: string) {
        if (newName && newName.length > fullNameMaxLength) {
            throw new Error("fullName has a max length of " + fullNameMaxLength);
        }

        this._fullName = newName;
    }
}

let employee = new Employee();
employee.fullName = "Bob Smith";
if (employee.fullName) {
    console.log(employee.fullName);
}

접근자가 값의 길이를 확인하고 있는지 검증하기 위해서, 10자가 넘는 이름을 할당하고 오류가 발생함을 확인할 수 있다.
접근자에 대해 주의해야 할 사항:
- 먼저 접근자는 ECMAScript 5 이상을 출력하도록 컴파일러를 설정해야한다.
- ECMAScript 3으로의 하향 조정은 지원되지 않는다.
- get 과 set 이 없는 접근자는 자동으로 readonly 로 유추된다. 이는 프로퍼티 내의 사용자들이 변경할 수 없음을 알 수 있기 때문에 코드 내에서 .d.ts 파일을 생성할 때 유용하다.

7. 전역 프로퍼티 (Static Properties)

인스턴스가 아닌 클래스 자체에서 보이는 전역 멤버를 생성할 수 있다.
이 예제에서는 모든 grid 의 일반적인 값이기 때문에 origin 에 static 을 사용한다.
각 인스턴스는 클래스 이름을 앞에 붙여 이 값에 접근할 수 있다.
인스턴스 접근 앞에 this. 를 붙이는 것과 비슷하게 여기선 전역 접근 앞에 Grid. 를 붙인다.

class Grid {
    static origin = {x: 0, y: 0};
    calculateDistanceFromOrigin(point: {x: number; y: number;}) {
        let xDist = (point.x - Grid.origin.x);
        let yDist = (point.y - Grid.origin.y);
        return Math.sqrt(xDist * xDist + yDist * yDist) / this.scale;
    }
    constructor (public scale: number) { }
}

let grid1 = new Grid(1.0);  // 1x scale
let grid2 = new Grid(5.0);  // 5x scale

console.log(grid1.calculateDistanceFromOrigin({x: 10, y: 10}));
console.log(grid2.calculateDistanceFromOrigin({x: 10, y: 10}));

8. 추상 클래스 (Abstract Classes)

추상 클래스는 다른 클래스들이 파생될 수 있는 기초 클래스이다.
추상 클래스는 직접 인스턴스화할 수 없다.
추상 클래스는 인터페이스와 달리 멤버에 대한 구현 세부 정보를 포함할 수 있다.
abstract 키워드는 추상 클래스뿐만 아니라 추상 클래스 내에서 추상 메서드를 정의하는데 사용된다.

abstract class Animal {
    abstract makeSound(): void;
    move(): void {
        console.log("roaming the earth...");
    }
}

추상 클래스 내에서 추상으로 표시된 메서드는 구현을 포함하지 않으며 반드시 파생된 클래스에서 구현되어야 한다.
추상 메서드는 인터페이스 메서드와 비슷한 문법을 공유한다.
둘 다 메서드 본문을 포함하지 않고 메서드를 정의한다.
그러나 추상 메서드는 반드시 abstract 키워드를 포함해야 하며, 선택적으로 접근 지정자를 포함할 수 있다.

abstract class Department {

    constructor(public name: string) {
    }

    printName(): void {
        console.log("Department name: " + this.name);
    }

    abstract printMeeting(): void; // 반드시 파생된 클래스에서 구현되어야 합니다.
}

class AccountingDepartment extends Department {

    constructor() {
        super("Accounting and Auditing"); // 파생된 클래스의 생성자는 반드시 super()를 호출해야 합니다.
    }

    printMeeting(): void {
        console.log("The Accounting Department meets each Monday at 10am.");
    }

    generateReports(): void {
        console.log("Generating accounting reports...");
    }
}

let department: Department; // 추상 타입의 레퍼런스를 생성합니다
department = new Department(); // 오류: 추상 클래스는 인스턴스화 할 수 없습니다
department = new AccountingDepartment(); // 추상이 아닌 하위 클래스를 생성하고 할당합니다
department.printName();
department.printMeeting();
department.generateReports(); // 오류: 선언된 추상 타입에 메서드가 존재하지 않습니다

9. 고급 기법 (Advanced Techniques)

9-1. 생성자 함수 (Constructor functions)

TypeScript에서는 클래스를 선언하면 실제로 여러 개의 선언이 동시에 생성된다. 첫 번째로 클래스의 인스턴스 타입이다.

class Greeter {
    greeting: string;
    constructor(message: string) {
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
}

let greeter: Greeter;
greeter = new Greeter("world");
console.log(greeter.greet()); // "Hello, world""

여기서 let greeter: Greeter 라고 할 때, Greeter 클래스의 인스턴스 타입으로 Greeter 를 사용한다.
이것은 거의 다른 객체 지향 언어를 사용하는 프로그래머들에겐 자연스러운 성질이다.
또한 생성자 함수라고 불리는 또 다른 값을 생성하고 있다.
이것은 클래스의 인스턴스를 new 할 때 호출되는 함수이다.

let Greeter = (function () {
    function Greeter(message) {
        this.greeting = message;
    }
    Greeter.prototype.greet = function () {
        return "Hello, " + this.greeting;
    };
    return Greeter;
})();

let greeter;
greeter = new Greeter("world");
console.log(greeter.greet()); // "Hello, world"

여기서, let Greeter 는 생성자 함수를 할당받을 것이다.
new 를 호출하고 이 함수를 실행할 때, 클래스의 인스턴스를 얻는다.
또한 생성자 함수는 클래스의 모든 전역 변수들을 포함하고 있다.
각 클래스를 생각하는 또 다른 방법은 인스턴스 측면과 정적 측면이 있다는 것이다.

class Greeter {
    static standardGreeting = "Hello, there";
    greeting: string;
    greet() {
        if (this.greeting) {
            return "Hello, " + this.greeting;
        }
        else {
            return Greeter.standardGreeting;
        }
    }
}

let greeter1: Greeter;
greeter1 = new Greeter();
console.log(greeter1.greet()); // "Hello, there"

let greeterMaker: typeof Greeter = Greeter;
greeterMaker.standardGreeting = "Hey there!";

let greeter2: Greeter = new greeterMaker();
console.log(greeter2.greet()); // "Hey there!"

이 예제에서 greeter1 은 이전과 비슷하게 작동한다.
Greeter 클래스를 인스턴스화하고 이 객체를 사용한다.
클래스를 직접 사용한다.
여기서 greeterMaker 라는 새로운 변수를 생성한다.
이 변수는 클래스 자체를 유지하거나 생성자 함수를 다르게 설명한다.
여기서 typeof Greeter 를 사용하여 인스턴스 타입이 아닌 "Greeter 클래스 자체의 타입을 제공한다".
혹은 더 정확하게 생성자 함수의 타입인 "Greeter 라는 심볼의 타입을 제공한다".
이 타입은 Greeter 클래스의 인스턴스를 만드는 생성자와 함께 Greeter 의 모든 정적 멤버를 포함할 것이다.
greeterMaker 에 new 를 사용함으로써 Greeter 의 새로운 인스턴스를 생성하고 이전과 같이 호출한다.

9-2. 인터페이스로써 클래스 사용하기 (Using a class as an interface)

클래스 선언은 클래스의 인스턴스를 나타내는 타입과 생성자 함수라는 두 가지를 생성한다.
클래스는 타입을 생성하기 때문에 인터페이스를 사용할 수 있는 동일한 위치에서 사용할 수 있다.

class Point {
    x: number;
    y: number;
}

interface Point3d extends Point {
    z: number;
}

let point3d: Point3d = {x: 1, y: 2, z: 3};

TypeScript HandBook

TypeScript HandBook 번역 문서

Wikipedia

TypeScript 알아보기 (5)

Sat, 06 Jan 2024 12:15:05 GMT

Chapter 5. 유니언 타입

학습 목차

1. 소개 (Introduction) 2. 유니언 타입 (Union Types) 3. 교차 타입 (Intersection Types)

1. 소개 (Introduction)

지금까지, 핸드북은 원자 객체의 타입들을 다뤄왔다.
하지만, 더 많은 타입을 모델링할수록 처음부터 타입을 만들어내기보다는 이미 존재하는 타입을 구성하거나 결합하는 방법들을 찾게 될 것이다.
유니언 타입과 교차 타입은 타입을 구성할 수 있는 방법 중 하나이다.

2. 유니언 타입 (Union Types)

가끔, number 나 string 을 매개변수로 기대하는 라이브러리를 사용할 때가 있다.

/**
 * 문자열을 받고 왼쪽에 "padding"을 추가합니다.
 * 만약 'padding'이 문자열이라면, 'padding'은 왼쪽에 더해질 것입니다.
 * 만약 'padding'이 숫자라면, 그 숫자만큼의 공백이 왼쪽에 더해질 것입니다.
 */
function padLeft(value: string, padding: any) {
  if (typeof padding === "number") {
    return Array(padding + 1).join(" ") + value;
  }
  if (typeof padding === "string") {
    return padding + value;
  }
  throw new Error(`Expected string or number, got '${padding}'.`);
}

padLeft("Hello world", 4); // "Hello world"를 반환합니다.

위 예제에서 padLeft 의 문제는 매개변수 padding 이 any 타입으로 되어있다는 것이다.
즉, number 나 string 둘 다 아닌 인수로 함수를 호출할 수 있다는 것이고, TypeScript는 이를 괜찮다고 받아들일 것이다.

declare function padLeft(value: string, padding: any): string;
// ---생략---
// 컴파일 타임에는 통과하지만, 런타임에는 오류가 발생합니다.
let indentedString = padLeft("Hello world", true);

전통적인 객체지향 코드에서, 타입의 계층을 생성하여 두 타입을 추상화할 수 있다. 이는 더 명시적일 수는 있지만, 조금 과하다고 할 수도 있다.
기존 방법의 padLeft 에서 좋은 점 중 하나는 원시 값을 단지 전달할 수 있다는 것이다.
즉 사용법이 간단하고 간결하다.
또한 이 새로운 방법은 단지 다른 곳에 이미 존재하는 함수를 사용하고자 할 때 도움이 되지 않는다.
any 대신에, 유니언 타입을 매개변수 padding 에 사용할 수 있다.

// @errors: 2345
/**
 * 문자열을 받고 왼쪽에 "padding"을 추가합니다.
 * 만약 'padding'이 문자열이라면, 'padding'은 왼쪽에 더해질 것입니다.
 * 만약 'padding'이 숫자라면, 그 숫자만큼의 공백이 왼쪽에 더해질 것입니다.
 */
function padLeft(value: string, padding: string | number) {
  // ...
}

let indentedString = padLeft("Hello world", true);

유니언 타입은 여러 타입 중 하나가 될 수 있는 값을 의미합니다. 세로 막대 (|)로 각 타입을 구분하여, number | string | boolean 은 값의 타입이 number, string 혹은 boolean이 될 수 있음을 의미한다.

1-1. 공통 필드를 갖는 유니언 (Unions with Common Fields)

유니언 타입인 값이 있으면, 유니언에 있는 모든 타입에 공통인 멤버들에만 접근할 수 있습니다.

// @errors: 2339

interface Bird {
  fly(): void;
  layEggs(): void;
}

interface Fish {
  swim(): void;
  layEggs(): void;
}

declare function getSmallPet(): Fish | Bird;

let pet = getSmallPet();
pet.layEggs();

// 두 개의 잠재적인 타입 중 하나에서만 사용할 수 있습니다.
pet.swim();

여기서 유니언 타입은 약간 까다로울 수 있으나, 익숙해지는 데 약간의 직관만 있으면 된다.
만약 값이 A | B 타입을 갖고 있으면, 확신할 수 있는 것은 그 값이 A 와 B 둘 다 가지고 있는 멤버들을 갖고 있다는 것뿐이다.
이 예제에서, Bird 는 fly 라는 멤버를 갖고 있다.
Bird | Fish 로 타입이 지정된 변수가 fly 메서드를 가지고 있는지 확신할 수 없다.
만약 변수가 실제로 런타임에 Fish이면, pet.fly() 를 호출하는 것은 오류이다.

1-2. 유니언 구별하기 (Discriminating Unions)

유니언을 사용하는 데 있어서 일반적인 기술은 TypeScript가 현재 가능한 타입 추론의 범위를 좁혀나가게 해줄 수 있는 리터럴 타입을 갖는 단일 필드를 사용하는 것이다.
예를 들어, 하나의 공통 필드를 가지고 있는 세 가지 타입의 유니언을 만들어보자.

type NetworkLoadingState = {
  state: "loading";
};

type NetworkFailedState = {
  state: "failed";
  code: number;
};

type NetworkSuccessState = {
  state: "success";
  response: {
    title: string;
    duration: number;
    summary: string;
  };
};

// 위 타입들 중 단 하나를 대표하는 타입을 만들었지만,
// 그것이 무엇에 해당하는지 아직 확실하지 않습니다.
type NetworkState =
  | NetworkLoadingState
  | NetworkFailedState
  | NetworkSuccessState;

위 타입들은 모두 state 라는 필드를 갖고 있으며, 그들 각자만의 필드도 갖고 있다.

NetworkLoadingState | NetworkFailedState | NetworkSuccessState | --- | --- | --- | state | state | state

| code | response
state 필드가 NetworkState 안의 모든 타입에 공통으로 존재한다는 점을 안다면 - 존재 여부를 체크하지 않고도 접근할 수 있다.
리터럴 타입으로서 state 를 갖고 있다면, state 의 값은 대응하는 동일한 문자열과 대조되고 TypeScript는 현재 어떤 타입이 사용되고 있는지 알 것이다.

NetworkLoadingState | NetworkFailedState | NetworkSuccessState | --- | --- | --- | "loading" | "failed" | "success"

이 경우, 런타임에 나타나는 타입의 범위를 좁히기 위하여 switch 문을 사용할 수 있다.

// @errors: 2339
type NetworkLoadingState = {
  state: "loading";
};

type NetworkFailedState = {
  state: "failed";
  code: number;
};

type NetworkSuccessState = {
  state: "success";
  response: {
    title: string;
    duration: number;
    summary: string;
  };
};
// ---생략---
type NetworkState =
  | NetworkLoadingState
  | NetworkFailedState
  | NetworkSuccessState;

function networkStatus(state: NetworkState): string {
  // 현재 TypeScript는 셋 중 어떤 것이
  // state가 될 수 있는 잠재적인 타입인지 알 수 없습니다.

  // 모든 타입에 공유되지 않는 프로퍼티에 접근하려는 시도는
  // 오류를 발생시킵니다.
  state.code;

  // state에 swtich문을 사용하여, TypeScript는 코드 흐름을 분석하면서
  // 유니언 타입을 좁혀나갈 수 있습니다.
  switch (state.state) {
    case "loading":
      return "Downloading...";
    case "failed":
      // 여기서 타입은 NetworkFailedState일 것이며,
      // 따라서 `code` 필드에 접근할 수 있습니다.
      return `Error ${state.code} downloading`;
    case "success":
      return `Downloaded ${state.response.title} - ${state.response.summary}`;
  }
}

3. 교차 타입 (Intersection Types)

교차 타입은 유니언 타입과 밀접한 관련이 있지만, 사용 방법은 매우 다르다.
교차 타입은 여러 타입을 하나로 결합한다.
기존 타입을 합쳐 필요한 기능을 모두 가진 단일 타입을 얻을 수 있다.
예를 들어, Person & Serializable & Loggable 은 Person 과 Serializable 그리고 Loggable 이다.
즉, 이 타입의 객체는 세 가지 타입의 모든 멤버를 갖게 된다.
예를 들어, 일관된 에러를 다루는 여러 네트워크 요청이 있다면 해당 에러 핸들링을 분리하여 하나의 응답 타입에 대응하는 결합된 자체 타입으로 만들 수 있다.

interface ErrorHandling {
  success: boolean;
  error?: { message: string };
}

interface ArtworksData {
  artworks: { title: string }[];
}

interface ArtistsData {
  artists: { name: string }[];
}

// 이 인터페이스들은
// 하나의 에러 핸들링과 자체 데이터로 구성됩니다.

type ArtworksResponse = ArtworksData & ErrorHandling;
type ArtistsResponse = ArtistsData & ErrorHandling;

const handleArtistsResponse = (response: ArtistsResponse) => {
  if (response.error) {
    console.error(response.error.message);
    return;
  }

  console.log(response.artists);
};

3-1. 교차를 통한 믹스인 (Mixins via Intersections)

교차는 믹스인 패턴을 실행하기 위해 사용된다.

class Person {
  constructor(public name: string) {}
}

interface Loggable {
  log(name: string): void;
}

class ConsoleLogger implements Loggable {
  log(name: string) {
    console.log(`Hello, I'm ${name}.`);
  }
}

// 두 객체를 받아 하나로 합칩니다.
function extend(
  first: First,
  second: Second
): First & Second {
  const result: Partial = {};
  for (const prop in first) {
    if (first.hasOwnProperty(prop)) {
      (result as First)[prop] = first[prop];
    }
  }
  for (const prop in second) {
    if (second.hasOwnProperty(prop)) {
      (result as Second)[prop] = second[prop];
    }
  }
  return result as First & Second;
}

const jim = extend(new Person("Jim"), ConsoleLogger.prototype);
jim.log(jim.name);

TypeScript HandBook

TypeScript HandBook 번역 문서

Wikipedia

TypeScript 알아보기 (4)

Wed, 03 Jan 2024 09:32:46 GMT

Chapter 4. 리터럴 타입

학습 목차

1. 소개 (Introduction) 2. 리터럴 타입 좁히기 (Literal Narrowing) 3. 문자열 리터럴 타입 (String Literal Types) 4. 숫자형 리터럴 타입 (Numeric Literal Types)

1. 소개 (Introduction)

리터럴 타입은 집합 타입의 보다 구체적인 하위 타입이다.
이것이 의미하는 바는 타입 시스템 안에서 "Hello World" 는 string 이지만, string 은 "Hello World" 가 아니란 것이다.
오늘날 TypeScript에는 문자열과 숫자, 두 가지 리터럴 타입이 있는데 이를 사용하면 문자열이나 숫자에 정확한 값을 지정할 수 있다.

2. 리터럴 타입 좁히기 (Literal Narrowing)

var 또는 let 으로 변수를 선언할 경우 이 변수의 값이 변경될 가능성이 있음을 컴파일러에게 알린다.
반면, const 로 변수를 선언하게 되면 TypeScript에게 이 객체는 절대 변경되지 않음을 알린다.

// const를 사용하여 변수 helloWorld가
// 절대 변경되지 않음을 보장합니다.

// 따라서, TypeScript는 문자열이 아닌 "Hello World"로 타입을 정합니다.
const helloWorld = "Hello World";

// 반면, let은 변경될 수 있으므로 컴파일러는 문자열이라고 선언할 것입니다.
let hiWorld = "Hi World";

무한한 수의 잠재적 케이스들 (문자열 값은 경우의 수가 무한대)을 유한한 수의 잠재적 케이스 (helloWorld 의 경우: 1개)로 줄여나가는 것을 타입 좁히기(narrowing)라 한다.

3. 문자열 리터럴 타입 (String Literal Types)

실제로 문자열 리터럴 타입은 유니언 타입, 타입 가드 그리고 타입 별칭과 잘 결합된다.
이런 기능을 함께 사용하여 문자열로 enum과 비슷한 형태를 갖출 수 있다.

// @errors: 2345
type Easing = "ease-in" | "ease-out" | "ease-in-out";

class UIElement {
  animate(dx: number, dy: number, easing: Easing) {
    if (easing === "ease-in") {
      // ...
    } else if (easing === "ease-out") {
    } else if (easing === "ease-in-out") {
    } else {
      // 하지만 누군가가 타입을 무시하게 된다면
      // 이곳에 도달하게 될 수 있습니다.
    }
  }
}

let button = new UIElement();
button.animate(0, 0, "ease-in");
button.animate(0, 0, "uneasy");

허용된 세 개의 문자열이 아닌 다른 문자열을 사용하게 되면 오류가 발생한다.

'"uneasy"' 타입은 '"ease-in" | "ease-out" | "ease-in-out"' 타입의 매개 변수에 할당할 수 없습니다.

문자열 리터럴 타입은 오버로드를 구별하는 것과 동일한 방법으로 사용될 수 있다.

function createElement(tagName: "img"): HTMLImageElement;
function createElement(tagName: "input"): HTMLInputElement;
// ... 추가적인 중복 정의들 ...
function createElement(tagName: string): Element {
  // ... 여기에 로직 추가 ...
}

4. 숫자형 리터럴 타입 (Numeric Literal Types)

TypeScript에는 위의 문자열 리터럴과 같은 역할을 하는 숫자형 리터럴 타입도 있다.

function rollDice(): 1 | 2 | 3 | 4 | 5 | 6 {
  return (Math.floor(Math.random() * 6) + 1) as 1 | 2 | 3 | 4 | 5 | 6;
}

const result = rollDice();

이는 주로 설정값을 설명할 때 사용된다.

/** loc/lat 좌표에 지도를 생성합니다. */
declare function setupMap(config: MapConfig): void;
// ---생략---
interface MapConfig {
  lng: number;
  lat: number;
  tileSize: 8 | 16 | 32;
}

setupMap({ lng: -73.935242, lat: 40.73061, tileSize: 16 });

TypeScript HandBook

TypeScript HandBook 번역 문서

Wikipedia

TypeScript 알아보기 (3)

Mon, 01 Jan 2024 09:33:28 GMT

Chapter 3. 함수

학습 목차

1. 소개 (Introduction) 2. 함수 (Function) 3. 함수 타입 (Function Types) 4. 선택적 매개변수와 기본 매개변수 (Optional and Default Parameter) 5. 나머지 매개변수 (Rest Parameters) 6. this 7. 오버로드 (Overloads)

1. 소개 (Introduction)

함수는 JavaScript로 된 모든 애플리케이션에서의 기본적인 구성 요소이다.
JavaScript 함수는 추상화 계층을 구축하거나 클래스 모방, 정보 은닉, 모듈에 대한 방법을 제공한다.
TypeScript에는 클래스, 네임스페이스, 모듈이 있지만, 함수는 여전히 이 일을 어떻게 할 것인지를 설명하는 데 있어 핵심 역할을 수행한다.
TypeScript에서는 표준 JavaScript 함수가 작업을 수월하게 하도록 몇 가지 새로운 기능을 추가한다.

2. 함수 (Function)

TypeScript 함수는 JavaScript와 마찬가지로 기명 함수(named function)과 익명 함수(anonymous function)로 만들 수 있다.
이를 통해 API에서 함수 목록을 작성하든 일회성 함수를 써서 다른 함수로 전달하든 애플리케이션에 가장 적합한 방법을 선택할 수 있다.
JavaScript에서의 이 두 가지 방법에 대한 예시를 보자.

// 기명 함수
fucntion add(x, y) {
  return x + y;
}

// 익명 함수
let myAdd = function(x, y) { return x + y };

JavaScript에서처럼, 함수는 함수 외부의 변수를 참조할 수 있습니다. 이런 경우를, 변수를 캡처 (capture) 한다고 한다.
이것이 어떻게 작동하는지 (그리고 이 기술을 사용할 때의 장단점)를 이해하는 것은 이 본문의 주제를 벗어나는 것이지만, 이 메커니즘이 어떻게 작동하는지에 대한 확실한 이해는 JavaScript 및 TypeScript를 사용하는 데 있어 중요하다.

let z = 100;

function addToZ(x, y) {
  return x + y + z;
}

3. 함수 타입 (Function Types)

3-1. 함수의 타이핑 (Typing the function)

이전에 사용했던 예시에 타입을 더해보자.

function add(x: number, y: number): number {
    return x + y;
}

let myAdd = function(x: number, y: number): number { return x + y };

각 파라미터와 함수 자신의 반환될 타입을 정해줄 수 있다.
TypeScript는 반환 문을 보고 반환 타입을 파악할 수 있으므로 반환 타입을 생략할 수 있다.

3-2. 함수 타입 작성하기 (Writing the function type)

함수에 타입을 붙였으니, 이제 함수 타입들을 살펴보고 함수의 전체 타입을 작성해 보자.

let myAdd: (x: number, y: number) => number =
    function(x: number, y: number): number { return x + y; };

함수의 타입은 매개변수의 타입과 반환 타입이 있다.
전체 함수 타입을 작성하고자 한다면 이 두 가지 타입이 필요하다.
매개변수 목록처럼 각 매개변수에 이름과 타입 타입을 작성해 주자.
작성하는 이름은 가독성을 위한 것이다.
위의 코드 대신 이렇게 쓸 수도 있다.

let myAdd: (baseValue: number, increment: number) => number =
    function(x: number, y: number): number { return x + y; };

매개변수의 타입들이 올바르게 나열되어 있다면 함수 타입에 이름을 붙이더라도 유효한 타입으로 간주한다.
두 번째로 반환 타입이다. 매개변수 타입들과 반환 타입 사이에 '화살표 표기'( => )를 써서 반환 타입을 분명히 할 수 있다.
이전에 언급했듯이, 함수 표기에 필요한 부분이다. 그래서 만약 함수가 값을 반환하지 않는다면 비워두는 대신 void 를 써서 표시한다.
참고로, 매개변수 타입과 반환 타입만이 함수 타입을 구성한다.
캡처된 변수는 타입에 반영되지 않는다.
사실상 캡처된 변수는 함수의 "숨겨진 상태"의 일부이고 API를 구성하지 않는다.

3-3. 타입의 추론 (Inferring the types)

TypeScript 컴파일러가 방정식의 한쪽에만 타입이 있더라도 타입을 알아낼 수 있다.

// myAdd는 전체 함수 타입을 가집니다
let myAdd = function(x: number, y: number): number { return  x + y; };

// 매개변수 x 와 y는 number 타입을 가집니다
let myAdd: (baseValue: number, increment: number) => number =
    function(x, y) { return x + y; };

이러한 타입 추론 형태를 "contextual typing" 이라 부른다.
이를 통해 여러분의 프로그램에서 타입을 유지하기 위한 노력을 줄일 수 있다.

4. 선택적 매개변수와 기본 매개변수 (Optional and Default Parameter)

TypeScript에서는 모든 매개변수가 함수에 필요하다고 가정한다.
이것이 null 이나 undefined 를 줄 수 없다는 걸 의미하는 것은 아니다.
대신 함수가 호출될 때, 컴파일러는 각 매개변수에 대해 사용자가 값을 제공했는지를 검사한다.
또한, 컴파일러는 매개변수들이 함수로 전달될 유일한 매개변수라고 가정한다.
요약하자면, 함수에 주어진 인자의 수는 함수가 기대하는 매개변수의 수와 일치해야 한다.

function buildName(firstName: string, lastName: string) {
    return firstName + " " + lastName;
}

let result1 = buildName("Bob");                  // 오류, 너무 적은 매개변수
let result2 = buildName("Bob", "Adams", "Sr.");  // 오류, 너무 많은 매개변수
let result3 = buildName("Bob", "Adams");         // 정확함

JavaScript에서는 모든 매개변수가 선택적이고, 사용자는 적합하다고 생각하면 그대로 둘 수 있다.
그렇게 둔다면 그 값은 undefined 가 된다.
TypeScript에서도 선택적 매개변수를 원한다면 매개변수 이름 끝에 ? 를 붙임으로써 해결할 수 있다.
그 예시로 성을 선택적 매개변수로 하는 경우를 들어보자.

function buildName(firstName: string, lastName?: string) {
    if (lastName)
        return firstName + " " + lastName;
    else
        return firstName;
}

let result1 = buildName("Bob");                  // 지금은 바르게 동작
let result2 = buildName("Bob", "Adams", "Sr.");  // 오류, 너무 많은 매개변수
let result3 = buildName("Bob", "Adams");         // 정확함

어느 선택적 매개변수든 반드시 매개변수 정의가 필요하다.
lastName 대신 firstName 을 선택적으로 하고 싶다면 매개변수의 순서를 변경해야 한다.
TypeScript에서는 유저가 값을 제공하지 않거나 undefined로 했을 때에 할당될 매개변수의 값을 정해 놓을 수도 있다.
이것을 기본-초기화 매개변수라고 한다.
이전 예시에서 lastName 을 "Smith" 라고 지정해 보자.

function buildName(firstName: string, lastName = "Smith") {
    return firstName + " " + lastName;
}

let result1 = buildName("Bob");                  // 올바르게 동작, "Bob Smith" 반환
let result2 = buildName("Bob", undefined);       // 여전히 동작, 역시 "Bob Smith" 반환
let result3 = buildName("Bob", "Adams", "Sr.");  // 오류, 너무 많은 매개변수
let result4 = buildName("Bob", "Adams");         // 정확함

모든 필수 매개변수 뒤에 오는 기본-초기화 매개변수 는 선택적으로 처리되며, 선택적 매개변수와 마찬가지로 해당 함수를 호출할 때 생략할 수 있다.
이는 선택적 매개변수와 뒤따르는 기본 매개변수의 타입들이 공통성을 공유함을 의미한다.

function buildName(firstName: string, lastName?: string) {
    // ...
}
와

function buildName(firstName: string, lastName = "Smith") {
    // ...
}

(firstName: string, lastName?: string) => string 라는 공통된 타입을 공유한다.
lastName의 기본값은 타입에서 사라지고 오직 선택적 매개변수라는 사실만 남깁니다.
순수한 선택적 매개변수와는 다르게 기본-초기화 매개변수 는 필수 매개변수 뒤에 오는 것이 강요되지 않는다.
만약 기본-초기화 매개변수 가 필수 매개변수보다 앞에 오게 된다면 사용자가 명시적으로 undefined 를 전달해 주어야 기본-초기화 매개변수 를 볼 수 있다.
앞서 사용했던 예시에 기본 초기화를 firstName 에 적용한 것이다.

function buildName(firstName = "Will", lastName: string) {
    return firstName + " " + lastName;
}

let result1 = buildName("Bob");                  // 오류, 너무 적은 매개변수
let result2 = buildName("Bob", "Adams", "Sr.");  // 오류, 너무 많은 매개변수
let result3 = buildName("Bob", "Adams");         // 성공, "Bob Adams" 반환
let result4 = buildName(undefined, "Adams");     // 성공, "Will Adams" 반환

5. 나머지 매개변수 (Rest Parameters)

필수, 선택적, 기본 매개변수는 한 번에 하나의 매개변수만을 가지고 이야기한다.
때로는 다수의 매개변수를 그룹 지어 작업하기를 원하거나, 함수가 최종적으로 얼마나 많은 매개변수를 취할지 모를 때도 있을 것이다.
JavaScript에서는 모든 함수 내부에 위치한 arguments 라는 변수를 사용해 직접 인자를 가지고 작업할 수 있다.
TypeScript에서는 이 인자들을 하나의 변수로 모을 수 있다.

function buildName(firstName: string, ...restOfName: string[]) {
    return firstName + " " + restOfName.join(" ");
}

// employeeName 은 "Joseph Samuel Lucas MacKinzie" 가 될것입니다.
let employeeName = buildName("Joseph", "Samuel", "Lucas", "MacKinzie");

나머지 매개변수는 선택적 매개변수들의 수를 무한으로 취급한다.
나머지 매개변수로 인자들을 넘겨줄 때는 당신이 원하는 만큼 넘겨 줄 수도 있다. 아무것도 넘겨주지 않을 수도 있다.
컴파일러는 생략 부호 (...) 뒤의 이름으로 전달된 인자 배열을 빌드하여 함수에서 사용할 수 있도록 한다.
생략 부호는 나머지 매개변수가 있는 함수의 타입에도 사용된다.

function buildName(firstName: string, ...restOfName: string[]) {
    return firstName + " " + restOfName.join(" ");
}

let buildNameFun: (fname: string, ...rest: string[]) => string = buildName;

6. this

this 가 JavaScript에서 어떻게 쓰이는지 아는 것은 일종의 통과의례이다.
TypeScript는 JavaScript의 상위 집합이므로 TypeScript 개발자들 역시 this가 어떻게 쓰이는지 또는 this가 잘못 쓰일 때를 발견하는 방법을 배울 필요가 있다.
다행히도 TypeScript는 몇 가지 기술들로 잘못된 this 사용을 잡아낼 수 있다.
만약 JavaScript에서 this가 어떻게 동작하는지 알고 싶다면 먼저 Yehuda Katz의 글 JavaScript 함수 호출과 "this" 이해하기 을 참고하도록 하자. Yehuda의 글은 this의 내부 동작을 아주 잘 설명한다.

6-1. this 와 화살표 함수 (this and arrow functions)

JavaScript에서, this는 함수가 호출될 때 정해지는 변수이다.
매우 강력하고 유연한 기능이지만 이것은 항상 함수가 실행되는 콘텍스트에 대해 알아야 한다는 수고가 생긴다.
특히 함수를 반환하거나 인자로 넘길 때의 혼란스러움은 악명높다.

let deck = {
    suits: ["hearts", "spades", "clubs", "diamonds"],
    cards: Array(52),
    createCardPicker: function() {
        return function() {
            let pickedCard = Math.floor(Math.random() * 52);
            let pickedSuit = Math.floor(pickedCard / 13);

            return {suit: this.suits[pickedSuit], card: pickedCard % 13};
        }
    }
}

let cardPicker = deck.createCardPicker();
let pickedCard = cardPicker();

alert("card: " + pickedCard.card + " of " + pickedCard.suit);

createCardPicker 가 자기 자신을 반환하는 함수임을 주목해보자.
이 예제를 작동시키면 기대했던 경보 창 대신 오류가 발생할 것이다.
createCardPicker 에 의해 생성된 함수에서 사용 중인 this 가 deck 객체가 아닌 window 에 설정되었기 때문이다.
cardPicker() 의 자체적인 호출 때문에 생긴 일이다.
최상위 레벨에서의 비-메서드 문법의 호출은 this 를 window 로 한다. (Note: strict mode에서는 this가 window 대신 undefined 가 됩니다. )
이 문제는 나중에 사용할 함수를 반환하기 전에 바인딩을 알맞게 하는 것으로 해결할 수 있다.
이 방법대로라면 나중에 사용하는 방법에 상관없이 원본 deck 객체를 계속해서 볼 수 있다.
이를 위해, 함수 표현식을 ES6의 화살표 함수로 바꿀 것이다.
화살표 함수는 함수가 호출 된 곳이 아닌 함수가 생성된 쪽의 this를 캡처한다.

let deck = {
    suits: ["hearts", "spades", "clubs", "diamonds"],
    cards: Array(52),
    createCardPicker: function() {
        // NOTE: 아랫줄은 화살표 함수로써, 'this'를 이곳에서 캡처할 수 있도록 한다
        return () => {
            let pickedCard = Math.floor(Math.random() * 52);
            let pickedSuit = Math.floor(pickedCard / 13);

            return {suit: this.suits[pickedSuit], card: pickedCard % 13};
        }
    }
}

let cardPicker = deck.createCardPicker();
let pickedCard = cardPicker();

alert("card: " + pickedCard.card + " of " + pickedCard.suit);

--noImplicitThis 플래그를 컴파일러에 전달하는 실수를 하게 된다면 TypeScript는 경고를 표시할 것이다.
this.suits[pickedSuit] 의 this 는 any 타입인 것을 짚고 넘어가자.

6-2. this 매개변수 (this parameter)

this.suits[pickedSuit] 의 타입은 여전히 any이다.
this 가 객체 리터럴 내부의 함수에서 왔기 때문이다.
이것을 고치기 위해 명시적으로 this 매개변수를 줄 수 있다.
this 매개변수는 함수의 매개변수 목록에서 가장 먼저 나오는 가짜 매개변수이다.

function f(this: void) { // 독립형 함수에서 this를 사용할 수 없는 것을 확인함 }


- 명확하고 재사용하기 쉽게 ```Card``` 와 ```Deck``` 두 가지 인터페이스 타입들의 예시보자.

interface Card { suit: string; card: number; } interface Deck { suits: string[]; cards: number[]; createCardPicker(this: Deck): () => Card; } let deck: Deck = { suits: ["hearts", "spades", "clubs", "diamonds"], cards: Array(52), // NOTE: 아래 함수는 이제 callee가 반드시 Deck 타입이어야 함을 명시적으로 지정합니다. createCardPicker: function(this: Deck) { return () => { let pickedCard = Math.floor(Math.random() * 52); let pickedSuit = Math.floor(pickedCard / 13);

        return {suit: this.suits[pickedSuit], card: pickedCard % 13};
    }
}

}

let cardPicker = deck.createCardPicker(); let pickedCard = cardPicker();

alert("card: " + pickedCard.card + " of " + pickedCard.suit);


- 이제 TypeScript는 ```createCardPicker```가 ```Deck``` 객체에서 호출된다는 것을 알게 됐다.

- 이것은 ```this``` 가 ```any``` 타입이 아니라 ```Deck``` 타입이며 따라서 ```--noImplicitThis``` 플래그가 어떤 오류도 일으키지 않는다는 것을 의미한다.

**6-3. 콜백에서 ```this``` 매개변수 (this parameters in callbacks)**

- 나중에 호출할 콜백 함수를 라이브러리에 전달할 때 ```this``` 때문에 오류가 발생할 수 있다.

- 라이브러리는 콜백을 일반 함수처럼 호출하므로 ```this``` 는 ```undefined``` 가 된다.

- 일부 작업에서는 ```this``` 매개변수를 콜백 오류를 막는데 사용할 수 있다.

- 먼저 라이브러리 작성자는 콜백 타입을 ```this``` 로 표시를 해주어야 한다.

interface UIElement { addClickListener(onclick: (this: void, e: Event) => void): void; } this: void는 addClickListener가 onclick이 this타입을 요구하지 않는 함수가 될 것으로 예상하는 것을 의미합니다. 두 번째로, 호출 코드를 this로 표시합니다.

class Handler { info: string; onClickBad(this: Handler, e: Event) { // 이런, this가 여기서 쓰이는군요. 이 콜백을 쓰면 런타임에서 충돌을 일으키겠군요. this.info = e.message; } } let h = new Handler(); uiElement.addClickListener(h.onClickBad); // 오류!


- ```this``` 로 표시를 한 상태에서 ```onClickBad``` 가 반드시 ```Handler``` 의 인스턴스로써 호출되어야 함을 명시해 주어야 한다.

- 그러면 TypeScript는 ```addClickListener``` 가 ```this: void``` 를 갖는 함수를 필요로 한다는 것을 감지한다.

- 오류를 고치기 위해 ```this``` 의 타입을 바꿔준다.

class Handler { info: string; onClickGood(this: void, e: Event) { // void 타입이기 때문에 this는 이곳에서 쓸 수 없습니다! console.log('clicked!'); } } let h = new Handler(); uiElement.addClickListener(h.onClickGood);


- ```onClickGood``` 이 ```this``` 타입을 ```void``` 로 지정하고 있기 때문에 ```addClickListener``` 로 넘겨지는데 적합하다.

- 물론, 이것이 ```this.info``` 를 쓸 수 없는 것을 의미하기도 하다.

- 만약 당신이 ```this.info``` 까지 원한다면 화살표 함수를 사용해야 할 것이다.

class Handler { info: string; onClickGood = (e: Event) => { this.info = e.message } }


- 이러한 작업은 화살표 함수가 외부의 ```this``` 를 사용하기 때문에 가능하므로 ```this: void``` 일 것으로 기대하는 무언가라면 전달에 문제가 없다.

- ```Handler``` 타입 객체마다 하나의 화살표 함수가 작성된다는 점이 단점이다.

- 반면, 메서드들은 하나만 작성되어 ```Handler``` 의 프로토타입에 붙는다.

- 그들은 ```Handler``` 타입의 모든 객체 간에 공유된다.


### 7. 오버로드 (Overloads)

- JavaScript는 본질적으로 매우 동적인 언어이다.

- 하나의 JavaScript 함수가 전달된 인자의 형태에 따라 다른 타입의 객체들을 반환하는 것은 흔한 일이다.

let suits = ["hearts", "spades", "clubs", "diamonds"];

let pickedCard2 = pickCard(15); alert("card: " + pickedCard2.card + " of " + pickedCard2.suit);


- 여기 사용자가 전달하는 것에 따라 두 가지 다른 결과를 반환하는 함수가 있다.

- 사용자가 ```deck``` 을 의미하는 객체 값을 전달한다면 함수가 카드를 선택한다.

- 사용자가 카드를 선택하면 선택한 카드가 무엇인지 대답해 준다.
하지만 타입 시스템에서 이것을 어떻게 구현할까?

- 정답은 오버로드 목록으로 동일한 함수에 다중 함수 타입을 제공하는 것이다.

- 오버로드 목록은 컴파일러가 함수 호출들을 해결할 때 사용하는 것이다.

- 오버로드 목록으로 ```pickCard```가 동작을 승인하고 반환하는 것을 구현해 보자.

let suits = ["hearts", "spades", "clubs", "diamonds"];

let pickedCard2 = pickCard(15); alert("card: " + pickedCard2.card + " of " + pickedCard2.suit);

```

이 변화를 통해, 오버로드는 pickCard 함수에 대해 타입 검사 호출을 제공한다.
컴파일러가 알맞은 타입 검사를 하기 위해서, JavaScript와 비슷한 프로세스를 따른다.
오버로드 목록에서 첫 번째 오버로드를 진행하면서 제공된 매개변수를 사용하여 함수를 호출하려고 시도한다.
만약 일치하게 된다면 해당 오버로드를 알맞은 오버로드로 선택하여 작업을 수행한다.
이러한 이유로 가장 구체적인 것부터 오버로드 리스팅을 하는 것이 일반적이다.
위 예제에서 function pickCard(x): any 는 오버로드 목록에 해당되지 않음을 유의하라.
그래서 두 가지 오버로드만을 가진다. 객체를 받는것 하나와 숫자를 받는 것 하나, 다른 매개변수 타입으로 pickCard 를 호출하는 것은 오류가 발생한다.

TypeScript HandBook

TypeScript HandBook 번역 문서

Wikipedia

https://yehudakatz.com/2011/08/11/understanding-javascript-function-invocation-and-this/

Yehuda's Blog

TypeScript 알아보기 (2)

Fri, 15 Dec 2023 18:22:27 GMT

Chapter 2. 인터페이스

학습 목차

1. 소개 (Introduction) 2. 첫 번째 인터페이스 (Our First Interface) 3. 선택적 프로퍼티 (Optional Properties) 4. 읽기전용 프로퍼티 (Readonly properties) 5. 초과 프로퍼티 검사 (Excess Property Checks) 6. 함수 타입 (Function Types) 7. 인덱서블 타입 (Indexable Types) 8. 클래스 타입 (Class Types) 9. 클래스의 스태틱과 인스턴스의 차이점 (Difference between the static and instance sides of classes) 10. 인터페이스 확장하기 (Extending Interfaces) 11. 하이브리드 타입 (Hybrid Types) 12. 클래스를 확장한 인터페이스 (Interfaces Extending Classes)

1. 소개 (Introduction)

TypeScript의 핵심 원칙 중 하나는 타입 검사가 값의 형태 에 초점을 맞추고 있다는 것이다.
이를 "덕 타이핑(duck typing)" 혹은 "구조적 서브타이핑 (structural subtyping)"이라고도 한다.
TypeScript에서, 인터페이스는 이런 타입들의 이름을 짓는 역할을 하고 코드 안의 계약을 정의하는 것뿐만 아니라 프로젝트 외부에서 사용하는 코드의 계약을 정의하는 강력한 방법이다.

2. 첫 번째 인터페이스 (Our First Interface)

어떻게 인터페이스가 동작하는지 확인하는 가장 쉬운 방법은 간단한 예제로 시작하는 것이다.

function printLabel(labeledObj: { label: string }) {
    console.log(labeledObj.label);
}

let myObj = {size: 10, label: "Size 10 Object"};
printLabel(myObj);

타입 검사는 printLabel 호출을 확인한다.
printLabel 함수는 string 타입 label 을 갖는 객체를 하나의 매개변수로 가진다.
이 객체가 실제로는 더 많은 프로퍼티를 갖고 있지만, 컴파일러는 최소한 필요한 프로퍼티가 있는지와 타입이 잘 맞는지만 검사한다.
이번엔 같은 예제를, 문자열 타입의 프로퍼티 label 을 가진 인터페이스로 다시 작성해 보겠습니다:

interface LabeledValue {
    label: string;
}

function printLabel(labeledObj: LabeledValue) {
    console.log(labeledObj.label);
}

let myObj = {size: 10, label: "Size 10 Object"};
printLabel(myObj);

LabeledValue 인터페이스는 이전 예제의 요구사항을 똑같이 기술하는 이름으로 사용할 수 있다.
이 인터페이스는 여전히 문자열 타입의 label 프로퍼티 하나를 가진다는 것을 의미한다.
다른 언어처럼 printLabel 에 전달한 객체가 이 인터페이스를 구현해야 한다고 명시적으로 얘기할 필요는 없다. 여기서 중요한 것은 형태뿐입니다.
함수에 전달된 객체가 나열된 요구 조건을 충족하면, 허용된다.
타입 검사는 프로퍼티들의 순서를 요구하지 않는다.
단지 인터페이스가 요구하는 프로퍼티들이 존재하는지와 프로퍼티들이 요구하는 타입을 가졌는지만을 확인한다.

3. 선택적 프로퍼티 (Optional Properties)

인터페이스의 모든 프로퍼티가 필요한 것은 아니다.
어떤 조건에서만 존재하거나 아예 없을 수도 있다.
선택적 프로퍼티들은 객체 안의 몇 개의 프로퍼티만 채워 함수에 전달하는 "option bags" 같은 패턴을 만들 때 유용하다.

interface SquareConfig {
    color?: string;
    width?: number;
}

function createSquare(config: SquareConfig): {color: string; area: number} {
    let newSquare = {color: "white", area: 100};
    if (config.color) {
        newSquare.color = config.color;
    }
    if (config.width) {
        newSquare.area = config.width * config.width;
    }
    return newSquare;
}

let mySquare = createSquare({color: "black"});

선택적 프로퍼티를 가지는 인터페이스는 다른 인터페이스와 비슷하게 작성되고, 선택적 프로퍼티는 선언에서 프로퍼티 이름 끝에 ? 를 붙여 표시합니다.
선택적 프로퍼티의 이점은 인터페이스에 속하지 않는 프로퍼티의 사용을 방지하면서, 사용 가능한 속성을 기술하는 것이다.
예를 들어, createSquare안의 color 프로퍼티 이름을 잘못 입력하면, 오류 메시지로 알려준다.

interface SquareConfig {
    color?: string;
    width?: number;
}

function createSquare(config: SquareConfig): { color: string; area: number } {
    let newSquare = {color: "white", area: 100};
    if (config.clor) {
        // Error: Property 'clor' does not exist on type 'SquareConfig'
        newSquare.color = config.clor;
    }
    if (config.width) {
        newSquare.area = config.width * config.width;
    }
    return newSquare;
}

let mySquare = createSquare({color: "black"});

4. 읽기전용 프로퍼티 (Readonly properties)

일부 프로퍼티들은 객체가 처음 생성될 때만 수정 가능해야한다.
프로퍼티 이름 앞에 readonly를 넣어서 이를 지정할 수 있다.

interface Point {
    readonly x: number;
    readonly y: number;
}

객체 리터럴을 할당하여 Point를 생성한다.
할당 후에는 x, y를 수정할 수 없다.

let p1: Point = { x: 10, y: 20 };
p1.x = 5; // 오류!
TypeScript에서는 모든 변경 메서드(Mutating Methods)가 제거된 Array와 동일한 ReadonlyArray 타입을 제공합니다. 그래서 생성 후에 배열을 변경하지 않음을 보장할 수 있습니다.

let a: number[] = [1, 2, 3, 4];
let ro: ReadonlyArray = a;
ro[0] = 12; // 오류!
ro.push(5); // 오류!
ro.length = 100; // 오류!
a = ro; // 오류!

예제 마지막 줄에서 ReadonlyArray를 일반 배열에 재할당이 불가능한 것을 확인할 수 있다.
타입 단언(type assertion)으로 오버라이드하는 것은 가능하다.

a = ro as number[];

KeyNote

readonly vs const readonly와 const 중에 어떤 것을 사용할 지 기억하기 가장 쉬운 방법은 변수와 프로퍼티중 어디에 사용할지 질문해 보는 것이다.
변수는 const를 사용하고 프로퍼티는 readonly를 사용한다.

5. 초과 프로퍼티 검사 (Excess Property Checks)

인터페이스의 첫 번째 예제에서 TypeScript가 { label: string; }을 기대해도 { size: number; label: string; }를 허용해주었다.
또한 선택적 프로퍼티를 배우고, 소위 "option bags"을 기술할 때, 유용하다는 것을 배웠다.
하지만, 그냥 그 둘을 결합하면 에러가 발생할 수 있다.

interface SquareConfig {
    color?: string;
    width?: number;
}

function createSquare(config: SquareConfig): { color: string; area: number } {
    // ...
}

let mySquare = createSquare({ colour: "red", width: 100 });

createSquare 의 매개변수가 color 대신 colour 로 전달된 것에 유의하자. 이 경우 JavaScript에선 조용히 오류가 발생합니다.
width 프로퍼티는 적합하고, color 프로퍼티는 없고, 추가 colour 프로퍼티는 중요하지 않기 때문에, 이 프로그램이 올바르게 작성되었다고 생각할 수 있다.
하지만, TypeScript는 이 코드에 버그가 있을 수 있다고 생각한다.
객체 리터럴은 다른 변수에 할당할 때나 인수로 전달할 때, 특별한 처리를 받고, 초과 프로퍼티 검사 (excess property checking)를 받는다.
만약 객체 리터럴이 "대상 타입 (target type)"이 갖고 있지 않은 프로퍼티를 갖고 있으면, 에러가 발생한다.

// error: Object literal may only specify known properties, but 'colour' does not exist in type 'SquareConfig'. Did you mean to write 'color'?
let mySquare = createSquare({ colour: "red", width: 100 });

이 검사를 피하는 방법은 정말 간단하다.
가장 간단한 방법은 타입 단언을 사용하는 것이다.

let mySquare = createSquare({ width: 100, opacity: 0.5 } as SquareConfig);

하지만 특별한 경우에, 추가 프로퍼티가 있음을 확신한다면, 문자열 인덱스 서명(string index signatuer)을 추가하는 것이 더 나은 방법이다.
만약 SquareConfig color 와 width 프로퍼티를 위와 같은 타입으로 갖고 있고, 또한 다른 프로퍼티를 가질 수 있다면, 다음과 같이 정의할 수 있다.

interface SquareConfig {
    color?: string;
    width?: number;
    [propName: string]: any;
}

하지만 여기서는 SquareConfig 가 여러 프로퍼티를 가질 수 있고, 그 프로퍼티들이 color 나 width 가 아니라면, 그들의 타입은 중요하지 않다.
이 검사를 피하는 마지막 방법은 놀랍게도 객체를 다른 변수에 할당하는 것이다.
squareOptions 가 추가 프로퍼티 검사를 받지 않기 때문에, 컴파일러는 에러를 주지 않는다.

let squareOptions = { colour: "red", width: 100 };
let mySquare = createSquare(squareOptions);

squareOptions와 SquareConfig 사이에 공통 프로퍼티가 있는 경우에만 위와 같은 방법을 사용할 수 있다.
이 예제에서는, width 가 그 경우이다.
하지만 만약에 변수가 공통 객체 프로퍼티가 없으면 에러가 난다.

let squareOptions = { colour: "red" };
let mySquare = createSquare(squareOptions);

위처럼 간단한 코드의 경우, 이 검사를 "피하는" 방법을 시도하지 않는 것이 좋다.
메서드가 있고 상태를 가지는 등 더 복잡한 객체 리터럴에서 이 방법을 생각해볼 수 있다.
하지만 초과 프로퍼티 에러의 대부분은 실제 버그이다.
그 말은, 만약 옵션 백 같은 곳에서 초과 프로퍼티 검사 문제가 발생하면, 타입 정의를 수정해야 할 필요가 있다.
예를 들어, 만약 createSquare 에 color 나 colour 모두 전달해도 괜찮다면, squareConfig 가 이를 반영하도록 정의를 수정해야 한다.

6. 함수 타입 (Function Types)

인터페이스는 JavaScript 객체가 가질 수 있는 넓은 범위의 형태를 기술할 수 있다.
프로퍼티로 객체를 기술하는 것 외에, 인터페이스는 함수 타입을 설명할 수 있다.
인터페이스로 함수 타입을 기술하기 위해, 인터페이스에 호출 서명 (call signature)를 전달한다.
이는 매개변수 목록과 반환 타입만 주어진 함수 선언과 비슷하다.
각 매개변수는 이름과 타입이 모두 필요하다.

interface SearchFunc {
    (source: string, subString: string): boolean;
}

한번 정의되면, 함수 타입 인터페이스는 다른 인터페이스처럼 사용할 수 있다.
여기서 함수 타입의 변수를 만들고, 같은 타입의 함수 값으로 할당하는 방법을 보여준다.

let mySearch: SearchFunc;
mySearch = function(source: string, subString: string) {
    let result = source.search(subString);
    return result > -1;
}

올바른 함수 타입 검사를 위해, 매개변수의 이름이 같을 필요는 없다.
예를 들어, 위의 예제를 아래와 같이 쓸 수 있다.

let mySearch: SearchFunc;
mySearch = function(src: string, sub: string): boolean {
    let result = src.search(sub);
    return result > -1;
}

함수 매개변수들은 같은 위치에 대응되는 매개변수끼리 한번에 하나씩 검사한다.
만약 타입을 전혀 지정하지 않고 싶다면, SearchFunc 타입의 변수로 직접 함수 값이 할당되었기 때문에 TypeScript의 문맥상 타이핑 (contextual typing)이 인수 타입을 추론할 수 있다.
이 예제에서, 함수 표현의 반환 타입이 반환하는 값으로 추론된다. (여기서는 false 와 true )

let mySearch: SearchFunc;
mySearch = function(src, sub) {
    let result = src.search(sub);
    return result > -1;
}

함수 표현식이 숫자 나 문자열을 반환했다면, 타입 검사는 반환 타입이 SearchFunc 인터페이스에 정의된 반환 타입과 일치하지 않는다는 에러를 발생시킨다.

let mySearch: SearchFunc;

// error: Type '(src: string, sub: string) => string' is not assignable to type 'SearchFunc'.
// Type 'string' is not assignable to type 'boolean'.
mySearch = function(src, sub) {
  let result = src.search(sub);
  return "string";
};

7. 인덱서블 타입 (Indexable Types)

인터페이스로 함수 타입을 설명하는 방법과 유사하게, a[10] 이나 ageMap["daniel"] 처럼 타입을 "인덱스로" 기술할 수 있다.
인덱서블 타입은 인덱싱 할때 해당 반환 유형과 함께 객체를 인덱싱하는 데 사용할 수 있는 타입을 기술하는 인덱스 시그니처 (index signature)를 가지고 있다.

interface StringArray {
    [index: number]: string;
}

let myArray: StringArray;
myArray = ["Bob", "Fred"];

let myStr: string = myArray[0];

위에서 인덱스 서명이 있는 StringArray 인터페이스가 있다.
이 인덱스 서명은 StringArray 가 number 로 색인화(indexed)되면 string을 반환할 것을 나타낸다.
인덱스 서명을 지원하는 타입에는 문자열과 숫자가 있다.
두 타입의 인덱서(indexer)를 모두 지원하는 것은 가능하지만, 숫자 인덱서에서 반환된 타입은 반드시 문자열 인덱서에서 반환된 타입의 하위 타입(subtype)이어야한다.
이 이유는 number 로 인덱싱 할 때, JavaScript 는 실제로 객체를 인덱싱하기 전에 string 으로 변환하기 때문이다.
즉, 100 (number)로 인덱싱하는 것은 "100" (string)로 인덱싱하는 것과 같기 때문에, 서로 일관성 있어야 한다.

class Animal {
    name: string;
}
class Dog extends Animal {
    breed: string;
}

// 오류: 숫자형 문자열로 인덱싱을 하면 완전히 다른 타입의 Animal을 얻게 될 것입니다!
interface NotOkay {
    [x: number]: Animal;
    [x: string]: Dog;
}

문자열 인덱스 시그니처는 "사전" 패턴을 기술하는데 강력한 방법이지만, 모든 프로퍼티들이 반환 타입과 일치하도록 강제한다.
문자열 인덱스가 obj.property 가 obj["property"] 로도 이용 가능함을 알려주기 때문이다.
다음 예제에서, name 의 타입은 문자열 인덱스 타입과 일치하지 않고, 타입 검사는 에러를 발생시킨다.

interface NumberDictionary {
    [index: string]: number;
    length: number;    // 성공, length는 숫자입니다
    name: string;      // 오류, `name`의 타입은 인덱서의 하위타입이 아닙니다
}

하지만, 인덱스 시그니처가 프로퍼티 타입들의 합집합이라면 다른 타입의 프로퍼티들도 허용할 수 있다.

interface NumberOrStringDictionary {
    [index: string]: number | string;
    length: number;    // 성공, length는 숫자입니다
    name: string;      // 성공, name은 문자열입니다
}

마지막으로, 인덱스의 할당을 막기 위해 인덱스 시그니처를 읽기 전용으로 만들 수 있다.

interface ReadonlyStringArray {
    readonly [index: number]: string;
}
let myArray: ReadonlyStringArray = ["Alice", "Bob"];
myArray[2] = "Mallory"; // 오류!

인덱스 시그니처가 읽기 전용이기 때문에 myArray[2] 의 값을 할당할 수 없다.

8. 클래스 타입 (Class Types)

8-1. 인터페이스 구현하기 (Implementing an interface)

클래스가 특정 계약(contract)을 충족시키도록 명시적으로 강제하는 C#과 Java와 같은 언어에서 인터페이스를 사용하는 가장 일반적인 방법은 TypeScript에서도 가능하다.

interface ClockInterface {
    currentTime: Date;
}

class Clock implements ClockInterface {
    currentTime: Date = new Date();
    constructor(h: number, m: number) { }
}

아래 예제의 setTime 처럼 클래스에 구현된 메서드를 인터페이스 안에서도 기술할 수 있다.

interface ClockInterface {
    currentTime: Date;
    setTime(d: Date): void;
}

class Clock implements ClockInterface {
    currentTime: Date = new Date();
    setTime(d: Date) {
        this.currentTime = d;
    }
    constructor(h: number, m: number) { }
}

인터페이스는 클래스의 public과 private 모두보다는, public을 기술한다.
그래서 클래스 인스턴스의 private에서는 특정 타입이 있는지 검사할 수 없다.

9. 클래스의 스태틱과 인스턴스의 차이점 (Difference between the static and instance sides of classes)

클래스와 인터페이스를 다룰 때, 클래스는 스태틱 타입과 인스턴스 타입을 가진다는 것을 기억하는 게 좋다.
생성 시그니처 (construct signature)로 인터페이스를 생성하고, 클래스를 생성하려고 한다면, 인터페이스를 implements 할 때, 에러가 발생하는 것을 확인할 수 있을 것이다.

interface ClockConstructor {
    new (hour: number, minute: number);
}

class Clock implements ClockConstructor {
    currentTime: Date;
    constructor(h: number, m: number) { }
}

클래스가 인터페이스를 implements 할 때, 클래스의 인스턴스만 검사하기 때문이다.
생성자가 스태틱이기 때문에, 이 검사에 포함되지 않는다.
대신에, 클래스의 스태틱 부분을 직접적으로 다룰 필요가 있다.
이번 예제에서, ClockConstructor 는 생성자를 정의하고, ClockInterface 는 인스턴스 메서드를 정의하는 두 인터페이스를 정의한다.
그리고, 편의를 위해, 전달된 타입의 인스턴스를 생성하는 createClock 생성자 함수를 정의한다.

interface ClockConstructor {
    new (hour: number, minute: number): ClockInterface;
}
interface ClockInterface {
    tick(): void;
}

function createClock(ctor: ClockConstructor, hour: number, minute: number): ClockInterface {
    return new ctor(hour, minute);
}

class DigitalClock implements ClockInterface {
    constructor(h: number, m: number) { }
    tick() {
        console.log("beep beep");
    }
}
class AnalogClock implements ClockInterface {
    constructor(h: number, m: number) { }
    tick() {
        console.log("tick tock");
    }
}

let digital = createClock(DigitalClock, 12, 17);
let analog = createClock(AnalogClock, 7, 32);

createClock 의 첫 번째 매개변수는 createClock(AnalogClock, 7, 32) 안에 ClockConstructor 타입이므로, AnalogClock 이 올바른 생성자 시그니처를 갖고 있는지 검사한다.
또 다른 쉬운 방법은 클래스 표현을 사용하는 것이다.

interface ClockConstructor {
  new (hour: number, minute: number);
}

interface ClockInterface {
  tick();
}

const Clock: ClockConstructor = class Clock implements ClockInterface {
  constructor(h: number, m: number) {}
  tick() {
      console.log("beep beep");
  }
}

10. 인터페이스 확장하기 (Extending Interfaces)

클래스처럼, 인터페이스들도 확장(extend)이 가능하다.
이는 한 인터페이스의 멤버를 다른 인터페이스에 복사하는 것을 가능하게 해주는데, 인터페이스를 재사용성 높은 컴포넌트로 쪼갤 때, 유연함을 제공해준다.

interface Shape {
    color: string;
}

interface Square extends Shape {
    sideLength: number;
}

let square = {} as Square;
square.color = "blue";
square.sideLength = 10;

인터페이스는 여러 인터페이스를 확장할 수 있어, 모든 인터페이스의 조합을 만들어낼 수 있다.

interface Shape {
    color: string;
}

interface PenStroke {
    penWidth: number;
}

interface Square extends Shape, PenStroke {
    sideLength: number;
}

let square = {} as Square;
square.color = "blue";
square.sideLength = 10;
square.penWidth = 5.0;

11. 하이브리드 타입 (Hybrid Types)

일찍이 언급했듯이, 인터페이스는 실제 JavaScript 세계에 존재하는 다양한 타입들을 기술할 수 있다.
JavaScript의 동적이고 유연한 특성 때문에, 위에서 설명했던 몇몇 타입의 조합으로 동작하는 객체를 가끔 마주할 수 있다.
그러한 예제 중 하나는 추가적인 프로퍼티와 함께, 함수와 객체 역할 모두 수행하는 객체이다.

interface Counter {
    (start: number): string;
    interval: number;
    reset(): void;
}

function getCounter(): Counter {
    let counter = (function (start: number) { }) as Counter;
    counter.interval = 123;
    counter.reset = function () { };
    return counter;
}

let c = getCounter();
c(10);
c.reset();
c.interval = 5.0;

써드파티 (3rd-party) JavaScript와 상호작용할 때, 타입의 형태를 완전히 기술하기 위해 위와 같은 패턴을 사용해야할 수도 있다.

12. 클래스를 확장한 인터페이스 (Interfaces Extending Classes)

인터페이스 타입이 클래스 타입을 확장하면, 클래스의 멤버는 상속받지만 구현은 상속받지 않는다.
이것은 인터페이스가 구현을 제공하지 않고, 클래스의 멤버 모두를 선언한 것과 마찬가지이다. 인터페이스는 심지어 기초 클래스의 private과 protected 멤버도 상속받는다.
이것은 인터페이스가 private 혹은 protected 멤버를 포함한 클래스를 확장할 수 있다는 뜻이고, 인터페이스 타입은 그 클래스나 하위클래스에 의해서만 구현될 수 있다.
이는 거대한 상속계층을 가지고 있을 때 유용하지만, 특정 프로퍼티를 가진 하위클래스에서만 코드가 동작하도록 지정하는데도 유용하다.
하위클래스는 기초클래스에서 상속하는 것 외에는 관련이 있을 필요가 없다.

class Control {
    private state: any;
}

interface SelectableControl extends Control {
    select(): void;
}

class Button extends Control implements SelectableControl {
    select() { }
}

class TextBox extends Control {
    select() { }
}

// Error: Property 'state' is missing in type 'Image'.
class Image implements SelectableControl {
    private state: any;
    select() { }
}

class Location {

}

위 예제에서, SelectableControl 은 private state 프로퍼티를 포함하여, Control의 모든 멤버를 가지고 있다.
state는 private 멤버이기 때문에, SelectableControl 를 구현하는 것은 Control 의 자식에게만 가능하다.
Control 의 자식만 같은 선언에서 유래된 state private 멤버를 가질수 있기 때문이고, private 멤버들이 호환되기 위해 필요하다.
Control 클래스 안에서 SelectableControl 의 인스턴스를 통해서 state private 멤버에 접근할 수 있다.
SelectableControl 은 select 메서드를 가진 Control 과 같은 역할을 한다.
Button 과 TextBox 클래스들은 SelectableControl 의 하위타입이지만 (Control 을 상속받고, select 메서드를 가지기 때문에), Image 와 Location 클래스는 아니다.

TypeScript HandBook

TypeScript HandBook 번역 문서

Wikipedia

TypeScript 알아보기 (1)

Fri, 15 Dec 2023 04:42:29 GMT

시작 동기

프로젝트 진행 중, TypeScript 사용 시, type을 부정확하게 사용하고 있지는 않는지, 제대로 사용하고 있는지 검토할까 생각하다 긴 생각않고 그냥 진행해보기로 하였다.
그리하여 TypeScript를 차근차근 정독해보며 정리해보려한다.

Chapter 1. 기본 타입

학습 목차

1. 소개 (Introduction) 2. 불리언 (Boolean) 3. 숫자 (Number) 4. 문자열 (String) 5. 배열 (Array) 6. 튜플 (Tuple) 7. 열거 (Enum) 8. Any 9. Void 10. Null and Undefined 11. Never 12. 객체 (Object) 13. 타입 단언 (Type assertions) 14. 'let'에 관하여

1. 소개 (Introduction)

프로그램이 유용하려면 숫자, 문자열, 구조체, 불리언 값과 같은 간단한 데이터 단위가 필요하다.
TypeScript는 JavaScript와 거의 동일한 데이터 타입을 지원하며, 열거 타입을 사용하여 더 편리하게 사용할 수 있습니다.

2. 불리언 (Boolean)

가장 기본적인 데이터 타입은 JavaScript, TypeScript에서 boolean 값이라고 일컫는 참/거짓(true/false) 값이다.

  let isDone: boolean = false;

3. 숫자 (Number)

JavaScript처럼, TypeScript의 모든 숫자는 부동 소수 값이다.
부동 소수에는 number 라는 타입이 붙혀진다.
TypeScript는 16진수, 10진수 리터럴에 더불어, ECMAScript 2015에 소개된 2진수, 8진수 리터럴도 지원한다.
```
let decimal: number = 6;
 let hex: number = 0xf00d;
 let binary: number = 0b1010;
 let octal: number = 0o744;
```

4. 문자열 (String)

웹 페이지, 서버 같은 프로그램을 JavaScript로 만들 때 기본적으로 텍스트 데이터를 다루는 작업이 필요하다.
다른 언어들처럼, TypeScript에서는 텍스트 데이터 타입을 string 으로 표현한다.
JavaScript처럼 TypeScript도 큰따옴표 (")나 작은따옴표 (')를 문자열 데이터를 감싸는데 사용한다.
```
let color: string = "blue";
 color = 'red';
```
또한 템플릿 문자열 을 사용하면 여러 줄에 걸쳐 문자열을 작성할 수 있으며, 표현식을 포함시킬 수도 있다.

이 문자열은 백틱/백쿼트 (`) 문자로 감싸지며, ${ expr } 과 같은 형태로 표현식을 포함시킬 수 있다.

let fullName: string = `Bob Bobbington`;
 let age: number = 37;
 let sentence: string = `Hello, my name is ${ fullName }.
 I'll be ${ age + 1 } years old next month.`;

위는 아래 sentence 선언과 동일하다.

  let sentence: string = "Hello, my name is " + fullName + ".\n\n" +
    "I'll be " + (age + 1) + " years old next month.";

5. 배열 (Array)

TypeScript는 JavaScript처럼 값들을 배열로 다룰 수 있게 해준다. 배열 타입은 두 가지 방법으로 쓸 수 있다.
- 첫 번째 방법은, 배열 요소들을 나타내는 타입 뒤에 []를 쓰는 것이다.
```
let list: number[] = [1, 2, 3];
```
- 두 번째 방법은 제네릭 배열 타입을 쓰는 것이다. Array
```
let list: Array = [1, 2, 3];
```

6. 튜플 (Tuple)

튜플 타입을 사용하면, 요소의 타입과 개수가 고정된 배열을 표현할 수 있다. 단 요소들의 타입이 모두 같을 필요는 없다.

예를 들어, number, string 이 쌍으로 있는 값을 나타내고 싶을 수 있다.

// 튜플 타입으로 선언
 let x: [string, number];

 // 초기화
 x = ["hello", 10]; // 성공

 // 잘못된 초기화
 x = [10, "hello"]; // 오류

정해진 인덱스에 위치한 요소에 접근하면 해당 타입이 나타난다.

console.log(x[0].substring(1)); // 성공
 console.log(x[1].substring(1)); // 오류, 'number'에는 'substring' 이 없다.

정해진 인덱스 외에 다른 인덱스에 있는 요소에 접근하면, 오류가 발생하며 실패한다.

x[3] = "world"; // 오류, '[string, number]' 타입에는 프로퍼티 '3'이 없다.
 console.log(x[5].toString()); // '[string, number]' 타입에는 프로퍼티 '5'가 없다.

7. 열거 (Enum)

JavaScript의 표준 자료형 집합과 사용하면 도움이 될만한 데이터 형은 enum 이다.
C# 같은 언어처럼, enum 은 값의 집합에 더 나은 이름을 붙여줄 수 있다.
```
enum Color {Red, Green, Blue}
 let c: Color = Color.Green;
```
기본적으로, enum 은 0 부터 시작하여 멤버들의 번호를 매긴다. 멤버 중 하나의 값을 수동으로 설정하여 번호를 바꿀 수 있다. 예를 들어, 위 예제를 0 대신 1 부터 시작해 번호를 매기도록 바꿀 수 있다.
```
enum Color {Red = 1, Green, Blue}
 let c: Color = Color.Green;
```

또는, 모든 값을 수동으로 설정할 수 있다.

  enum Color {Red = 1, Green = 2, Blue = 4}
   let c: Color = Color.Green;

enum 의 유용한 기능 중 하나는 매겨진 값을 사용해 enum 멤버의 이름을 알아낼 수 있다는 것이다. 예를 들어, 위의 예제에서 2 라는 값이 위의 어떤 Color enum 멤버와 매칭되는지 알 수 없을 때, 이에 일치하는 이름을 알아낼 수 있다.
```
enum Color {Red = 1, Green, Blue}
 let colorName: string = Color[2];

 console.log(colorName); // 값이 2인 'Green'이 출력됩니다.
```

8. Any

애플리케이션을 만들 때, 알지 못하는 타입을 표현해야 할 수도 있다. 이 값들은 사용자로부터 받은 데이터나 서드 파티 라이브러리 같은 동적인 컨텐츠에서 올 수도 있다.

이 경우 타입 검사를 하지 않고, 그 값들이 컴파일 시간에 검사를 통과하길 원한다. 이를 위해, any 타입을 사용할 수 있다.

  let notSure: any = 4;
   notSure = "maybe a string instead";
   notSure = false; // 성공, 분명히 부울입니다.

any 타입은 기존에 JavaScript로 작업할 수 있는 강력한 방법으로, 컴파일 중에 점진적으로 타입 검사를 하거나 하지 않을 수 있다.
혹 다른 언어에서 그렇듯, Object가 비슷한 역할을 할 수 있을 것 같다고 생각할 수도 있다.

그런데, Object로 선언된 변수들은 오직 어떤 값이든 그 변수에 할당할 수 있게 해주지만 실제로 메서드가 존재하더라도, 임의로 호출할 수는 없다.

let notSure: any = 4;
 notSure.ifItExists(); // 성공, ifItExists 는 런타임엔 존재할 것이다.
 notSure.toFixed(); // 성공, toFixed는 존재한다. (하지만 컴파일러는 검사하지 않음)

 let prettySure: Object = 4;
 prettySure.toFixed(); // 오류: 프로퍼티 'toFixed'는 'Object'에 존재하지 않는다.

KeyNote

Do's and Don'ts에 설명 했듯이 Object를 no-primitive object 대신에 사용하지 말자.

또한, any 타입은 타입의 일부만 알고 전체는 알지 못할 때 유용하다. 예를 들어, 여러 다른 타입이 섞인 배열을 다룰 수 있다.
```
let list: any[] = [1, true, "free"];

 list[1] = 100;
```

9. Void

void 는 어떤 타입도 존재할 수 없음을 나타내기 때문에, any 의 반대 타입 같다. void 는 보통 함수에서 반환 값이 없을 때 반환 타입을 표현하기 위해 쓰이는 것을 볼 수 있다.
```
function warnUser(): void {
  console.log("This is my warning message");
}
```
void를 타입 변수를 선언하는 것은 유용하지 않은데, 왜냐하면 그 변수에는 null(--strictNullChecks 을 사용하지 않을 때만 해당, 자세한 건 다음 섹션을 참고)또는 undefined 만 할당할 수 있기 때문이다.
```
let unusable: void = undefined;
 unusable = null; // 성공  `--strictNullChecks` 을 사용하지 않을때만
```

10. Null and Undefined

TypeScript는 undefined 과 null 둘 다 각각 자신의 타입 이름으로 undefined , null 로 사용한다. void 처럼 그 자체로 유용한 경우는 거의 없다.
```
// 이 밖에 이 변수들에 할당할 수 있는 값이 없습니다!
 let u: undefined = undefined;
 let n: null = null;
```
기본적으로 null 과 undefined 는 다른 모든 타입의 하위 타입이다.
이건, null과 undefined를 number 같은 타입에 할당할 수 있다는 것을 의미한다.
하지만, --strictNullChecks를 사용하면, null 과 undefined 는 오직 any 와 각자 자신들 타입에만 할당 가능하다. (예외적으로 undefined는 void에 할당 가능하다.)
이건 많은 일반적인 에러를 방지하는 데 도움을 준다. 이 경우, string 또는 null 또는 undefined 를 허용하고 싶은 경우 유니언 타입인 string | null | undefined 를 사용할 수 있다.

KeyNote
- 가능한 경우 --strictNullChecks 를 사용할 것을 권장한다. 하지만 핸드북의 목적에 따라, 사용하지 않는다고 가정한다.

11. Never

never 타입은 절대 발생할 수 없는 타입을 나타낸다. 예를 들어, never는 함수 표현식이나 화살표 함수 표현식에서 항상 오류를 발생시키거나 절대 반환하지 않는 반환 타입으로 쓰인다.
변수 또한 타입 가드에 의해 아무 타입도 얻지 못하게 좁혀지면 never 타입을 얻게 될 수 있다.
never타입은 모든 타입에 할당 가능한 하위 타입이다.
하지만 어떤 타입도 never에 할당할 수 있거나, 하위 타입이 아닙니다.(never 자신은 제외) 심지어 any 도 never에 할당할 수 없다.

아래는 never를 반환하는 몇 가지 예제이다.

// never를 반환하는 함수는 함수의 마지막에 도달할 수 없다.
 function error(message: string): never {
   throw new Error(message);
 }

 // 반환 타입이 never로 추론된다.
 function fail() {
  return error("Something failed");
 }

 // never를 반환하는 함수는 함수의 마지막에 도달할 수 없다.
 function infiniteLoop(): never {
   while (true) {
     }
 }

12. 객체 (Object)

object 는 원시 타입이 아닌 타입을 나타낸다. 예를 들어, number, string, boolean, bigint, symbol, null 또는 undefined 가 아닌 나머지를 의미한다.

object 타입을 쓰면, Object.create 같은 API 가 더 잘 나타난다.

declare function create(o: object | null): void;

 create({ prop: 0 }); // 성공
 create(null); // 성공

 create(42); // 오류
 create("string"); // 오류
 create(false); // 오류
 create(undefined); // 오류

13. 타입 단언 (Type assertions)

가끔, TypeScript보다 개발자가 값에 대해 더 잘 알고 일을 때가 있다.
대개, 이런 경우는 어떤 엔티티의 실제 타입이 현재 타입보다 더 구체적일 때 발생한다.
타입 단언(Type assertions) 은 컴파일러에게 "날 믿어, 난 내가 뭘 하고 있는지 알아"라고 말해주는 방법이다.
타입 단언 은 다른 언어의 타입 변환(형 변환)과 유사하지만, 다른 특별한 검사를 하거나 데이터를 재구성하지는 않는다.
이는 런타임에 영향을 미치지 않으며, 온전히 컴파일러만 이를 사용한다.
타입 스크립트는 개발자가 필요한 어떤 특정 검사를 수행했다고 인지한다.

타입 단언에는 두 가지 형태가 있다.

하나는, "angle-bracket" 문법이다.

 let someValue: any = "this is a string";

  let strLength: number = (someValue).length;

다른 하나는 as -문법이다.

let someValue: any = "this is a string";

let strLength: number = (someValue as string).length;

위 두 예제는 동일하다.

어떤 것을 사용할지는 주로 선호에 따른 선택이다.
하지만 TypeScript를 JSX와 함께 사용할 때는, as -스타일의 단언만 허용된다.

14. 'let'에 관하여

지금까지 더 익숙할 수도 있는 JavaScript의 var 키워드 대신 let 키워드를 이용했다는 걸 알 수 있다.
let 키워드는 JavaScript ES2015에서 소개되었고, var 보다 안전하다는 이유로, 현재 표준으로 여겨지고 있다.
대부분의 JavaScript의 문제들이 let 을 사용해서 해결되며, 때문에 가능한 경우 최대한 var 대신 let 을 사용하여야 한다.

TypeScript HandBook

TypeScript HandBook 번역 문서

Wikipedia

https://school.programmers.co.kr/learn/courses/30/parts/12077

Hash

Thu, 14 Dec 2023 09:01:01 GMT

1. Hash란?

해시 함수(hash function) 또는 해시 알고리즘(hash algorithm) 또는 해시함수 알고리즘은 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 함수이다. 해시 함수에 의해 얻어지는 값은 해시 값, 해시 코드, 해시 체크섬 또는 간단하게 해시라고 한다. 그 용도 중 하나는 해시 테이블이라는 자료구조에 사용되며, 매우 빠른 데이터 검색을 위한 컴퓨터 소프트웨어에 널리 사용된다.
해시 함수는 큰 파일에서 중복되는 레코드를 찾을 수 있기 때문에 데이터베이스 검색이나 테이블 검색의 속도를 가속할 수 있다.
암호용 해시 함수는 매핑된 해싱 값만을 알아가지고는 원래 입력 값을 알아내기 힘들다는 사실에 의해 사용될 수 있다. 또한 전송된 데이터의 무결성을 확인해주는 데 사용되기도 하는데, 메시지가 누구에게서 온 것인지 입증해주는 HMAC를 구성하는 블록으로 사용된다.
해시 함수는 결정론적으로 작동해야 하며, 따라서 두 해시 값이 다르다면 그 해시값에 대한 원래 데이터도 달라야 한다. (역은 성립하지 않는다)
해시 함수의 질은 입력 영역에서의 해시 충돌 확률로 결정되는데, 해시 충돌의 확률이 높을수록 서로 다른 데이터를 구별하기 어려워지고 검색하는 비용이 증가하게 된다.

Recap

해시함수는 하나의 주어진 출력에 대하여 이 출력으로 사상시키는 하나의 입력을 찾는 것이 계산적으로 불가능하고, 하나의 주어진 입력에 대하여 같은 출력으로 사상시키는 또 다른 입력을 찾는 것이 계산적으로 불가능하다는 두 가지 성질을 만족하면서 임의의 비트열을 고정된 길이의 비트열로 사상시키는 함수이다.

2. Hash의 특징

같은 종류의 자료를 묶어서 파악할 수 있다.

3. 알고리즘

해시함수 알고리즘은 긴 길이의 데이터를 짧은 길이의 데이터로 변환하는 알고리즘으로 따라서 제3자는 짧은 길이의 데이터로부터 원래의 데이터를 복구할 수 없어야 하며, 동일한 출력을 갖는 서로 다른 데이터를 찾을 수 없어야 한다.

4. 예시

프로그래머스,해시,완주하지 못한 선수 with JavaScript

문제

수많은 마라톤 선수들이 마라톤에 참여하였습니다. 단 한 명의 선수를 제외하고는 모든 선수가 마라톤을 완주하였습니다.
마라톤에 참여한 선수들의 이름이 담긴 배열 participant와 완주한 선수들의 이름이 담긴 배열 completion이 주어질 때, 완주하지 못한 선수의 이름을 return 하도록 solution 함수를 작성해주세요.
제한사항 마라톤 경기에 참여한 선수의 수는 1명 이상 100,000명 이하입니다. completion의 길이는 participant의 길이보다 1 작습니다. 참가자의 이름은 1개 이상 20개 이하의 알파벳 소문자로 이루어져 있습니다. 참가자 중에는 동명이인이 있을 수 있습니다.
```
function solution(participant, completion) {
  var answer = '';
  return answer;
}
```

해답

function solution(participant, completion) {
    const map = new Map();
    for(let i = 0; i < participant.length; i++) {
        let a = participant[i], 
            b = completion[i];
        map.set(a, (map.get(a) || 0) + 1);
        map.set(b, (map.get(b) || 0) - 1);
    }
    for(let [k, v] of map) {
        if(v > 0) return k;
    }
    return 'nothing';
}

회고

본인이 작성한 코드보다 가독성이 좋은 코드를 들고 옴.
가독성이 좋고 예쁜(?)코드를 짜려고 할 때 마다 더욱 어렵게 생각함.
문제를 코드화 시키는 능력과, 해당 코드로 간결하고 가독성 좋게 하려는 코드를 작성하는 방향으로 하자.

Programmers - Hash

Wikipedia - Hash

https://ko.wikipedia.org/wiki/%ED%95%B4%EC%8B%9C_%ED%95%A8%EC%88%98

Greedy algorithm

Wed, 13 Dec 2023 14:57:10 GMT

1. 탐욕 알고리즘(Greedy algorithm)이란?

탐욕 알고리즘(Greedy algorithm) 은 최적의 해를 구하는 데에 사용되는 근사적인 방법 으로, 여러 경우 중 하나를 결정해야 할 때마다 그 순간에 최적이라고 생각되는 것을 선택해 나가는 방식으로 진행하여 최종적인 해답에 도달한다.
순간마다 하는 선택은 그 순간에 대해 지역적으로는 최적이지만, 그 선택들을 계속 수집하여 최종적(전역적)인 해답을 만들었다고 해서, 그것이 최적이라는 보장은 없다.
하지만 탐욕알고리즘을 적용할 수 있는 문제들은 지역적으로 최적이면서 전역적으로 최적인 문제들이다.

2. 탐욕(Greedy)의 조건

탐욕 알고리즘이 잘 작동하는 문제는 대부분 탐욕스런 선택 조건(greedy choice property)과 최적 부분 구조 조건(optimal substructure)이라는 두 가지 조건이 만족된다. 탐욕스런 선택 조건은 앞의 선택이 이후의 선택에 영향을 주지 않는다는 것이며, 최적 부분 구조 조건은 문제에 대한 최적해가 부분문제에 대해서도 역시 최적해라는 것이다.
이러한 조건이 성립하지 않는 경우에는 탐욕 알고리즘은 최적해를 구하지 못한다. 하지만, 이러한 경우에도 탐욕 알고리즘은 근사 알고리즘으로 사용이 가능할 수 있으며, 대부분의 경우 계산 속도가 빠르기 때문에 실용적으로 사용할 수 있다. 이 경우 역시 어느 정도까지 최적해에 가까운 해를 구할 수 있는지를 보장하려면 엄밀한 증명이 필요하다.
어떤 특별한 구조가 있는 문제에 대해서는 탐욕 알고리즘이 언제나 최적해를 찾아낼 수 있다. 이 구조를 매트로이드라 한다. 매트로이드는 모든 문제에서 나타나는 것은 아니나, 여러 곳에서 발견되기 때문에 탐욕 알고리즘의 활용도를 높여 준다.

3. 예시

프로그래머스, 탐욕법, 체육복 with JavaScript

문제

점심시간에 도둑이 들어, 일부 학생이 체육복을 도난당했습니다. 다행히 여벌 체육복이 있는 학생이 이들에게 체육복을 빌려주려 합니다. 학생들의 번호는 체격 순으로 매겨져 있어, 바로 앞번호의 학생이나 바로 뒷번호의 학생에게만 체육복을 빌려줄 수 있습니다. 예를 들어, 4번 학생은 3번 학생이나 5번 학생에게만 체육복을 빌려줄 수 있습니다. 체육복이 없으면 수업을 들을 수 없기 때문에 체육복을 적절히 빌려 최대한 많은 학생이 체육수업을 들어야 합니다.
전체 학생의 수 n, 체육복을 도난당한 학생들의 번호가 담긴 배열 lost, 여벌의 체육복을 가져온 학생들의 번호가 담긴 배열 reserve가 매개변수로 주어질 때, 체육수업을 들을 수 있는 학생의 최댓값을 return 하도록 solution 함수를 작성해주세요.
제한사항 전체 학생의 수는 2명 이상 30명 이하입니다. 체육복을 도난당한 학생의 수는 1명 이상 n명 이하이고 중복되는 번호는 없습니다. 여벌의 체육복을 가져온 학생의 수는 1명 이상 n명 이하이고 중복되는 번호는 없습니다. 여벌 체육복이 있는 학생만 다른 학생에게 체육복을 빌려줄 수 있습니다. 여벌 체육복을 가져온 학생이 체육복을 도난당했을 수 있습니다. 이때 이 학생은 체육복을 하나만 도난당했다고 가정하며, 남은 체육복이 하나이기에 다른 학생에게는 체육복을 빌려줄 수 없습니다.
```
function solution(n, lost, reserve) {
  var answer = 0;
  return answer;
}
```

해답

function solution(n, lost, reserve) {
    const students = {};
    let answer = 0;
    for(let i = 1; i <= n; i++){
        students[i] = 1;
    }
    lost.forEach(number => students[number] -= 1);
    reserve.forEach(number => students[number] += 1);
    for(let i = 1; i <= n; i++){
        if(students[i] === 2 && students[i-1] === 0){
                students[i-1]++;
                students[i]--;
        } else if(students[i] === 2 && students[i+1] === 0){
                students[i+1]++;
                students[i]--;
        }
    }
    for(let key in students){
        if(students[key] >= 1){
            answer++;
        }
    }
    return answer;
}

회고

본인이 작성한 코드보다 가독성이 좋은 코드를 들고 옴.
이런 코드를 볼 때마다 현타가 강하게 오지만 현타만큼 더욱 배우고자하는 열정이 생김.
어려운 코드보다 가독성이 좋은 코드를 작성하려고 하자.

Programmers - Greedy

https://school.programmers.co.kr/learn/courses/30/parts/12244

Wikipedia - Greedy algorithm

https://ko.wikipedia.org/wiki/%ED%83%90%EC%9A%95_%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98

DFS & BFS

Mon, 11 Dec 2023 14:58:57 GMT

1. DFS

1-1. DFS란?

깊이 우선 탐색(depth-first search, DFS)은 맹목적 탐색방법의 하나로 탐색트리의 최근에 첨가된 노드를 선택한다. 그 다음 이 노드에 적용 가능한 동작자 중 하나를 적용하여 트리에 다음 수준(level)의 한 개의 자식노드를 첨가하고, 첨가된 자식 노드가 목표노드일 때까지 앞의 자식 노드의 첨가 과정을 반복해 가는 방식이다.

1-2. 깊이 제한과 백트래킹

탐색 과정이 시작 노드에서 한없이 깊이 진행되는 것을 막기 위해 깊이 제한(depth bound)을 사용한다.
깊이 제한에 도달할 때까지 목표노드가 발견되지 않으면 최근에 첨가된 노드의 부모노드로 되돌아와서, 부모노드에 이전과는 다른 동작자를 적용하여 새로운 자식노드를 생성한다. 여기서 부모노드로 되돌아오는 과정을 백트래킹(backtracking)이라 한다.

1-3. 알고리즘

만일 트리가 아닌 그래프를 탐색하게 된다면 약간의 변화가 필요하다.
우선 그래프에서의 깊이(depth)를 결정할 필요가 있다. 일반적으로 그래프에서는 루트 노드의 깊이를 0으로 하며, 임의의 노드의 깊이는 이의 부모 중 가장 깊이가 작은 것의 깊이에 1을 더한 값으로 정의한다. 따라서 그래프에서의 깊이우선탐색은 OPEN에 있는 노드 중 가장 깊은 것을 택하여 확장시키게 된다. 후계 노드가 생성되어 이 중에 이미 OPEN이나 CLOSED에 있는 것이 있다면, 깊이를 재조정하여야 한다.
여기서 알 수 있는 것은 일반적인 그래프를 탐색하는 경우라도, 탐색 과정에 의하여 얻어지는 노드들과 포인터들은 역시 탐색 트리를 형성한다는 것이다. 즉, 포인터들은 오직 하나의 부모를 가리키게 된다.

1-4. 장단점

장점
- 단지 현 경로상의 노드들만을 기억하면 되므로 저장공간의 수요가 비교적 적다.
- 목표노드가 깊은 단계에 있을 경우 해를 빨리 구할 수 있다.
단점
- 해가 없는 경로에 깊이 빠질 가능성이 있다. 따라서 실제의 경우 미리 지정한 임의의 깊이까지만 탐색하고 목표노드를 발견하지 못하면 다음의 경로를 따라 탐색하는 방법이 유용할 수 있다.
- 얻어진 해가 최단 경로가 된다는 보장이 없다. 이는 목표에 이르는 경로가 다수인 문제에 대해 깊이우선 탐색은 해에 다다르면 탐색을 끝내버리므로, 이때 얻어진 해는 최적이 아닐 수 있다는 의미이다.

1-5. 시간과 저장공간 분석

깊이 우선 탐색에서 필요로 하는 시간과 저장공간을 분석해 보면, 일반적으로는 시간에 대해 말하기가 좀 어려운데, 이는 트리가 무한할 경우, 깊이우선 탐색은 목적을 만족시키는 노드를 찾지 못할 수도 있을 뿐 아니라 알고리즘이 끝나지 않을 수도 있기 때문이다. 트리의 깊이가 목적 노드 깊이와 같을 때에는 최악의 경우 모든 노드를 다 검사하게 된다.
이 경우 전체 시간은 $$ 1+b+b^{2}+\cdots +b^{d}={\frac {b^{{d+1}}-1}{b-1}} $$ 이 된다.
깊이우선 탐색에 의해 방문된 노드수의 평균은 $$ {\frac {b^{{d+1}}+db+b-d-2}{2(b-1)}} $$ 인데, 이것은 $d+1$과 ${\frac {b^{{d+1}}-1}{b-1}}$ 의 평균이며, 이 때 $d+1$은 목적 노드가 제일 왼쪽에 있을 때 방문하게 되는 노드의 수이고, ${\frac {b^{{d+1}}-1}{b-1}}$ 은 목적 노드가 탐색트리의 맨 오른쪽에 있을 때 방문하는 노드의 수이다.
저장공간의 사용량을 계산해 보면 좀 더 희망적인 결과를 얻을 수 있다.
탐색공간 내의 각 노드 $n$에서 깊이우선 탐색 알고리즘이 기억해야 할 것은 루트 노드로부터 $n$까지의 경로 상에 있는 각 노드의 자식들 중 $n$을 제외한 것들이다. 그러한 경로 중 가장 긴 경로의 길이가 $d$이므로, 최악의 경우 깊이우선 탐색은 $d(b-1)+1$에 비례하는 비교적 적은 공간을 사용한다. 연구 결과에 따르면 깊이우선 탐색은 저장공간의 사용에 있어서 점근 최적인 것으로 알려져 있다.

2. BFS

2-1. BFS란?

너비 우선 탐색(Breadth-first search, BFS)은 맹목적 탐색방법의 하나로 시작 정점을 방문한 후 시작 정점에 인접한 모든 정점들을 우선 방문하는 방법이다. 더 이상 방문하지 않은 정점이 없을 때까지 방문하지 않은 모든 정점들에 대해서도 너비 우선 검색을 적용한다. OPEN List는 큐를 사용해야만 레벨 순서대로 접근이 가능하다.

2-2. 장단점

장점
- 출발노드에서 목표노드까지의 최단 길이 경로를 보장한다.
단점
- 경로가 매우 길 경우에는 탐색 가지가 급격히 증가함에 따라 보다 많은 기억 공간을 필요로 하게 된다.
- 해가 존재하지 않는다면 유한 그래프(finite graph)의 경우에는 모든 그래프를 탐색한 후에 실패로 끝난다.
- 무한 그래프(infinite graph)의 경우에는 결코 해를 찾지도 못하고, 끝내지도 못한다.

Wikipedia - DFS

https://ko.wikipedia.org/wiki/%EA%B9%8A%EC%9D%B4_%EC%9A%B0%EC%84%A0_%ED%83%90%EC%83%89

Wikipedia - BFS

https://ko.wikipedia.org/wiki/%EB%84%88%EB%B9%84_%EC%9A%B0%EC%84%A0_%ED%83%90%EC%83%89

React 공식문서 이해하기 (30)

Sun, 10 Dec 2023 11:58:50 GMT

Chapter 4. Escape Hatches

#8 커스텀 훅으로 로직 재사용하기

학습 목차

1. 커스텀 훅: 컴포넌트간의 로직 공유 2. 훅 사이에 반응형 값 전달하기 3. 언제 커스텀 훅을 사용할 것인가

1. 커스텀 훅: 컴포넌트간의 로직 공유

대부분의 앱이 그렇듯이 네트워크에 크게 의존하는 앱을 개발한다고 가정해 보자. 사용자가 앱을 사용하는 동안 실수로 네트워크 연결이 끊어진 경우 사용자에게 주의를 줄 경우 어떻게 하면 좋을까? 이럴 경우에 컴포넌트에는 두 가지가 필요하다.
1. 네트워크가 온라인 상태인지 여부를 추적하는 state
2. 전역 online 및 offline 이벤트를 구독하고, state를 업데이트하는 Effect
이렇게 하면 컴포넌트가 네트워크 state와 동기화된 상태로 유지된다.

1-1. 컴포넌트에서 커스텀 훅 추출하기

컴포넌트 내부의 코드가 (브라우저 이벤트에 가입하여) 어떻게 할 것인가가 아니라 무엇을 할 것인가(온라인 상태 사용!)를 설명한다는 점이다.
로직을 커스텀 훅으로 추출하면 외부 시스템이나 브라우저 API를 처리하는 방법에 대한 지저분한 세부 사항을 숨길 수 있다. 컴포넌트의 코드는 구현_이 아니라 _의도를 표현한다.

1-2. 훅의 이름은 언제나 use로 시작된다.

React 애플리케이션은 컴포넌트로 빌드된다.
컴포넌트는 빌트인이든 커스텀이든 상관없이 훅으로 빌드된다.
다른 사람이 만든 커스텀 훅을 사용하는 경우가 많지만, 가끔은 직접 작성할 수도 있다. 이때는 다음 명명 규칙을 따라야 한다.
1. React 컴포넌트 이름은 StatusBar나 SaveButton과 같이 대문자로 시작해야한다. 또한 React 컴포넌트는 JSX와 같이 React가 표시하는 방법을 알고 있는 것을 반환해야한다.
2. 훅의 이름은 useState(빌트인)이나 useOnlineStatus(커스텀)처럼 use로 시작해야 하고, 그 다음의 첫글자는 대문자여야 합니다. 훅은 임의의 값을 반환할 수 있습니다.
이 규칙은 컴포넌트를 보고 state, Effect 및 기타 React 기능이 어디에 “숨어 있는지” 항상 알 수 있도록 보장합니다.

KeyNote

Linter가 React용으로 구성된 경우, 이 명명 규칙을 적용한다. 오직 훅과 컴포넌트만이 다른 훅을 호출할 수 있다.

1-3. 커스텀 훅은 state 자체가 아닌 상태적인 로직(stateful logic)을 공유한다.

커스텀 훅을 사용하면 상태 로직(stateful logic)은 공유할 수 있지만 state 자체는 공유할 수 없다.
각 훅 호출은 동일한 훅에 대한 다른 모든 호출과 완전히 독립적이다.
여러 컴포넌트 간에 state 자체를 공유해야 하는 경우, 대신 끌어올려 전달하기를 사용하자.

2. 훅 사이에 반응형 값 전달하기

컴포넌트를 다시 렌더링할 때마다 커스텀 훅 내부의 코드가 다시 실행된다. 이것이 컴포넌트와 마찬가지로 커스텀 훅도 순수해야 하는 이유이다. 커스텀 Hook의 코드를 컴포넌트 본문의 일부로 생각하자.
커스텀 훅은 컴포넌트와 함께 다시 렌더링되기 때문에 항상 최신 props와 state를 받는다.

2-1. 커스텀훅에게 이벤트 핸들러 전달하기

3. 언제 커스텀 훅을 사용할 것인가

중복되는 모든 코드에 대해 커스텀 훅을 추출할 필요는 없다. 약간의 중복은 괜찮다.
하지만 Effect를 작성할 때마다 커스텀 훅으로 감싸는 것이 더 명확할지 고려하자. Effect는 자주 필요하지 않으므로, 만약 Effect를 작성한다면 외부 시스템과 동기화하거나 React에 빌트인 API가 없는 작업을 수행하기 위해 “React 외부로 나가야 한다”는 뜻이다.
Effect를 커스텀 훅으로 감싸면 의도와 데이터 흐름 방식을 정확하게 전달할 수 있다.

3-1. 커스텀 훅은 더 나은 패턴으로 마이그레이션하는데 도움을 준다.

마이그레이션을 위해 컴포넌트를 변경할 필요가 없다.
Effect는 “탈출구”:이다. “React를 벗어나야 할 때”, 그리고 사용 사례에 더 나은 빌트인 솔루션이 없을 때 사용한다. 시간이 지남에 따라 React 팀의 목표는 더 구체적인 문제에 대한 더 구체적인 솔루션을 제공함으로써 앱에서 Effect의 수를 최소한으로 줄이는 것이다. Effect를 커스텀 훅으로 감싸면 이러한 솔루션이 제공될 때 코드를 더 쉽게 업그레이드할 수 있다.
아래가 커스텀 훅으로 Effect를 감싸는 것이 좋은이유 중 하나이다.
1. Effect와의 데이터 흐름을 매우 명확하게 만들 수 있다.
2. 컴포넌트가 Effect의 정확한 구현보다는 의도에 집중할 수 있다.
3. React가 새로운 기능을 추가할 때 컴포넌트를 변경하지 않고도 해당 Effect를 제거할 수 있다.
디자인 시스템과 유사하게 앱의 컴포넌트에서 공통된 관용구를 추출하여 커스텀 훅으로 만드는 것이 도움이 될 수 있다. 이렇게 하면 컴포넌트의 코드가 의도에 집중할 수 있고, 원시 Effect를 자주 작성하는 것을 피할 수 있다. React 커뮤니티에서 관리하고 있는 훌륭한 커스텀 훅도 많이 있다.

요약

커스텀 훅을 사용하면 컴포넌트 간에 로직을 공유할 수 있다.
커스텀 훅의 이름은 use로 시작하고 대문자로 끝나야한다.
커스텀 훅은 상태적 로직만 공유하며 state 자체는 공유하지 않는다.
반응형 값을 한 훅에서 다른 훅으로 전달할 수 있으며 최신 state로 유지된다.
컴포넌트가 다시 렌더링될 때마다 모든 훅이 다시 실행된다.
커스텀 훅의 코드는 컴포넌트의 코드와 같이 순수해야한다.
커스텀 훅이 수신한 이벤트 핸들러를 Effect Event로 감싸자.
useMount와 같은 커스텀 훅을 만들지 마세요. 용도를 명확히 하라.
코드의 경계를 어디에서 어떻게 선택할지는 여러분이 결정할 수 있다.

회고

공식문서를 정독하며 정답이지만 모든 것이 정답은 아닌듯 했다.
여러 예시들이 있어 정리하기 힘들었지만 이해하기에는 그보다 더 용이했다.
당장 프로젝트에 적용하여 사용할 수는 있겠지만 러닝커브로 인해 다소 걸릴 것으로 보인다.
React를 사용한다면, 학생 때 영어 단어 외우듯 자주 공식문서를 봐줘야겠다는 생각이 든다.

React 공식 문서

React 비공식 번역 문서

MDN

Wikipedia

2-1. 이 코드를 이벤트 핸들러로 옮겨야 하는가? 2-2. Effect가 여러 관련 없는 일을 하고 있는가? 2-3. 다음 state를 계산하기 위해 어떤 state를 읽고 있는가? 2-4. 값의 변경에 ‘반응’하지 않고 값을 읽고 싶은가? 2-5. 일부 반응형 값이 의도치 않게 변경되는가?

React 공식문서 이해하기 (29)

Sat, 09 Dec 2023 14:53:25 GMT

Chapter 4. Escape Hatches

#7 Effect 의존성 제거하기

학습 목차

1. 의존성은 코드와 일치해야 한다. 2. 불필요한 의존성 제거하기

1. 의존성은 코드와 일치해야 한다.

Effect를 작성할 때는 먼저 Effect가 수행하기를 원하는 작업을 시작하고 중지하는 방법을 지정한다.
그런 다음 Effect 의존성을 비워두면([]) 린터가 올바른 의존성을 제안한다.
Effect는 반응형 값에 “반응”한다.

1-1. 의존성을 제거하려면 의존성이 아님을 증명하라.

Effect의 의존성을 “선택”할 수 없다는 점에 유의하라. Effect의 코드에서 사용되는 모든 반응형 값은 의존성 목록에 선언되어야 합니다. 의존성 목록은 주변 코드에 의해 결정된다.
반응형 값에는 props와 컴포넌트 내부에서 직접 선언된 모든 변수 및 함수가 포함된다.

1-2. 의존성을 변경하려면 코드를 변경하라.

먼저 Effect의 코드 또는 반응형 값 선언 방식을 변경한다.
그런 다음, 변경한 코드에 맞게 의존성을 조정한다.
의존성 목록이 마음에 들지 않으면 첫 번째 단계로 돌아가서 코드를 다시 변경한다. (그리고 코드를 다시 변경하자.)

의존성을 변경하려면 먼저 주변 코드를 변경하라. 의존성 목록은 Effect의 코드에서 사용하는 모든 반응형 값의 목록이라고 생각하면 된다. 이 목록에 무엇을 넣을지는 사용자가 선택하지 않는다. 이 목록은 코드를 설명한다. 의존성 목록을 변경하려면 코드를 변경하자.
이것은 방정식을 푸는 것처럼 느껴질 수 있다. 예를 들어, 의존성 제거와 같은 목표를 설정하고 그 목표에 맞는 코드를 “찾아야” 한다. 모든 사람이 방정식을 푸는 것을 재미있어하는 것은 아니며, Effect를 작성할 때도 마찬가지이다.

! 주의 !

기존 코드베이스가 있는 경우 이와 같이 린터를 억제하는 Effect가 있을 수 있다.

useEffect(() => {
  // ...
  // 🔴 Avoid suppressing the linter like this:
  // eslint-ignore-next-line react-hooks/exhaustive-deps
}, []);

의존성이 코드와 일치하지 않으면 버그가 발생할 위험이 매우 높다. 린터를 억제하면 Effect가 의존하는 값에 대해 React에 “거짓말”을 하게 된다.

2. 불필요한 의존성 제거하기

코드를 반영하기 위해 Effect의 의존성을 조정할 때마다 의존성 목록을 살펴보라. 이러한 의존성 중 하나라도 변경되면 Effect가 다시 실행되는 것이 합리적일까? 가끔 대답은 “아니오”이다. 다른 조건에서 Effect의 다른 부분을 다시 실행하고 싶을 수도 있다. 일부 의존성의 변경에 “반응”하지 않고 “최신 값”만 읽고 싶을 수도 있다. 의존성은 객체나 함수이기 때문에 의도치 않게 너무 자주 변경될 수 있다.

위의 2-* 내용들은 아직 안정된 버전의 React로 출시되지 않은 실험적인 API에 대해 설명하는 내용을 포함하고 있어 참고만 하였음.

요약

의존성은 항상 코드와 일치해야한다.
의존성이 마음에 들지 않으면 코드를 수정해야한다.
린터를 억제하면 매우 혼란스러운 버그가 발생하므로 항상 피해야한다.
의존성을 제거하려면 해당 의존성이 필요하지 않다는 것을 린터에게 “증명”해야한다.
특정 상호작용에 대한 응답으로 일부 코드가 실행되어야 하는 경우 해당 코드를 이벤트 핸들러로 이동하자.
Effect의 다른 부분이 다른 이유로 다시 실행되어야 하는 경우 여러 개의 Effect로 분할하라.
이전 state를 기반으로 일부 state를 업데이트하려면 업데이터 함수를 전달하라.
“반응”하지 않고 최신 값을 읽으려면 Effect에서 Effect Event를 추출하자.
JavaScript에서 객체와 함수는 서로 다른 시간에 생성된 경우 서로 다른 것으로 간주된다.
객체와 함수의 의존성을 피하라. 컴포넌트 외부나 Effect 내부로 이동하자.

React 공식 문서

React 비공식 번역 문서

MDN

Wikipedia

3-1. Effect Event 선언하기 3-2. Effect Event로 최신 props 및 state 읽기 3-3. Effect Event의 제한사항

React 공식문서 이해하기 (28)

Fri, 08 Dec 2023 13:56:20 GMT

Chapter 4. Escape Hatches

#6 이벤트와 Effect 분리하기

학습 목차

1. 이벤트 핸들러와 Effect 중 선택하기 2. 반응형 값 및 반응형 로직 3. Effect에서 비반응형 로직 추출하기

1. 이벤트 핸들러와 Effect 중 선택하기

채팅방 컴포넌트를 구현한다고 상상해보자.
1. 컴포넌트는 선택한 채팅방에 자동으로 연결되어야 합니다.
2. “전송” 버튼을 클릭하면, 채팅에 메시지를 전송해야 합니다.
이미 코드를 구현했지만, 이 코드를 어디에 놓아야 할지 확실하지 않다. 이벤트 핸들러와 Effects 중 어떤 것을 사용해야 할까?
이 질문에 대답할 때마다, 코드가 실행되어야하는 이유를 생각해야한다.*

1-1. 이벤트 핸들러는 특정 상호 작용에 대한 응답으로 실행된다.

사용자 관점에서 메시지를 보내는 것은 특정 “전송” 버튼을 클릭했기 때문에 발생되어야한다. 메시지가 다른 시간이나 다른 이유로 보내지면 사용자들은 화가 날 것이다. 이것이 메시지를 보내는 것이 이벤트 핸들러여야하는 이유이다. 이벤트 핸들러를 사용하면 특정 상호 작용에 대한 처리를 할 수 있다.
```
function ChatRoom({ roomId }) {
const [message, setMessage] = useState('');
// ...
function handleSendClick() {
  sendMessage(message);
}
// ...
return (
  <>
     setMessage(e.target.value)} />
    ;
  
);
}
```
이벤트 핸들러를 사용하면 사용자가 버튼을 누를 때만 sendMessage(message) 가 실행된다는 것을 확신할 수 있다.

1-2. Effect는 동기화가 필요할 때마다 실행된다.

코드를 실행해야 하는 이유 는 특정 상호 작용이 아니다. 사용자가 채팅방 화면으로 이동한 이유나 방법은 중요하지 않다. 사용자들이 채팅방 화면을 보고 상호작용 할 수 있어야하기 때문에, 컴포넌트는 선택한 채팅 서버에 계속 연결되어 있어야 한다. 앱의 초기 화면이 채팅방 컴포넌트이고, 사용자가 어떤 상호작용도 수행하지 않았더라도 여전히 채팅 서버에 연결되어야한다. 이것이 바로 Effect인 이유이다.
```
function ChatRoom({ roomId }) {
// ...
useEffect(() => {
 const connection = createConnection(serverUrl, roomId);
 connection.connect();
 return () => {
   connection.disconnect();
 };
}, [roomId]);
// ...
}
```
이 코드를 사용하면, 사용자가 수행한 특정 상호작용과는 무관하게, 항상 현재 선택된 채팅 서버에 대한 활성화된 연결이 있음을 확신할 수 있다.
사용자가 앱을 열었을 때 뿐만 아니라, 다른 채팅방을 선택하거나 다른 화면으로 이동했다가 다시 돌아와도 Effect가 현재 선택된 방과 동기화되어 컴포넌트에 항상 현재 선택된 채팅서버가 연결된 상태가 유지된다. 또한, 필요할 때마다 다시 연결된다.

2. 반응형 값 및 반응형 로직

직관적으로, 이벤트 핸들러는 버튼을 클릭하는 등 항상 “수동”으로 트리거시킨다고 말할 수 있다. 반면에 Effect는 “자동”으로 동기화 상태를 유지하는 데 필요한 만큼 자주 다시 실행된다.
컴포넌트 본문 내부에 선언된 props, state, 변수를 반응형 값이라고 합니다. 아래 예제에서 serverUrl은 반응형 값이 아니지만 roomId와 message는 반응형 값이다.
```
const serverUrl = 'https://localhost:1234';
```

function ChatRoom({ roomId }) { const [message, setMessage] = useState('');

// ... }

- 이와 같은 반응형 값은 리렌더링으로 인해 변경될 수 있습니다. 예를 들어, 사용자가 message를 수정하거나 드롭다운에서 다른 roomId를 선택할 수 있습니다. 이벤트 핸들러와 Effect는 변경 사항에 다르게 반응한다.
  - **이벤트 핸들러 내부의 로직은 반응형이 아니다.**
  사용자가 동일한 상호작용(예: 클릭)을 다시 수행하지 않는 한 다시 실행되지 않는다.
  이벤트 핸들러는 변경에 “반응”하지 않고 반응형 값을 읽을 수 있다.
  - **Effects 내부의 로직은 반응형이다.**
  Effect에서 반응형 값을 읽는 경우 의존성으로 지정해야 한다.
  그런 다음 리렌더링으로 인해 해당 값이 변경되면 React는 새 값으로 Effect의 로직을 다시 실행한다.

**2-1. 이벤트 핸들러 내부의 로직은 반응형이 아니다.**

// ... sendMessage(message); // ...

- 사용자의 관점에서 볼 때 message가 변경되었다고 해서 메시지를 보내겠다는 뜻은 아니다.
사용자가 입력 중이라는 의미일 뿐이다.
즉, 메시지를 전송하는 로직은 반응적이어서는 안 된다.
반응형 값이 변경되었다는 이유만으로 다시 실행되어서는 안 된다.
이것이 바로 이벤트 핸들러에 속하는 이유이다.

function handleSendClick() { sendMessage(message); }

- 이벤트 핸들러는 반응형이 아니므로 사용자가 보내기 버튼을 클릭할 때만 ```sendMessage(message)```가 실행된다.

**2-2. Effect 내부의 로직은 반응형이다.**

// ... const connection = createConnection(serverUrl, roomId); connection.connect(); // ...

- 사용자 입장에서 보면, ```roomId```가 변경되었다는 것은 다른 룸에 연결하고 싶다는 의미이다.
즉, 방에 연결하기 위한 로직은 반응형이어야한다.
이러한 코드 라인은 반응형 값을 “따라잡고”, 값이 달라지면 다시 실행되기를 원한다.
이것이 바로 Effect에 속하는 이유이다.

useEffect(() => { const connection = createConnection(serverUrl, roomId); connection.connect(); return () => { connection.disconnect() }; }, [roomId]);

- Effect는 반응형이므로 ```createConnection(serverUrl, roomId)``` 및 ```connection.connect()``` 코드는 ```roomId```의 모든 고유값에 대해 실행된다.
Effect는 현재 선택된 방에 따라 채팅 연결을 동기화한다.


### 3. Effect에서 비반응형 로직 추출하기

- 반응형 로직과 비반응형 로직을 함께 사용하려는 경우 상황이 더 까다로워진다.
- 예를 들어, 사용자가 채팅에 연결할 때 알림을 표시하고 싶다고 가정해 보자.
props에서 현재 테마(dark or light)를 읽어 올바른 색상으로 알림을 표시한다.

function ChatRoom({ roomId, theme }) { useEffect(() => { const connection = createConnection(serverUrl, roomId); connection.on('connected', () => { showNotification('Connected!', theme); }); connection.connect(); // ...

- 그러나, theme는 반응형 값이며(리렌더링의 결과로 변경될 수 있음), Effect에서 읽는 모든 반응형 값은 의존성으로 선언해야한다.
이제 theme를 Effect의 의존성으로 지정해야한다.

```

위의 3-* 내용들은 아직 안정된 버전의 React로 출시되지 않은 실험적인 API에 대해 설명하고 있어 참고만 하였음.

요약

이벤트 핸들러는 특정 상호 작용에 대한 응답으로 실행된다.
Effect는 동기화가 필요할 때마다 실행된다.
이벤트 핸들러 내부의 로직은 반응형이 아니다.
Effect 내부의 로직은 반응적이다.
비반응적 로직을 Effect에서 Effect Event로 이동할 수 있다.
Effect 내부에서만 Effect Event를 호출하라.
Effect Event를 다른 컴포넌트나 Hook에 전달하지 말자.

React 공식 문서

React 비공식 번역 문서

MDN

Wikipedia

React 공식문서 이해하기 (27)

Thu, 07 Dec 2023 14:40:35 GMT

Chapter 4. Escape Hatches

#5 반응형 Effect의 생명주기

학습 목차

1. Effect의 생명주기 2. Effect는 ‘반응형 값’에 반응한다.

1. Effect의 생명주기

모든 React 컴포넌트는 동일한 생명주기를 거친다.
- 컴포넌트는 화면에 추가될 때 마운트된다.
- 컴포넌트는 새로운 props나 state를 받으면 업데이트됩니다. 이는 보통 상호작용에 대한 응답으로 발생한다.
- 화면에서 제거되면 컴포넌트가 마운트 해제된다.
컴포넌트에 대해 생각하는 좋은 방법이지만 Effect에 대해서는 생각하지 않는 것이 좋다.
대신 각 Effect를 컴포넌트의 생명주기와 독립적으로 생각해보자. Effect는 외부 시스템을 현재 props 및 state에 동기화하는 방법을 설명한다. 코드가 변경되면 이 동기화를 더 자주 또는 덜 자주 수행해야한다.
직관적으로 React는 컴포넌트가 마운트될 때 동기화를 시작하고 컴포넌트가 마운트 해제될 때 동기화를 중지할 것이라고 생각할 수 있다. 때로는 컴포넌트가 마운트된 상태에서 동기화를 여러 번 시작하고 중지해야 할 수도 있다.

KeyNote

일부 Effect는 클린업 함수를 전혀 반환하지 않는다.
대부분의 경우 함수를 반환하고 싶겠지만, 그렇지 않은 경우 React는 아무 작업도 하지 않는 빈 클린업 함수를 반환한 것처럼 동작한다.

1-1. 동기화가 두 번 이상 수행되어야 하는 이유

Effect의 본문은 동기화를 시작하는 방법을 지정하고, 클린업 함수는 동기화를 중지하는 방법을 지정합니다.
~~예시 코드 참조~~

1-2. React가 Effect를 재동기화 하는 방법

다른 컴포넌트에 다시 연결하려면 React가 Effect를 다시 동기화해야한다.
~~예시 코드 참조~~

1-3. Effect의 관점에서 생각하기

항상 한 번에 하나의 시작/중지 사이클에만 집중하자. 컴포넌트를 마운트, 업데이트 또는 마운트 해제하는 것은 중요하지 않다. 동기화를 시작하는 방법과 중지하는 방법만 설명하면 된다. 이 작업을 잘 수행하면 필요한 횟수만큼 Effect를 시작하고 중지할 수 있는 탄력성을 확보할 수 있다.
JSX를 생성하는 렌더링 로직을 작성할 때 컴포넌트가 마운트되는지 업데이트되는지 생각하지 않는 것을 떠올리면 이해가 쉬울 것이다. 화면에 무엇이 표시되어야 하는지 설명하면 나머지는 React가 알아서 처리한다.
~~예시 코드 참조~~

1-4. React가 Effect의 재동기화 가능 여부를 확인하는 방법

개발 모드에서 React는 즉시 강제로 동기화를 수행하여 Effect가 다시 동기화될 수 있는지 확인한다. 도어락이 작동하는지 확인하기 위해 문을 열었다가 한 번 더 닫는 것과 비슷하다. React는 개발 중에 Effect를 한 번 더 시작하고 중지하여 클린업 함수를 잘 구현했는지 확인한다.
~~예시 코드 참조~~

1-5. React가 Effect의 재동기화 필요성을 인식하는 방법

컴포넌트가 다시 렌더링될 때마다 React는 사용자가 전달한 의존성 배열을 살펴보자. 배열의 값 중 하나라도 이전 렌더링 중에 전달한 동일한 지점의 값과 다르면 React는 Effect를 다시 동기화한다.
~~예시 코드 참조~~

1-6. 각각의 Effect는 별도의 동기화 프로세스를 나타낸다.

일관된 로직을 별도의 Effect로 분리하면 코드가 “더 깔끔해” 보일 수 있지만 유지 관리가 더 어려워진다. 따라서 코드가 더 깔끔해 보이는지 여부가 아니라 프로세스가 동일한지 또는 분리되어 있는지를 고려해야 한다.
~~예시 코드 참조~~

2. Effect는 ‘반응형 값’에 반응한다.

컴포넌트 내부에서 선언된 props, state 및 기타 값은 렌더링 중에 계산되고 React 데이터 흐름에 참여하기 때문에 반응형이다.
~~예시 코드 참조~~

2-1. 빈 의존성을 가지고 있는 Effect의 의미

Effect의 관점에서 생각하면 마운트 및 마운트 해제에 대해 전혀 생각할 필요가 없다. 중요한 것은 Effect가 동기화를 시작하고 중지하는 작업을 지정한 것이다.
~~예시 코드 참조~~

2-2. 컴포넌트 본문에서 선언된 모든 변수는 반응형이다.

props와 state만 반응형 값인 것은 아니다. 이들로부터 계산하는 값들 역시 반응형이다.
props나 state가 변경되면 컴포넌트가 다시 렌더링되고 그로부터 계산된 값도 변경된다. 그렇기 때문에 Effect가 사용하는 컴포넌트 본문의 모든 변수는 Effect 의존성 목록에 있어야 한다.
~~예시 코드 참조~~

2-3. React는 모든 반응형 값을 의존성으로 지정했는지 검토한다.

린터가 React에 맞게 구성된 경우, Effect 코드에서 사용되는 모든 반응형 값이 해당 의존성으로 선언되었는지 확인한다.
~~예시 코드 참조~~

KeyNote

어떤 경우에는 컴포넌트 내부에서 값이 선언되더라도 절대 변하지 않는다는 것을 React가 알고 있다. 예를 들어, useState에서 반환된 설정자 함수와 useRef에서 반환된 ref 객체는 리렌더링 시 변경되지 않도록 보장되는 안정적인 값이다.
안정적인 값은 반응하지 않으므로 린터를 사용하면 목록에서 생략할 수 있다. 그러나 이러한 값을 포함하는 것은 허용된다. 변경되지 않으므로 상관없다.

2-4. 재동기화를 원치 않는 경우엔 어떻게 해야 하는가?

Effect는 반응형 코드 블록이다. 내부에서 읽은 값이 변경되면 다시 동기화된다. 상호작용당 한 번만 실행되는 이벤트 핸들러와 달리 Effect는 동기화가 필요할 때마다 실행된다.
의존성을 “선택”할 수는 없다. 의존성에는 Effect에서 읽은 모든 반응형 값이 포함되어야 한다.린터가 이를 강제한다. 때때로 이로 인해 무한 루프와 같은 문제가 발생하거나 Effect가 너무 자주 다시 동기화될 수 있다. 린터를 억제하여 이러한 문제를 해결하지 말자. 대신 시도할 수 있는 방법은 다음과 같다.
- Effect가 독립적인 동기화 프로세스를 나타내는지 확인하라. Effect가 아무것도 동기화하지 않는다면 불필요한 것일 수 있다. 여러 개의 독립적인 것을 동기화하는 경우 분할하라.
- ‘반응’하지 않고 Effect를 재동기화하지 않으면서 props나 state의 최신 값을 읽으려면, Effect를 반응하는 부분(Effect에 유지)과 반응하지 않는 부분(Effect Event라는 것으로 추출)으로 분리할 수 있다.
- 객체와 함수를 의존성으로 사용하지 말자. 렌더링 중에 오브젝트와 함수를 생성한 다음 Effect에서 읽으면 렌더링할 때마다 오브젝트와 함수가 달라진다. 그러면 매번 Effect를 다시 동기화해야 한다.
~~예시 코드 참조~~

! 주의 !

린터는 의존성이 잘못되었을 때만 알 수 있다. 각 사례를 해결하는 최선의 방법은 알지 못한다.
만약 린터가 의존성을 제안하지만 이를 추가하면 루프가 발생한다고 해서 린터를 무시해야 한다는 의미는 아니다. 해당 값이 반응적이지 않고 의존성이 될 필요가 없도록 Effect 내부(또는 외부)의 코드를 변경해야 한다는 뜻이다.

요약

컴포넌트는 마운트, 업데이트, 마운트 해제할 수 있다.
각 Effect는 주변 컴포넌트와 별도의 생명주기를 가진다.
각 Effect는 시작 및 중지 할 수 있는 별도의 동기화 프로세스를 설명한다.
Effect를 작성하고 읽을 때는 컴포넌트의 관점(마운트, 업데이트 또는 마운트 해제 방법)이 아니라 각 개별 Effect의 관점(동기화 시작 및 중지 방법)에서 생각해야한다.
컴포넌트 본문 내부에 선언된 값은 “반응형”이다.
반응형 값은 시간이 지남에 따라 변경될 수 있으므로 Effect를 다시 동기화해야한다.
린터는 Effect 내부에서 사용된 모든 반응형 값이 의존성으로 지정되었는지 확인한다.
린터에 의해 플래그가 지정된 모든 오류는 합법적인 오류입니다. 규칙을 위반하지 않도록 코드를 수정할 수 있는 방법은 항상 있다.

React 공식 문서

React 비공식 번역 문서

MDN

Wikipedia

React 공식문서 이해하기 (26)

Wed, 06 Dec 2023 14:46:41 GMT

Chapter 4. Escape Hatches

#4 Effect가 필요하지 않을 수도 있다.

학습 목차

1. 불필요한 Effect를 제거하는 방법

1. 불필요한 Effect를 제거하는 방법

Effect가 필요하지 않은 흔한 경우는 두 가지가 있다.
1. 렌더링을 위해 데이터를 변환하는 경우 Effect는 필요하지 않다. 예를 들어, 목록을 표시하기 전에 필터링하고 싶다고 가정해 보자. 목록이 변경될 때 state 변수를 업데이트하는 Effect를 작성하고 싶을 수 있다. 하지만 이는 비효율적이다. 컴포넌트의 state를 업데이트할 때 React는 먼저 컴포넌트 함수를 호출해 화면에 표시될 내용을 계산한다. 다음으로 이러한 변경 사항을 DOM에 “commit”하여 화면을 업데이트하고, 그 후에 Effect를 실행한다. 만약 Effect “역시” state를 즉시 업데이트한다면, 이로 인해 전체 프로세스가 처음부터 다시 시작될 것이다. 불필요한 렌더링을 피하려면 모든 데이터 변환을 컴포넌트의 최상위 레벨에서 하라. 그러면 props나 state가 변경될 때마다 해당 코드가 자동으로 다시 실행될 것아다.
2. 사용자 이벤트를 처리하는 데에 Effect는 필요하지 않다. 예를 들어, 사용자가 제품을 구매할 때 /api/buy POST 요청을 전송하고 알림을 표시하고 싶다고 하자. 구매 버튼 클릭 이벤트 핸들러에서는 정확히 어떤 일이 일어났는지 알 수 있다. 반면 Effect는 사용자가 무엇을 했는지(예: 어떤 버튼을 클릭했는지)를 알 수 없다. 그렇기 때문에 일반적으로 사용자 이벤트를 해당 이벤트 핸들러에서 처리한다.
한편 외부 시스템과 동기화하려면 Effect가 필요하다. 예를 들어, jQuery 위젯을 React state와 동기화하는 Effect를 작성할 수 있다. 또한 검색 결과를 현재의 검색 쿼리와 동기화하기 위해 데이터 요청을 Effect로 처리할 수 있다. 최신 프레임워크는 컴포넌트에 직접 Effects를 작성하는 것보다 더 효율적인 빌트인 데이터 페칭 메커니즘을 제공한다는 점을 명심하라.

1-1. props 또는 state에 따라 state 업데이트하기

기존 props나 state에서 계산할 수 있는 것이 있으면 state에 넣지 말자. 대신 렌더링 중에 계산하라. 이렇게 하면 코드가 더 빨라지고, (추가적인 “계단식” 업데이트를 피함) 더 간단해지고, (일부 코드 제거) 오류가 덜 발생한다. (서로 다른 state 변수가 서로 동기화되지 않아 발생하는 버그를 피함) 이 접근 방식이 생소하게 느껴진다면, React로 사고하기에서 state에 들어가야할 내용이 무엇인지 확인하자.

1-2. 복잡한 계산 캐싱하기

아래 컴포넌트는 props로 받은 todos를 filter prop에 따라 필터링하여 visibleTodos를 계산한다. 이 결과를 state 변수에 저장하고 Effect에서 업데이트하고 싶을 수도 있을 것이다.

function TodoList({ todos, filter }) {
const [newTodo, setNewTodo] = useState('');
// 🔴 중복 state 및 불필요한 Effect 사용을 자제하자.
const [visibleTodos, setVisibleTodos] = useState([]);
useEffect(() => {
  setVisibleTodos(getFilteredTodos(todos, filter));
}, [todos, filter]);

// ...
}

앞의 예시에서와 마찬가지로 이것은 불필요하고 비효율적이다. state와 Effect를 제거하자.

function TodoList({ todos, filter }) {
const [newTodo, setNewTodo] = useState('');
// ✅ getFilteredTodos()가 느리지 않다면 괜찮다.
const visibleTodos = getFilteredTodos(todos, filter);
// ...
}

getFilteredTodos()가 느리거나 todos가 많을 경우, newTodo와 같이 관련 없는 state 변수가 변경되더라도 getFilteredTodos()를 다시 계산하고 싶지 않을 수 있다.
이럴 땐 복잡한 계산을 useMemo 훅으로 감싸서 캐시(또는 “메모화 (memoize)”)할 수 있다.
```
import { useMemo, useState } from 'react';
```

또는 아래와 같이 한 줄로 작성할 수도 있다.

import { useMemo, useState } from 'react';

function TodoList({ todos, filter }) { const [newTodo, setNewTodo] = useState(''); // ✅ todos나 filter가 변하지 않는 한 getFilteredTodos()가 재실행되지 않음 const visibleTodos = useMemo(() => getFilteredTodos(todos, filter), [todos, filter]); // ... }

- 이렇게 하면 ```todos```나 ```filter```가 변경되지 않는 한 내부 함수가 다시 실행되지 않기를 원한다는 것을 React에 알린다.
그러면 React는 초기 렌더링 중에 ```getFilteredTodos()```의 반환값을 기억한다.
그 다음부터는 렌더링 중에 할 일이나 필터가 다른지 확인한다.
지난번과 동일하다면 ```useMemo```는 마지막으로 저장한 결과를 반환한다.
같지 않다면, React는 내부 함수를 다시 호출하고 그 결과를 저장한다.
```useMemo```로 감싸는 함수는 렌더링 중에 실행되므로, 순수 계산에만 작동한다.

**1-3. prop이 변경되면 모든 state 재설정하기**

- 다음 ```ProfilePage``` 컴포넌트는 ```userId``` prop을 받는다.
이 페이지에는 코멘트 input이 포함되어 있으며, ```comment``` state 변수를 사용하여 그 값을 보관한다.
어느 날, 한 프로필에서 다른 프로필로 이동할 때 comment state가 재설정되지 않는 문제를 발견했다.
그 결과 의도치 않게 잘못된 사용자의 프로필에 댓글을 게시하기가 쉬운 상황이다.
이 문제를 해결하려면 ```userId```가 변경될 때마다 ```comment``` state 변수를 지워줘야 한다.

export default function ProfilePage({ userId }) { const [comment, setComment] = useState(''); // 🔴 prop 변경시 Effect에서 state 재설정 수행하므로 자제 useEffect(() => { setComment(''); }, [userId]); // ... }

- 이것은 ```ProfilePage```와 그 자식들이 먼저 오래된 값으로 렌더링한 다음 새로운 값으로 다시 렌더링하기 때문에 비효율적이다.
또한 ```ProfilePage``` 내부에 어떤 state가 있는 모든 컴포넌트에서 이 작업을 수행해야 하므로 복잡하다.
예를 들어, 댓글 UI가 중첩되어 있는 경우 중첩된 하위 댓글 state들도 모두 지워야 할 것이다.
- 그 대신 명시적인 키를 전달해 각 사용자의 프로필이 개념적으로 다른 프로필이라는 것을 React에 알릴 수 있다.
컴포넌트를 둘로 나누고 바깥쪽 컴포넌트에서 안쪽 컴포넌트로 ```key``` 속성을 전달하라.

export default function ProfilePage({ userId }) { return ( ); }

function Profile({ userId }) { // ✅ key가 변하면 이 컴포넌트 및 모든 자식 컴포넌트의 state가 자동으로 재설정됨 const [comment, setComment] = useState(''); // ... }

- 일반적으로 React는 같은 컴포넌트가 같은 위치에서 렌더링될 때 state를 유지한다.
**```userId```를 ```key```로 ```Profile``` 컴포넌트에 전달하는 것은 곧, ```userId```가 다른 두 ```Profile``` 컴포넌트를 state를 공유하지 않는 별개의 컴포넌트들로 취급하도록 React에게 요청하는 것이다.**
React는 (```userId```로 설정한) ```key```가 변경될 때마다 DOM을 다시 생성하고 state를 재설정하며, ```Profile``` 컴포넌트 및 모든 자식들의 state를 재설정할 것이다.
그 결과 ```comment``` 필드는 프로필들을 탐색할 때마다 자동으로 지워진다.
- 위 예제에서는 외부의 ```ProfilePage``` 컴포넌트만 export하였으므로 프로젝트의 다른 파일에서는 오직 ```ProfilePage``` 컴포넌트에만 접근 가능하다.
```ProfilePage```를 렌더링하는 컴포넌트는 ```key```를 전달할 필요 없이 일반적인 ```prop```으로 ```userId```만 전달하고 있다.
```ProfilePage```가 내부의 ```Profile``` 컴포넌트에 ```key```로 전달한다는 사실은 내부에서만 알고 있는 구현 세부 사항이다.

**1-4. props가 변경될 때 일부 state 조정하기**

- 때론 ```prop```이 변경될 때 state의 전체가 아닌 일부만 재설정하거나 조정하고 싶을 수 있다.
- 다음의 ```List``` 컴포넌트는 ```items``` 목록을 ```prop```으로 받고, ```selection``` state 변수에 선택된 항목을 유지한다.
```items prop```이 다른 배열을 받을 때마다 ```selection```을 ```null```로 재설정하고 싶다.

- 이것 역시 이상적이지 않다. ```items```가 변경될 때마다 ```List```와 그 하위 컴포넌트는 처음에는 오래된 ```selection```값으로 렌더링된다.
그런 다음 React는 DOM을 업데이트하고 Effects를 실행한다.
마지막으로 ```setSelection(null)```호출은 ```List```와 그 자식 컴포넌트를 다시 렌더링하여 이 전체 과정을 재시작하게 된다.
- Effect를 삭제하는 것으로 시작하라. 대신 렌더링 중에 직접 state를 조정한다.

- 이렇게 이전 렌더링의 정보를 저장하는 것은 이해하기 어려울 수 있지만, Effect에서 동일한 state를 업데이트하는 것보다는 낫다.
위 예시에서는 렌더링 도중 ```setSelection```이 직접 호출된다.
React는 ```return```문과 함께 종료된 직후에 List를 다시 렌더링한다.
이 시점에서 React는 아직 ```List```의 자식들을 렌더링하거나 DOM을 업데이트하지 않았기 때문에, ```List```의 자식들은 기존의 ```selection``` 값에 대한 렌더링을 건너뛰게 된다.
- 렌더링 도중 컴포넌트를 업데이트하면, React는 반환된 JSX를 버리고 즉시 렌더링을 다시 시도한다.
React는 계단식으로 전파되는 매우 느린 재시도를 피하기 위해, 렌더링 중에 동일한 컴포넌트의 state만 업데이트할 수 있도록 허용한다.
렌더링 도중 다른 컴포넌트의 state를 업데이트하면 오류가 발생한다.
동일 컴포넌트가 무한으로 리렌더링을 반복 시도하는 상황을 피하기 위해 ```items !== prevItems```와 같은 조건이 필요한 것이다.
이런 식으로 state를 조정할 수 있긴 하지만, 다른 side effect(DOM 변경이나 timeout 설정 등)은 이벤트 핸들러나 Effect에서만 처리함으로써 컴포넌트의 순수성을 유지해야 한다.
- 이 패턴은 Effect보다 효율적이지만, 대부분의 컴포넌트에는 필요하지 않다.
어떻게 하든 ```props```나 다른 state들을 바탕으로 state를 조정하면 데이터 흐름을 이해하고 디버깅하기 어려워질 것이다.
항상 ```key```로 모든 state를 재설정하거나 렌더링 중에 모두 계산할 수 있는지를 확인하라.
예를 들어, 선택한 item을 저장(및 재설정)하는 대신, 선택한 item의 ID를 저장할 수 있다.

function List({ items }) { const [isReverse, setIsReverse] = useState(false); const [selectedId, setSelectedId] = useState(null); // ✅ 가장 좋음: 렌더링 중에 모든 값을 계산 const selection = items.find(item => item.id === selectedId) ?? null; // ... }

```

이제 state를 “조정”할 필요가 전혀 없다. 선택한 ID를 가진 항목이 목록에 있으면 선택된 state로 유지된다. 그렇지 않은 경우 렌더링 중에 계산된 selection 항목은 일치하는 항목을 찾지 못하므로 null이 된다. 이 방식은 items에 대한 대부분의 변경과 무관하게 ‘selection’ 항목은 그대로 유지되므로 대체로 더 나은 방법이다.

1-5. 이벤트 핸들러 간 로직 공유

어떤 코드가 Effect에 있어야 하는지 이벤트 핸들러에 있어야 하는지 확실치 않은 경우, 이 코드가 실행되어야 하는 이유를 자문해 보자.
컴포넌트가 사용자에게 표시되었기 때문에 실행되어야 하는 코드에만 Effect를 사용하라.

1-6. POST요청 보내기

어떤 로직을 이벤트 핸들러에 넣을지 Effect에 넣을지 선택할 때, 사용자 관점에서 어떤 종류의 로직인지에 대한 답을 찾아야 한다. 이 로직이 특정 상호작용으로 인해 발생하는 것이라면 이벤트 핸들러에 넣어라. 사용자가 화면에서 컴포넌트를 보는 것이 원인이라면 Effect에 넣자.

1-7. 연쇄 계산

이벤트 핸들러에서 직접 다음 state를 계산할 수 없는 경우도 있다. 예를 들어, 이전 드롭다운의 선택 값에 따라 다음 드롭다운의 옵션이 달라지는 form을 상상해 보자. 이를 네트워크와 동기화해야 한다면 Effect 체인이 적절할 것이다.

1-8. 애플리케이션 초기화하기

일부 로직은 앱이 로드될 때 한 번만 실행되어야한다.
상용 환경에서는 실제로 다시 마운트되지 않을 수 있지만, 모든 컴포넌트에서 동일한 제약 조건을 따르면 코드를 이동하고 재사용하기가 더 쉬워진다. 일부 로직이 컴포넌트 마운트당 한 번이 아니라 앱 로드당 한 번 실행되어야 하는 경우, 최상위 변수를 추가하여 이미 실행되었는지 여부를 추적하라.
컴포넌트를 import할 때 최상위 레벨의 코드는 렌더링되지 않더라도 일단 한 번 실행된다. 임의의 컴포넌트를 임포트할 때 속도 저하나 예상치 못한 동작을 방지하려면 이 패턴을 과도하게 사용하지 말자.

1-9. state변경을 부모 컴포넌트에 알리기

부모 컴포넌트가 더 많은 로직을 포함해야 하지만, 전체적으로 걱정해야 할 state가 줄어든다는 것을 의미힌다.
두 개의 서로 다른 state 변수를 동기화하려고 할 때마다, 대신 state를 끌어올려 보자.

1-10. 부모에게 데이터 전달하기

React에서 데이터는 부모 컴포넌트에서 자식 컴포넌트로 흐른다. 화면에 뭔가 잘못된 것이 보이면, 컴포넌트 체인을 따라 올라가서 어떤 컴포넌트가 잘못된 prop을 전달하거나 잘못된 state를 가지고 있는지 찾아냄으로써 정보의 출처를 추적할 수 있다. 자식 컴포넌트가 Effect에서 부모 컴포넌트의 state를 업데이트하면, 데이터 흐름을 추적하기가 매우 어려워진다. 자식과 부모 컴포넌트 모두 동일한 데이터가 필요하므로, 대신 부모 컴포넌트가 해당 데이터를 페치해서 자식에게 전달하도록 하라.

1-11. 외부 스토어 구독하기

때로는 컴포넌트가 React state 외부의 일부 데이터를 구독해야 할 수도 있다. 서드파티 라이브러리나 브라우저 빌트인 API에서 데이터를 가져와야 할 수도 있다. 이 데이터는 React가 모르는 사이에 변경될 수도 있는데, 그럴 땐 수동으로 컴포넌트가 해당 데이터를 구독하도록 해야 한다. 이 작업은 종종 Effect에서 수행한다.
React 컴포넌트에서 외부 store를 구독하는 방법에 대해 자세히 읽어보자.

1-12. 데이터 페칭하기

많은 앱이 데이터 페칭을 시작하기 위해 Effect를 사용한다.
데이터 페칭을 구현할 때 경합 조건을 처리하는 것만 어려운 것은 아니다. 응답을 캐시하는 방법, (사용자가 Back을 클릭하고면 스피너 대신 이전 화면을 즉시 볼 수 있도록) 서버에서 페치하는 방법, (초기 서버 렌더링 HTML에 스피너 대신 가져온 콘텐츠가 포함되도록) 네트워크 워터폴을 피하는 방법 (데이터를 페치해야 하는 하위 컴포넌트가 시작하기 전에 위의 모든 부모가 데이터 페치를 완료할 때까지 기다릴 필요가 없도록) 등도 고려해볼 사항이다.
이런 문제는 React뿐만 아니라 모든 UI 라이브러리에 적용된다. 이러한 문제를 해결하는 것은 간단하지 않기 때문에 최신 프레임워크들은 컴포넌트에서 직접 Effect를 작성하는 것보다 더 효율적인 빌트인 데이터 페칭 메커니즘을 제공한다.
프레임워크를 사용하지 않고(또한 직접 만들고 싶지 않고) Effect에서 데이터 페칭을 보다 인체공학적으로 만들고 싶다면, 페칭 로직을 커스텀 훅으로 추출하는 것을 고려해 보자.
또한 오류 처리와 콘텐츠 로딩 여부를 추적하기 위한 로직을 추가하고 싶을 것이다. 이와 같은 훅을 직접 빌드하거나 React 에코시스템에서 이미 사용 가능한 많은 솔루션 중 하나를 사용할 수 있다. 이 방법만으로는 프레임워크 빌트인 데이터 페칭 메커니즘을 사용하는 것만큼 효율적이지는 않겠지만, 데이터 페칭 로직을 커스텀 훅으로 옮기면 나중에 효율적인 데이터 페칭 전략을 채택하기가 더 쉬워진다.

요약

렌더링 중에 무언가를 계산할 수 있다면 Effect가 필요하지 않다.
비용이 많이 드는 계산을 캐시하려면 useEffect 대신 useMemo를 추가하라.
전체 컴포넌트 트리의 state를 재설정하려면 다른 key를 전달하자.
prop 변경에 대한 응답으로 특정 state 일부를 조정하려면 렌더링 중에 설정하라.
컴포넌트가 표시되었기 때문에 실행해야 하는 코드는 Effect에 있어야 하고, 나머지는 이벤트에 있어야 한다.
여러 컴포넌트의 state를 업데이트해야 하는 경우 단일 이벤트에서 처리하는 것이 좋다.
여러 컴포넌트에서 state 변수를 동기화하려고 할 때마다 state 끌어올리기를 고려하라.
Effect로 데이터를 페치할 수 있지만, 경쟁 조건을 피하기 위해 클린업 로직을 구현해야 한다.

React 공식 문서

React 비공식 번역 문서

MDN

Wikipedia

React 공식문서 이해하기 (25)

Tue, 05 Dec 2023 00:47:08 GMT

Chapter 4. Escape Hatches

#3 Effect와 동기화하기

학습 목차

1. Effect란 무엇이며 이벤트와는 어떤게 다른가? 2. Effect가 필요하지 않을 수도 있다. 3. Effect 작성 방법 4. 개발 환경에서 두 번씩 실행되는 Effect를 처리하는 방법은 무엇인가? 5. 한 곳에 모으기

1. Effect란 무엇이며 이벤트와는 어떤게 다른가?

Effect에 도달하기 전에 React 컴포넌트 내부의 두가지 유형의 논리에 익숙해져야 한다.
- 렌더링 코드(UI 구성하기에서 소개됨)는 컴포넌트의 최상위 레벨에 있다. 여기서 props와 state를 가져와 변환하고 화면에 표시할 JSX를 반환한다. 렌더링 코드는 순수해야한다. 수학 공식처럼 결과만 계산할 뿐 다른 작업은 수행하지 않는다.
이벤트 핸들러(상호작용 추가하기에서 소개됨)는 컴포넌트 내부에 있는 중첩된 함수로, 계산만 하는 것이 아니라 별도의 작업도 수행한다. 이벤트 핸들러에서는 입력 필드를 업데이트하거나, HTTP POST요청을 제출하여 제품을 구매하거나, 사용자를 다른 화면으로 이동할 수 있다. 이벤트 핸들러에는 특정 사용자 작업(예:버튼 클릭 또는 입력)으로 인해 발생하는 “사이드 이펙트”(프로그램의 state를 변경함)가 포함되어 있다.
때로는 이것만으로는 충분하지 않을 수 있다. 화면에 표시될 때마다 채팅 서버에 연결해야 하는 ChatRoom 컴포넌트를 고려해 보자. 서버에 연결하는 것은 순수한 계산이 아니므로(사이드 이펙트) 렌더링 중에 발생할 수 없다. 그러나 ChatRoom 표시를 촉발하는 클릭과 같은 특정한 단일 이벤트는 없다.
Effect를 사용하면 특정 이벤트가 아닌 렌더링 자체로 인해 발생하는 사이드 이펙트를 명시할 수 있다. 채팅에서 메시지를 보내는 것은 사용자가 특정 버튼을 클릭함으로써 직접적으로 발생하기 때문에 이벤트이다. 그러나 서버 연결을 설정하는 것은 컴포넌트를 표시하게 만든 상호작용에 관계없이 발생해야 하기 때문에 하나의 Effect이다. Effect는 화면 업데이트 후 커밋이 끝날 때 실행된다. 이 때가 React 컴포넌트를 일부 외부 시스템(네트워크 또는 서드파티 라이브러리와 같은)과 동기화하기에 좋은 시기이다.

KeyNote

이 글에서 대문자로 시작하는 “Effect”는 위의 React에 한정된 정의, 즉, 렌더링으로 인해 발생하는 사이드 이펙트를 나타낸다. 이 후로 더 넓은 프로그래밍 개념을 언급할 때는 “사이드 이펙트”라고 하겠다.

2. Effect가 필요하지 않을 수도 있다.

Effect는 일반적으로 React 코드에서 벗어나 일부 외부 시스템과 동기화하는 데에 사용된다는 점을 인지하자. 여기에는 브라우저 API, 서드파티 위젯, 네트워크 등이 포함된다. Effect가 다른 state를 기반으로 일부 state만을 조정하는 경우, Effect가 필요하지 않을 수도 있다.

2-1. Effect 작성 방법

Effect를 작성하려면 다음 세 단계를 따라가자.
1. Effect를 선언한다. 기본적으로 Effect는 모든 렌더링 후에 실행된다.
2. Effect의 의존성을 명시한다. 대부분의 Effect는 렌더링 할 때마다가 아니라 필요할 때만 다시 실행해야 한다. 예를 들어, 페이드 인 애니메이션은 컴포넌트가 나타날 때만 발동되어야 한다. 대화방 연결 및 해제는 컴포넌트가 나타났다가 사라지거나 대화방이 변경될 때만 발생해야한다.
3. 필요한 경우 클린업을 추가한다. 일부 Effect는 수행중이던 작업을 중지, 취소 또는 정리하는 방법을 명시해야한다. 예를 들어, “connect”에는 “disconnect”가 필요하고 “subscribe”에는 “unsubscribe”가 필요하며 “fetch”에는 “cancel”또는 “ignore”가 필요하다.
! 주의 !
- 기본적으로 Effect는 매번 렌더링 후에 실행된다. 그렇기 때문에 다음과 같은 코드는 무한 루프를 생성한다.
```
const [count, setCount] = useState(0);
useEffect(() => {
setCount(count + 1);
});
```
- Effect는 렌더링의 결과로 실행된다. state를 설정하면 렌더링을 트리거한다. Effect에서 즉시 state를 설정하는 것은 전원 콘센트를 꽂는 것과 같다. Effect가 실행되고, state를 설정하면 다시 렌더링이 발생하고, 다시 렌더링이 발생하면 Effect가 실행되고, 다시 state를 설정하면 또 다시 렌더링이 발생하는 식이다.
- Effect는 보통 컴포넌트를 외부 시스템과 동기화해야 한다. 외부 시스템이 없고 다른 state를 기반으로 일부 state만 조정하려는 경우 Effect가 필요하지 않을 수도 있다.
- 의존성 배열이 없는 경우와 비어 있는 [] 의존성 배열이 있는 경우의 동작은 다르다.
```
useEffect(() => {
// This runs after every render
// 렌더시마다 실행됩니다.
});
```
```
useEffect(() => {
// This runs only on mount (when the component appears)
// 오직 마운트시(컴포넌트가 나타날 때)에만 실행됩니다.
}, []);
```
```
useEffect(() => {
// This runs on mount *and also* if either a or b have changed since the last render
// 마운트시 뿐만 아니라 a 또는 b가 직전 렌더와 달라졌을 때에도 실행됩니다.
}, [a, b]);
```

3. Effect 작성 방법

React는 개발 환경에서 버그를 찾기 위해 컴포넌트를 의도적으로 다시 마운트한다. “어떻게 하면 Effect를 한 번만 실행할 수 있는가”가 아니라 “어떻게 다시 마운트한 후에도 Effect가 잘 작동하도록 수정하는가” 이다.
일반적으로 정답은 클린업 함수를 구현하는 것이다. 클린업 함수는 Effect가 수행 중이던 작업을 중지하거나 취소해야 한다. 경험상 (상용 환경에서) 한 번만 실행되는 Effect와 (개발 환경에서의) 설정 → 정리 → 설정 시퀀스를 사용자가 구분할 수 없어야 한다.
작성하게 될 대부분의 Effect는 아래의 일반적인 패턴 중 하나에 해당한다.

4. 개발 환경에서 두 번씩 실행되는 Effect를 처리하는 방법은 무엇인가?

4-1. React가 아닌 위젯 제어하기

때론 React로 작성하지 않은 UI 위젯을 추가해야 하는 경우가 있다. 예를 들어, 페이지에 지도 컴포넌트를 추가한다고 가정해 보면 여기에는 setZoomLevel() 메서드가 있으며, 확대/축소 수준을 React 코드의 zoomLevel state 변수와 동기화하고 싶다. Effect는 다음과 비슷할 것이다.
```
useEffect(() => {
const map = mapRef.current;
map.setZoomLevel(zoomLevel);
}, [zoomLevel]);
```
이 경우 클린업이 필요하지 않다. 개발 환경에서 React는 Effect를 두 번 호출하지만 동일한 값으로 setZoomLevel을 두 번 호출해도 아무 작업도 수행하지 않기 때문에 문제가 되지 않는다. 약간 느릴 수는 있지만 상용 환경에서는 불필요하게 다시 마운트되지 않으므로 문제가 되지 않는다.
일부 API는 연속으로 두 번 호출하는 것을 허용하지 않을 수 있다. 예를 들어, 브라우저의 빌트인 요소인 의 showModal 메서드는 두 번 호출하면 에러를 던잔다. 클린업 함수를 구현하고 대화 상자를 닫도록 하자.

useEffect(() => {
  const dialog = dialogRef.current;
  dialog.showModal();
  return () => dialog.close();
}, []);

개발 중에 Effect는 showModal()을 호출한 다음 즉시 close()를 호출하고, 다시 showModal()을 호출한다. 이는 상용 환경에서 볼 수 있는 것처럼 showModal()을 한 번 호출하는 것과 체감상 동일하다.

4-2. 이벤트 구독하기

Effect가 무언가를 구독하는 경우, 클린업 함수는 구독을 취소해야한다.

useEffect(() => {
function handleScroll(e) {
  console.log(window.scrollX, window.scrollY);
}
window.addEventListener('scroll', handleScroll);
return () => window.removeEventListener('scroll', handleScroll);
}, []);

개발 중에 Effect는 addEventListener()를 호출한 다음 즉시 removeEventListener()를 호출한다. 그런 다음 동일한 핸들러를 사용하여 다시 addEventListener()를 사용함으로써, 한 번에 하나의 구독만 활성화 되도록 한다. 는 상용 환경에서 addEventListener()를 한 번만 호출하는 것과 체감상 동일하다.

4-3. 트리거링 애니메이션

Effect가 무언가를 애니메이션하는 경우 클린업 함수는 애니메이션을 초기값으로 재설정해야한다.

useEffect(() => {
const node = ref.current;
node.style.opacity = 1; // Trigger the animation
                        // 애니메이션 촉발
return () => {
  node.style.opacity = 0; // Reset to the initial value
                          // 초기값으로 재설정
};
}, []);

개발 과정에서 불투명도는 1이었다가, 0이었다가, 다시 1로 설정된다. 이것은 상용 환경에서 1을 한 번만 설정하는 것과 체감상 동일하다. 만약 트위닝을 지원하는 서드파티 애니메이션 라이브러리를 사용하는 경우라면, 클린업 함수에서 타임라인을 초기 state로 재설정해줘야 한다.

4-4. 데이터 페칭하기

Effect가 무언가를 페치하면 클린업 함수는 페치를 중단하거나 그 결과를 무시해야한다.

useEffect(() => {
let ignore = false;

async function startFetching() {
  const json = await fetchTodos(userId);
  if (!ignore) {
    setTodos(json);
  }
}

startFetching();

return () => {
  ignore = true;
};
}, [userId]);

이미 발생한 네트워크 요청을 “실행 취소”할 수는 없으므로, 대신 클린업 함수에서 더 이상 관련이 없는 페치가 애플리케이션에 계속 영향을 미치지 않도록 해야힌다. 만약 userId가 'Alice'에서 'Bob'으로 변경되면 클린업은 'Alice' 응답이 'Bob' 이후에 도착하더라도 이를 무시하도록 한다.
개발 환경에서는 네트워크 탭에 두 개의 페치가 표시된다. 위의 접근 방식을 사용하면 첫 번째 Effect가 즉시 정리되므로, ignore 변수의 복사본이 true로 설정된다. 따라서 추가 요청이 있더라도 if (!ignore) 검사 덕분에 state에 영향을 미치지 않는다.
상용 환경에서는 요청이 하나만 있다. 발 중인 두 번째 요청이 귀찮은 경우 가장 좋은 방법은 요청을 중복 제거하고 컴포넌트 간에 응답을 캐시하는 솔루션을 사용하는 것이다.
```
function TodoList() {
const todos = useSomeDataLibrary(`/api/user/${userId}/todos`);
// ...
```
이렇게 하면 개발 경험이 향상될 뿐만 아니라 애플리케이션이 더 빠르게 느껴진다. 예를 들어, Back 버튼을 누르는 사용자는 일부 데이터가 캐시되기 때문에 다시 로드될 때까지 기다릴 필요가 없다. 이러한 캐시는 직접 구축할 수도 있고, Effect에서 수동으로 페칭하는 기능을 대체하는 많은 대안 중 하나를 사용할 수도 있다.

4-5. 분석 전송

useEffect(() => {
  logVisit(url); // Sends a POST request
}, [url]);

개발 환경에서는 모든 URL에 대해 logVisit이 두 번 호출되므로 이를 수정하고 싶을 수 있다. 이전 예제와 마찬가지로 한 번 실행하는 것과 두 번 실행하는 것 사이에 사용자가 볼 수 있는 동작 차이는 없다. 개발 머신의 로그가 상용 메트릭을 왜곡하는 것을 원하지는 않을 것이니, 실용적인 관점에서 개발 환경에서는 logVisit가 아무 것도 하지 않도록 하자. 차피 개발 환경에서는 파일을 저장할 때마다 컴포넌트가 다시 마운트될 것이고, 따라서 추가 방문이 기록될 것이기 때문이다.
상용 환경에서는 중복 방문 로그가 없다.
전송하는 분석 이벤트를 디버깅하려면 앱을 스테이징 환경(상용 모드에서 실행됨)에 배포하거나, Strict Mode 및 개발 전용의 중복 마운트 검사를 일시적으로 해제할 수 있다. Effect 대신 경로 변경 이벤트 핸들러에서 분석을 전송할 수도 있다. 보다 정확한 분석을 위해서는 intersection observers를 활용하면 뷰포트에 어떤 컴포넌트가 있고 얼마나 오래 표시되는지를 추적하는 데 도움이 될 수 있다.

4-6. Effect가 아님: 애플리케이션 초기화하기

일부 로직은 애플리케이션이 시작될 때 한 번만 실행되어야 한다. 이런 로직은 컴포넌트 외부에 넣을 수 있다.

if (typeof window !== 'undefined') { // Check if we're running in the browser.
                                   // 실행환경이 브라우저인지 여부 확인
checkAuthToken();
loadDataFromLocalStorage();
}

function App() { // ... }

- 이렇게 하면 위 로직은 브라우저가 페이지를 로드한 후 한 번만 실행된다.

**4-7. Effect가 아님: 제품 구매하기**
- 클린업 함수를 작성하더라도 Effect를 두 번 실행함으로써 체감상 결과가 달라지는 것을 막을 방법이 없는 경우도 있다.
예를 들어, Effect가 제품 구매와 같은 POST 요청을 보낸다고 하자.

useEffect(() => { // 🔴 Wrong: This Effect fires twice in development, exposing a problem in the code. // 🔴 틀렸습니다: 이 Effect는 개발모드에서 두 번 실행되며, 문제를 일으킵니다. fetch('/api/buy', { method: 'POST' }); }, []);

- 제품을 두 번 사고 싶지는 않을 것이다. 이 로직을 Effect에 넣지 말아야 하는 이유이기도 하다.
사용자가 다른 페이지로 이동한 다음 Back(뒤로가기)를 누르면, Effect가 다시 실행될 것이다.
사용자는 페이지를 _방문_할 때 제품을 구매하고 싶지는 않을 것이다.
구매 버튼을 _클릭_할 때 구매하길 원할 것이다.
- 구매는 렌더링으로 인한 것이 아니다. 특정 상호 작용으로 인해 발생한다.
사용자가 버튼을 누를 때만 실행되어야한다.
**Effect를 삭제하고 ```/api/buy``` 요청을 구매 버튼 이벤트 핸들러로 이동한다.**

function handleClick() { // ✅ Buying is an event because it is caused by a particular interaction. // ✅ 구매는 특정 상호작용으로 인해 발생하므로 이벤트입니다. fetch('/api/buy', { method: 'POST' }); }

- **다시 마운트하면 애플리케이션의 로직이 깨지는 경우, 일반적으로 기존 버그를 발견할 수 있다.**
사용자 관점에서 페이지를 방문하는 것은 페이지를 방문하여 링크를 클릭하고 뒤로가기 버튼을 누르는 것과 다르지 않아야 한다.
React는 개발 단계에서 컴포넌트를 다시 한 번 마운트하여 이 원칙을 준수하는지 확인한다.

### 5. 한 곳에 모으기

- 이 플레이그라운드를 통해 실제로 Effect가 어떻게 작동하는지 “느껴볼” 수 있다.
- 이 예에서는 [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/setTimeout)을 사용하여 Effect가 실행되고 3초 뒤에 input 텍스트가 포함된 콘솔 로그를 표시하도록 예약한다. 클린업 함수는 보류 중인 타임아웃을 취소합니다.

import { useState, useEffect } from 'react';

function Playground() { const [text, setText] = useState('a');

useEffect(() => { function onTimeout() { console.log('⏰ ' + text); }

console.log('🔵 Schedule "' + text + '" log');
const timeoutId = setTimeout(onTimeout, 3000);

return () => {
  console.log('🟡 Cancel "' + text + '" log');
  clearTimeout(timeoutId);
};

}, [text]);

return ( <> What to log:{' '} setText(e.target.value)} />

{text}

); }

export default function App() { const [show, setShow] = useState(false); return ( <> {show &&

} {show && } ); }

```

처음에는 Schedule "a" log, Cancel "a" log, Schedule "a" log의 세 가지 로그가 표시된다. 3초 후에 a라는 로그도 표시된다. 앞서 배운 것처럼 schedule/cancel 쌍이 한 번 더 출력되는 이유는 개발 환경에서 React가 클린업을 잘 구현했는지 확인하기 위해 컴포넌트를 다시 마운트하기 때문이다.
이제 input을 편집하여 abc라고 입력하라. 충분히 빨리 입력하면 Schedule "ab" log와 Cancel "ab" log, Schedule "abc" log가 바로 표시될 것이다. React는 항상 다음 렌더링의 Effect 전에 이전 렌더링의 Effect를 정리한다. 따라서 입력을 빠르게 입력하더라도 한 번에 최대 한 번만 타임아웃이 예약된다.
input에 무언가를 입력한 다음 즉시 “Unmount the component”를 눌러보자. 마운트를 해제하면 마지막 렌더링의 Effect가 어떻게 정리되는지 확인하자. 여기서는 Effect가 실행 기회를 갖기 전에 마지막 타임아웃을 지운다.
마지막으로 위의 컴포넌트를 편집하고 타임아웃이 취소되지 않도록 클린업 함수를 주석 처리 해보자. abcde를 빠르게 입력해 보자. 3초 후에 어떤 일이 일어날까?
3초 후, 5개의 abcde가 아닌 일련의 (a, ab, abc, abcd, abcde)가 표시되어야 한다. 각 Effect는 해당 렌더링에서 text 값을 “캡처”한다. text state가 변경되더라도, text = 'ab'인 렌더링의 Effect는 항상 'ab'를 표시한다. 즉,각 렌더링의 Effect는 서로 분리되어 있다. 이것이 어떻게 작동하는지 궁금하다면 클로저를 읽어 보자.

요약

이벤트와 달리 Effect는 특정 상호 작용이 아닌 렌더링 자체에 의해 발생한다.
Effect를 사용하면 일부 외부 시스템(서드파티 API, 네트워크 등)과 컴포넌트를 동기화할 수 있다.
기본적으로 Effect는 모든 렌더링 후에 실행된다. (초기 렌더링 포함)
React는 모든 의존성이 마지막 렌더링 시점과 동일한 값을 갖는 경우 Effect를 건너뛴다.
의존성을 “선택”할 수는 없다. 그들은 Effect 내부의 코드에 의해 결정된다.
빈 의존성 배열([])은 컴포넌트 “마운팅”, 즉,화면에 추가되는 시점에 대응한다.
Strict 모드에서 React는 컴포넌트를 두 번 마운트하여(개발 중인 경우에만) Effect를 스트레스 테스트한다.
다시 마운트를 수행함으로 인해 Effect가 깨지는 경우, 클린업 함수를 구현해야 한다. = React는 다음 Effect가 실행되기 전 및 마운트 해제 시점에 클린업 함수를 호출한다.

React 공식 문서

React 비공식 번역 문서

MDN

Wikipedia

React 공식문서 이해하기 (24)

Mon, 04 Dec 2023 09:47:00 GMT

Chapter 4. Escape Hatches

#2 ref로 DOM 조작하기

학습 목차

1. 노드에 대한 ref 가져오기 2. 다른 컴포넌트의 DOM 노드에 접근하기 3. React가 ref를 첨부할 때 4. ref를 이용한 DOM 조작 모범 사례

1. 노드에 대한 ref 가져오기

React가 관리하는 DOM 노드에 접근하려면, 먼저 useRef 훅을 불러오자. import { useRef } from 'react';
그런 다음 컴포넌트 내부에서 ref를 선언하자. const myRef = useRef(null);
마지막으로, DOM 노드를 가져올 JSX 태그에 ref 속성으로 참조를 전달하라.
이 useRef 훅은 current 라고 하는 프로퍼티가 포함된 객체를 반환한다. 처음에는 myRef.current 는 null 이 될 것이다. React가 이
에 대한 DOM 노드를 생성하면, React는 이 노드에 대한 참조를 myRef.current에 넣는다. 그런 다음 이벤트 핸들러에서 이 DOM 노드에 액세스하고 여기에 정의된 빌트인 브라우저 API를 사용할 수 있다.
```
// 모든 브라우저 API를 사용할 수 있습니다. 예를 들어:
myRef.current.scrollIntoView();
```

2. 다른 컴포넌트의 DOM 노드에 접근하기

과 같은 브라우저 엘리먼트를 출력하는 빌트인 컴포넌트에 ref를 넣으면, React는 해당 ref의 current 프로퍼티를 해당 DOM 노드(예: 브라우저의 실제 )로 설정한다.
그러나 과 같은 여러분이 만든 컴포넌트에 ref를 넣으려고 하면 기본적으로 null이 반환된다.

문제를 알아차리는 데 도움이 되도록 React는 콘솔에 오류를 출력하기도 한다.

//Console
Warning: Function components cannot be given refs. Attempts to access this ref will fail. Did you mean to use React.forwardRef()?
// 경고: 함수 컴포넌트에는 refs를 지정할 수 없습니다. 이 ref에 접근하려는 시도는 실패합니다. React.forwardRef()를 사용하려고 하셨나요?

이는 기본적으로 React가 컴포넌트가 다른 컴포넌트의 DOM 노드에 접근하는 것을 허용하지 않기 때문이다.
ref는 탈출구이기 때문에 아껴서 사용해야 한다.
다른 컴포넌트의 DOM 노드를 수동으로 조작하면 코드가 훨씬 더 취약해진다.
대신, DOM 노드를 노출하길 원하는 컴포넌트에 해당 동작을 설정해야 한다. 컴포넌트는 자신의 ref를 자식 중 하나에 “전달”하도록 지정할 수 있습니다.
디자인 시스템에서 버튼, 입력 등과 같은 저수준 컴포넌트는 해당 ref를 DOM 노드로 전달하는 것이 일반적인 패턴이다. 반면 양식, 목록 또는 페이지 섹션과 같은 상위 수준 컴포넌트는 일반적으로 DOM 구조에 대한 우발적 의존성을 피하기 위해 해당 DOM 노드를 노출하지 않는다.

3. React가 ref를 첨부할 때

React에서 모든 업데이트는 두 단계로 나뉜다.
- 렌더링 하는 동안 React는 컴포넌트를 호출하여 화면에 무엇이 표시되어야 하는지 파악한다.
- 커밋(commit) 하는 동안 React는 DOM에 변경 사항을 적용한다.
일반적으로 렌더링 중에는 ref에 액세스하는 것을 원하지 않을 것이다. DOM 노드를 보유하는 ref도 마찬가지이다.
첫 번째 렌더링 중에는 DOM 노드가 아직 생성되지 않았으므로 ref.current는 null이 된다. 그리고 업데이트를 렌더링하는 동안에는 DOM 노드가 아직 업데이트되지 않았다. 따라서 이를 읽기에는 너무 이르다.
React는 커밋하는 동안에 ref.current를 설정한다. React는 DOM이 업데이트 되기 전에는 ref.current의 값을 null로 설정하였다가, DOM이 업데이트된 직후 해당 DOM 노드로 다시 설정한다.
일반적으로 이벤트 핸들러에서 ref에 접근한다.
ref로 무언가를 하고 싶지만 그 작업을 수행할 특정 이벤트가 없다면, Effect가 필요할 수 있다.

4. ref를 이용한 DOM 조작 모범 사례

Ref는 탈출구이다. React 외부로 나가야” 할 때만 사용해야 한다. 일반적인 예로는 초점을 맞추거나, 스크롤 위치를 관리하거나 React가 노출하지 않는 브라우저 API를 호출하는 것이 있다.
포커스나 스크롤 같은 비파괴적 동작을 고수한다면 문제가 발생하지 않을 것이다. 그러나 DOM을 수동으로 수정하려고 하면 React가 수행하는 변경 사항과 충돌할 위험이 있다.
React가 관리하는 DOM 노드를 변경하지 말자. React가 관리하는 요소를 수정하거나, 자식을 추가하거나 제거하면, 위와 같이 일관성 없는 시각적 결과나 충돌이 발생할 수 있다.
그렇다고 전혀 할 수 없다는 건 아니고, 주의가 필요하다는 의미이다.
React가 업데이트할 이유가 없는 DOM의 일부는 안전하게 수정할 수 있다.* 예를 들어, JSX에서 일부
가 항상 비어 있는 경우, React는 그 자식 목록을 건드릴 이유가 없다. 따라서 수동으로 요소를 추가하거나 제거하더라도 안전하다.

요약

Ref는 일반적인 개념이긴 하지만, 대부분 DOM 엘리먼트를 보관할 때 사용한다.
를 전달해 DOM 노드를 myRef.current에 넣으라고 React에 지시한다.
보통은 포커스, 스크롤, DOM 엘리먼트 측정과 같은 비파괴적인 동작에 ref를 사용한다.
컴포넌트는 기본적으로 DOM 노드를 노출하지 않는다. forwardRef를 사용하고 두 번째 ref 인수를 특정 노드에 전달하여 DOM 노드를 노출하도록 설정할 수 있다.
React가 관리하는 DOM 노드를 변경하지 말자.
React가 관리하는 DOM 노드를 수정해야 한다면 React가 업데이트할 이유가 없는 부분을 수정하라.

React 공식 문서

React 비공식 번역 문서

MDN

Wikipedia