지난 포스팅에서 Zod로 스키마를 정의하는 다양한 방법에 대해서 알아보았는데요. Zod의 부가적인 기능이지만 알아두면 굉장히 유용한 입출력 간 데이터 변환에 대해서 알아보겠습니다. 내장 트랜스포머 Zod는 입출력 간 문자열 변환을 돕기 위해서 트랜스포머(transformer)를 내장하고 있는데요. 대표적으로 .trim(), .toLowerCase(), .toUpperCase()를 들 수 있습니다. 그럼 이 3가지 내장 트랜스포머를 모두 사용해서 스키마를 하나 정의한 후에 데이터 변환을 해보겠습니다. 결과를 출력해보면 입력된 문자열이
이전 포스팅에서는 Zod를 사용하여 하나의 스키마로 유효성 검증과 타입 선언을 한 번에 해결하는 방법에 대해서 살펴보았는데요. 이번 포스팅에서는 Zod에 제공하는 타입스크립트 친화적인 검증자를 사용하여 스키마를 정의하는 다양한 방법에 대해서 알아보도록 하겠습니다. 자료형 스키마 정의는 자료형울 명시하는 것부터 시작하는데요. Zod는 자바스크립트의 기본 자료형이나 Date와 같은 내장 클래스에 대응하는 검증자(validator) 함수를 제공합니다. 예를 들어, 이메일, 나이, 활성화 여부, 생성 일자로 이루어진 사용자 객체를 나타내는
이전 포스팅에서 타입스크립트로 코드를 작성하는 것과 무관하게 왜 자바스크립트 프로그램에서 유효성 검증이 필요한지에 대해서 알아보았는데요. 이번 포스팅에서는 최근 개발자들로부터 많은 인기를 끌고 있는 Zod를 사용하는 전반적인 방법에 대해서 알아보겠습니다. 라이브러리 설치 프로젝트에 zod라는 패키지를 npm으로 설치합니다. 그리고 Zod를 사용하실 때는 가급적 타입스크립트는 strict 모드로 쓰시기를 추천드릴게요. 이제 zod 패키지에서 z를 불러올 수 있으며, 이 녀석만 있으면 우리는 Zod의 모든 기능을 활용할 수 있습니다.
"타입스크립트로 코드를 짜니까 별도로 유효성 검증은 필요없는 거 아니에요?" 타입스크립트를 공부하고 계시거나 자바스크립트 경험이 많지 않은 개발자들로 부터 종종 받는 질문인데요. 정말 타입스크립트의 타입 검사가 자바스크립트의 유효성 검증을 대신할 수 있을까요? 이번 포스팅에서는 이러한 타입스크립트에 대한 오해를 풀어보는 시간을 갖도록 하겠습니다. 타입스크립트의 역할 이해를 돕기 위해서 타입스크립트로 간단한 코드를 함께 짜볼까요? 사용자 계정을 나타내는 Account 인터페이스를 선언하고 이것을 입력으로 받는 processAccoun
설정 파일 하나 잘못 건드렸다가 배포가 실패한 경험, 다들 한 번쯤 있지 않을까요? tsconfig.json에 오타가 있었다거나 GitHub Actions 워크플로우 파일에서 들여쓰기를 하나 잘못 넣었다거나 😅 JSON 파일은 사람이 읽고 쓰기엔 편하지만 구조가 조금만 복잡해지면 어떤 필드가 필수인지, 값의 타입이 뭔지 헷갈리기 시작합니다. 이런 문제를 해결하기 위해 등장한 것이 JSON Schema인데요. JSON 데이터가 어떤 구조를 가져야 하는지를 JSON 형태로 정의하는 표준이라고 생각하면 됩니다. 이번 글에서는 JSON