Ts를 쓰는 프로젝트의 form태그를 작성하다 만난 유효성 검사 라이브러리
왜? 그리고 어떻게 쓰는지까지 알아보기 위해 작성
interface
, type
등을 선언해서 작성한 Ts의 타입 에러는 컴파일 과정에서만 유효하다.이렇듯 Ts는 코드에 명시되어 있는 타입 구조를 정적으로 분석하여 프로그램을 실행하지 않고도 발생할 가능성이 있는 문제를 예측할 수 있다.
결국 Ts는 정적언어로서 예측가능한 문제를 개발자에게 알려줌으로써 좀 더 견고한 코드를 짤 수 있도록 도와주는 도구일 뿐이다.
그렇기에 타입 검사는 컴파일 과정까지만 유효하고, 그 이후의 유효성 검증은 컴파일이 끝난 Js 프로그램의 실행 시점에서 일어나고 최종 사용자(클라이언트)를 위한 것이다. 즉 타입 검사와 유효성 검증은 엄연히 다르고, 타입 검사가 유효성 검증를 대신할 수도 없다.
Zod를 사용할 때 가장 먼저 해야 할 것 : Schema 정의하기!
Schema: 데이터의 형태와 구조.
// zod로 정의한 스키마
const User = z.object({
id: z.string(),
age: z.number(),
isAdult: z.boolean(),
});
parse()
함수에 검증하고싶은 값을 넘겨서 호출하면 된다.
// 검증 성공
User.parse({
email: "example@gmail.com",
age: 1,
isAdult: false,
});
// 검증 실패
User.parse({
email: "example@gmail.com",
age: "1",
});
⚠️ 주의
검증이 성공했을 경우parse()
함수가 반환하는 객체에는 검증에 통과한 속성만 포함된다
const user = User.parse({
email: "example@gmail.com",
age: 1,
isAdult: false,
password: "123" // 스키마에 정의 되지 않음
});
console.log(user);
// console.log(user)
{
email: "user@test.com",
age: 35,
active: true,
}
위 코드에서 password
는 정의되어 있지 않기에 parse()
함수는 스키마에 정의된 속성 외에 추가적인 속성이 있는 것을 허용하지 않아 이 경우 타입 에러가 발생한다.
또한 Zod는 스키마를 기준으로 Ts의 타입을 알아서 추론할 수도 있다.
이 기능을 활용하면 타입을 따로 작성할 필요가 없어진다.
import { z } from "zod";
const Man = z.object({
name: z.string(),
height: z.number(),
age: z.number(),
phoneNum: z.string(),
homePhoneNum: z.string().optional(),
isCompletedMilitaryService: z.boolean(),
});
type ManType = z.infer<typeof Man>;
const processMan = (man : ManType) => {
Man.parse(man); // 유효성 검증
// 사용자 처리 로직
}
import { z } from "zod";
// primitive values
z.string();
z.number();
z.bigint();
z.boolean();
z.date();
z.symbol();
// empty types
z.undefined();
z.null();
z.void(); // accepts undefined
// catch-all types
// allows any value
z.any();
z.unknown();
// never type
// allows no values
z.never();