type INullable<T> = T | null;
interface ITodos {
id: string;
text: string;
isDone: boolean;
}
function fetchTodo (): Promise<INullable<ITodos>> {
// request api
}
fetchTodo().then(todo => {
// 서버의 응답값이 null일 수 있기 때문에 방어코드를 추가해준다.
if(!todo) {
// do something
}
});
Maybe
프론트 개발을 하다보면 아무리 정해져 있는 API 규약에 맞춰 백엔드 서버와 커뮤니케이션 한다고 하더라도 실제 정해져있는 규약으로 넘어오지 않는 경우가 많다. 그러한 경우 값이 없을 때의 타입이 null인지, undefined인지 알 수가 없다. 물론 아예 해당하는 키의 데이터가 안내려올때도 있지만 그러한 경우는 optional 옵션을 이용하여 인터페이스를 선언하면 되지만, 타입이 명확하지 않은 경우는 런타임 환경에서 타입 에러에 직면하는 경우가 많다. 그런 경우를 대비하며 Nullable 타입과 분리하여 Maybe 유틸 타입을 선언하여 사용한다.
Nullable
Maybe
프론트 개발을 하다보면 아무리 정해져 있는 API 규약에 맞춰 백엔드 서버와 커뮤니케이션 한다고 하더라도 실제 정해져있는 규약으로 넘어오지 않는 경우가 많다. 그러한 경우 값이 없을 때의 타입이 null인지, undefined인지 알 수가 없다. 물론 아예 해당하는 키의 데이터가 안내려올때도 있지만 그러한 경우는 optional 옵션을 이용하여 인터페이스를 선언하면 되지만, 타입이 명확하지 않은 경우는 런타임 환경에서 타입 에러에 직면하는 경우가 많다. 그런 경우를 대비하며 Nullable 타입과 분리하여 Maybe 유틸 타입을 선언하여 사용한다.
Reference