서버에 있는 상태를 타이핑하는 것에 대한 고민

[nninnnin]

고민

서버에서 동적으로 가져오는 카테고리 관련 정보가 있습니다. 이것을 타이핑해 사용하기 위해 저는 보통 클라이언트 TS 코드에 다음과 같은 타입을 작성하는데요,

export type ProjectType = "위치기반 AR" | "얼굴인식 AR" | "이미지마커 AR";

작성할때마다 양심에 걸리는 것이, 서버에서 다이나믹하게 관리되는 상태를 정적으로 타이핑해두는것이 괜찮은가? 혹은 그냥 string타입으로 루즈하게 관리하는 것이 좋을까 싶은데, string 타입으로 관리하자니 해당 정보를 이용해 퍼널상태를 관리한다던지 할 때 유용성이 떨어져 고민입니다.

여러분은 어떻게 동적인 서버상태를 타이핑하고 계신가요?

[milooy]

오! 좋은 고민거리네요.

저라면 런타임에서 서버 응답을 검증하면서(zod든, 에러 throw든), 정적 타입을 활용하는 방식을 택할 것 같아요.
그리고 만약 스웨거에서 enum으로 제공해줄 수 있다면, OpenAPI Generator 등으로 서버 데이터를 기반으로 TypeScript 타입을 생성해주는 장치를 추가하면 서버와 프론트간의 싱크도 챙길 수 있어보입니다.

[nninnnin]

그렇군요! zod를 이용해서 검증과정을 거치도록 한번 코드를 짜봐야겠네요. 유용한 조언 감사합니다 :)

[joseph0926]

서버에서 변경 가능한 enum 필드를 클라이언트에서 TS의 유니온등으로 정의했을 경우, 서버의 필드가 갑자기 바뀌는 상황(있으면 안되는 일이지만)에 클라이언트가 터지는 상황이 불안하신거라면, 유니온 타입에 폴백 스트링을 하나 추가하신 후 else나 switch의 default에서 해당 폴백 스트링을 처리하도록 하면 조금이나마 안전할거같다고 생각합니다

예를들어 export type ProjectType = "위치기반 AR" | "얼굴인식 AR" | "이미지마커 AR" | "UNKNOWN"; 이렇게 유니온 타입으로 정의하고

  switch (projectType) {
    case "위치기반 AR":
      ...
      break;
    case "얼굴인식 AR":
      ...
      break;
    case "이미지마커 AR":
      ...
      break;
    case "UNKNOWN":
    default:
      // 예외처리
      break;
  }

예전에 개인 프로젝트로 graphQL을 다루면서 문서를 검색하다가 찾았던 패턴이라 아래 해당 문서 공유드립니다

https://www.charpeni.com/blog/graphql-enums-are-unsafe

[ho1234c]

상황에 따라 다르기 때문에 커뮤니케이션을 통해 결정해야하는 부분같아요.

"안전하다"의 범위를 어디까지로 볼 것 인가에 대해 이야기해야 할것 같은데, 클라이언트에서 서버를 통제할 수 없는 외부요인으로 취급한다면 사실 모든 서버 통신에 대해 정해진 타입을 반환하지 않는 경우를 상정해야 합니다.

하지만 이건 현실적이지 않고, fetch로 받은 응답을 정해진 타입으로 캐스팅한다는것은 그 외 약속한 형태가 아니게 오는건 우리가 정의한 세계에서 없는일이다, 여기에 대한 예외는 우리가 다루는 범위로 취급하지 않겠다 라고 가정 하겠다는 것이에요.

이렇듯 ProjectType 이 서버 관점에서 변경될 가능성이 충분히 높다면 다른분께서 말씀해주신 fallback type을 추가하는게 솔루션이 될 수 있고, 변경될 가능성이 미미해서 무시해도 된다면 "위치기반 AR" | "얼굴인식 AR" | "이미지마커 AR" 까지만 처리하도록 type을 구성할것 같아요.

즉, 우리가 만든 세계를 어디까지로 정의할건지에 대한 결정이 아닐까 싶습니다.

[DoK6n]

export type ProjectType = "위치기반 AR" | "얼굴인식 AR" | "이미지마커 AR" | (string & NonNullable<unknown>);

느슨하게와 타입좁히는 것에 타협점을 찾고 싶으시다면 이런 방식은 어떠신가요?

[nninnnin]

오호, 방금 시도해봤는데 기대하는 것처럼 작동되네요! string도 들어갈 수 있고 기존의 타입들도 컴파일러에서 인식하네요. 제가 NonNullable에 익숙하지 않아서 잘 이해가 되지 않는데, 혹시 어떻게 이러한 동작을 하는지 간단히 설명을 부탁드려도 괜찮을까요?

[nninnnin]

혹시나 보게되실 다른분들을 위해 제가 알아본 내용 간략히 정리해봐요!

먼저 NonNullable은 TS 에서 다음과 같이 정의되어 있습니다.

/**
 * Exclude null and undefined from T
 */
type NonNullable<T> = T & {};

모르시는 분들을 위해, 여기에서 {} 는 타입스크립트에서 nullish value 가 아닌 모든 원시값과 객체값을 할당할 수 있는 타입입니다.

따라서 NonNullable<unknown> 은 unknown & {} 으로 해석될 것이고, 이것은 결국 {} 로 귀결됩니다.

따라서 댓글 작성자님이 작성해주신 코드 중 string & NonNullable<unknown> 부분은 string & {} 가 됩니다. 그리고 string & {} 는 의미상으로는 string으로 해석되지만 타입스크립트는 이것을 문자열 값과 동일한 레벨의 타입으로 해석해서, 'a' | 'b' | 'c' | string 이 string 으로 축소평가 되는 것과는 달리 'a' | 'b' | 'c' | (string & {}) 은 우리가 기대하는 것과 같이 'a' | 'b' | 'c' | string 으로 평가된다고 합니다.

해당 코드를 처음 작성할 때 저처럼 많은 개발자들이 이러한 결과를 기대할텐데 이건 타입스크립트 설계에서 놓친 부분이라고 하네요. 당분간은 알려주신 것과 같은 방식대로 NonNullable 또는 {}를 사용해서 workaround 해 사용하면 될 것 같습니다.

아예 명시적으로 LiteralUnion 이라는 유틸리티를 제공하는 라이브러리 도 있네요 :)