Dev Camp : typescript 한계와 zod -shadcn (4)

lunaxislu·2024년 3월 14일

dev-camp

목록 보기

4/5

OverView

shadcn-ui에 당연히 form component도 있다.

이 form component의 구성요소는 react-hook-form + zod 라이브러리들을 결합하여 ui component를 만들었는데, react-hook-form 라이브러리는 당연히 form과 관련된 라이브러리로 직관적이게 알수 있지만

zod라.... ~~죠스 바는 아는데..~~

생소한 zod에 대해 한번 알아보자

typescript의 한계성

우선 타입스크립트??

초보자이면서도 미숙한 나에게도 편리하고 대단한 녀석이다.

그러나 반대로 생각해보면 javascript의 특징인 동적언어를 버리는 것이라고도 할 수 있다 생각한다.

typescript는 컴파일을 하는 시점에서만 타입에러를 잡아내고 런타임 단계에서의 타입에러는 어쩔 수가 없다.

function notZod(prop:string){ 
  //대단해 엄청난 연산
  return value as number
}

위의 코드처럼 타입 추론과 컴파일 과정에서 타입 assertion을 해도 런타임 단계에서는 타입강제한 value 값이 number가 아니면 오류가 아니겠나??

추가적으로 타입스크립트는 결국 자바스크립트로 컴파일되어 동작하므로 조금만 생각을 달리해보면 '런타임에는 무용지물? 약한 녀석이다.

예를 들어 타입스크립트로 작성한 Node.js 서버가 HTTP 요청을 받았을 때 클라이언트가 userName이라는 값을 보내주었다고 선언(단언)할 수는 있지만, 이는 가정이 맞았을 때 자신의 코드가 잘 동작함을 보장할 뿐

사용자가 실제로 어떤 값을 보냈는지 검사하지는 않는다.

typescript의 타입은 세분화가 잘 되어있지 않는다.
가령 number type을 지정하느 것은 가능하지만,

원하는 문자열, 숫자 범위를 강제하거나

number타입의 정수/실수 구분은 불가하다. 그렇다면 어떻하면 좋을까??
~~코드 잘짜면 되긴함~~

유효성 검증의 고통

url 유효성, 이메일 유효성 검사, 비밀번호 검사, 그리고 아직 검사할 기회가 없는 IP등 특정 문자열 형식의 검사등이 필요하면 유효성 검증을 구현하게 되는데

const regUrl = /(ftp|http|https):\/\/(\w+:{0,1}\w*@)?(\S+)(:[0-9]+)?(\/|\/([\w#!:.?+=&%@!\-\/]))?/;

function isValidate(){
  if(typeof id !== "string" || id.length < 18 ) throw new Error("invalid id")
  
  if(typeof password !== "number" || password.length < 0 ) throw new Error("invalid password")
  
  if(typeof url !== "string" || url.length < 40 || !regUrl.test(url) ) throw new Error("invalid url")
  // ...
}

작성해야할 유효성 검사가 많고 비즈니스 로직보다 유효성 검증 로직이 차지하는 공간이 더 커질수도 있다. 배보다 배꼽이 클수도 있는 상황이 올 수도 있다.

이렇게 직접 유효성 검증을 구현하는 것이 효과적인 접근 방법은 아닌것 같다..

ZOD

그렇다면 어떻게 typescript,위와 같은 한계점을 보완할 수 있을까??

zod is a TypeScript-first schema declaration and validation library. -Zod Docs

zod는 공식문서에 나와있듯이 스키마(schema) 선언 및 유효성 검사 라이브러리다.

Y ZOD ??

당위성 : typescript의 한계로 zod 라이브러리는 typescript를 보완하며, 동시에 특정 로직의 유효성 검사를 대단히, 엄청난, 엄격히 해준다.

스키마 (schema)

스키마(schema)라는 단어는 형태 , 모양 , 모양 또는 계획 을 의미.

IT업계?에서의 스키마란 데이터의 형태 및 구조라고 할 수 있다.

현재까지의 zod를 생각한다면, 유효성 || typescript의 확장판, reg Ex의 확장판 이라는 느낌이 강함

간단하게 맛만 보기

zod를 통해서 길어질 수 있고 타입추론의 한계점을 극복 해보는 예시 코드를 작성해 보겠다.

    // zod로 스키마 정의
    const account = z.object({
        id:z.string().uuid(),
        email:z.string().email(),
        age: z.number().int().min(18).max(90),
        image:z.string().url().max(200).optional(),
        active:z.boolean().default(false),
        createdAt:z.date().default(new Date())
    })

    // 스키마로 부터 타입 추론, 타입선언
    type Account = z.infer<typeof account>

    const isValidatedAccount=(계정:Account)=>{

        // 스키마로 유효성 검증
        account.parse(계정) || account.safeParse(계정)
        // something logic...
    }