식별된 union은 FE개발자의 베프입니다.
프론트엔드 개발자의 업무는 단순히 픽셀을 푸시하는 것만이 아닙니다. 프론트엔드에서 발생하는 대부분의 복잡성은 앱의 다양한 상태를 모두 처리하는 데서 비롯됩니다.
데이터를 로드하거나, 양식이 채워지기를 기다리거나, 원격 분석 이벤트를 전송하거나, 이 세가지를 동시에 처리해야 할 수도 이닏습니다.
상태를 제대로 처리하지 않으면 문제가 발생할 가능성이 높습니다. 상태 처리는 타입으로 표현하는 방식에서 시작됩니다.
간단한 데이터 로더를 빌드한다고 가정해 봅시다. 상태를 표현하기 위해 이와 같은 타입을 사용할 수 있습니다.
interface State {
status: "loading" | "error" | "success";
error?: Error;
data?: { id: string };
}
// Some examples:
const example: State = {
status: "loading"
};
const example2: State = {
status: "error",
error: new Error("Oh no!")
};
상태를 확인하여 화면에 표시할 UI의 종류를 파악할 수 있어 매우 유용해 보입니다.
단, 이 타입을 사용하면 불가능해야 하는 모든 종류의 모양을 선언할 수 있습니다.
const example3: State = {
status: "success",
// Where's the data?!
};
여기서는 성공 상태이므로 데이터에 액세스할 수 있어야 합니다. 하지만 데이터는 존재하지 않습니다.
const example4: State = {
status: "loading",
// We're loading, but we still have an error?!
error: new Error("Eek!"),
};
여기서는 로딩 상태이지만 데이터 객체에 여전히 오류가 있습니다!
이는 선택적 속성으로 가득찬 객체, 즉 ‘bag of optionals’라고 부르는 것을 사용하여 상태를 표현하기로 선택했기 때문입니다.
옵셔널 프로퍼티는 값이 있을 수도 있고 없을 수도 있을 때 가장 잘 사용됩니다. 이 경우에는 그렇지 않습니다.