การเปิดตัว Zod 4

 (zod.dev)
1 คะแนน โดย GN⁺ 2025-05-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Zod ไลบรารีสำหรับประกาศสคีมาและตรวจสอบความถูกต้อง เปิดตัวเวอร์ชัน 4 แบบเสถียร พร้อมการปรับปรุงประสิทธิภาพครั้งใหญ่และฟีเจอร์ที่มีการร้องขอมาอย่างยาวนาน
  • มีการปรับปรุงครั้งใหญ่ทั้งด้านความเร็วและขนาดบันเดิล โดยมินิเวอร์ชันใหม่ (v4-mini) ช่วยลดขนาดบันเดิลลงอย่างมาก
  • เพิ่ม metadata registry ใหม่, การแปลงเป็น JSON Schema และความสามารถในการอนุมาน recursive type
  • ยกระดับประสบการณ์นักพัฒนาด้วย การปรับแต่งข้อความข้อผิดพลาด และระบบ locale หลายภาษา
  • ขยายความสามารถในการต่อยอดเพิ่มเติมด้วยการเพิ่ม core subpackage ที่สามารถนำไปใช้สร้างไลบรารีในอนาคตได้

แนะนำ Zod 4

ข้อมูลสำคัญเกี่ยวกับการเปิดตัว

  • หลังการพัฒนาอย่างต่อเนื่องตลอด 1 ปี Zod 4 ได้เปิดตัวเป็นเวอร์ชันเสถียรแล้ว
  • การพัฒนาได้รับการสนับสนุนจาก OSS Fellowship ของ Clerk
  • ขณะนี้มีการแจกจ่ายควบคู่กับ Zod 3 ทำให้ค่อย ๆ ย้ายไปใช้ Zod 4 ได้ง่าย
  • รายละเอียดของการเปลี่ยนแปลงที่อาจไม่เข้ากันย้อนหลังบางส่วนดูได้ใน Migration guide

เบื้องหลังการเติบโต

  • เมื่อเทียบกับ Zod 3 ที่เปิดตัวในปี 2021, Zod 4 เติบโตแบบก้าวกระโดดทั้งในด้านจำนวนดาวบน GitHub และยอดดาวน์โหลดรายสัปดาห์
  • Zod 4 เร็วกว่า เบากว่า และทำงานกับ TypeScript compiler ได้มีประสิทธิภาพยิ่งขึ้น
  • มีการแก้ไขปัญหาหลัก 9 ข้อที่ถูกเรียกร้องมาอย่างยาวนาน

เบนช์มาร์กและประสิทธิภาพ

  • ความเร็วที่เพิ่มขึ้น:
    • การ parse สตริง: เร็วขึ้น 14.71 เท่า
    • การ parse อาร์เรย์: เร็วขึ้น 7.43 เท่า
    • การ parse อ็อบเจ็กต์ (safeParse): เร็วขึ้น 6.5 เท่า
  • มีสคริปต์สำหรับรันเบนช์มาร์กได้โดยตรงจากรีโป
  • ด้วยโครงสร้าง generics ที่ปรับปรุงใหม่ ทำให้ประสิทธิภาพการคอมไพล์ดีขึ้น 10 เท่าเมื่อ chain เมธอดอย่าง .extend(), .omit() เป็นต้น
  • ความเร็วในการคอมไพล์ของ TypeScript ดีขึ้นอย่างมากในสคีมาขนาดใหญ่และโค้ดเบสขนาดใหญ่

ขนาดบันเดิลและ Zod Mini

  • ขนาดบันเดิลพื้นฐานลดลง 57% ทำให้ v4 มีขนาดเล็กกว่า v3 ถึง 2.3 เท่า
  • zod/v4-mini มาพร้อม API แบบฟังก์ชันที่รองรับ tree-shaking และช่วยลดขนาดบันเดิลได้สูงสุด 85%
  • ความแตกต่างของ API ระหว่าง core กับ v4-mini มีการสรุปไว้อย่างละเอียดในเอกสารทางการ
  • โครงสร้างถูกออกแบบมาเพื่อให้ bundler ตัดเมธอดที่ไม่ได้ใช้ออกได้ง่าย

Metadata registry และการรองรับ JSON Schema

  • สามารถลงทะเบียนและจัดการ typed metadata บนสคีมาแบบ strongly typed ได้
  • ใน global registry (z.globalRegistry) มีความสามารถในการจัดการ metadata ที่เข้ากันได้กับ JSON Schema และรวมเข้าไปให้อัตโนมัติ
  • ใช้ .meta(), .describe() เพื่อจัดทำเอกสารสคีมาได้สะดวก
  • ใช้ .toJSONSchema() เพื่อแปลงสคีมาเป็นรูปแบบ JSON Schemaได้ พร้อมสะท้อน metadata โดยอัตโนมัติ

การอนุมาน recursive type อัตโนมัติ

  • สามารถนิยามและอนุมาน recursive object type และ mutually recursive type ได้อย่างเป็นธรรมชาติโดยไม่ต้อง type cast แยก
  • ใช้งานได้ดีขึ้นมากเมื่อเทียบกับแพตเทิร์นเดิมของ Zod 3
  • แม้เป็น recursive หรือ mutually recursive type ก็ยังใช้ความสามารถของเมธอดสคีมาได้ครบถ้วน

ประเภทไฟล์และฟีเจอร์การตรวจสอบ

  • เพิ่ม type ใหม่ file() สำหรับตรวจสอบอินสแตนซ์ File
  • รองรับการตรวจสอบข้อกำหนดไฟล์หลากหลายแบบ เช่น ขนาดไฟล์ (min, max) และ MIME type

ข้อความข้อผิดพลาดและระบบ locale

  • รองรับข้อความข้อผิดพลาดหลายภาษาผ่าน global locale API (z.locales)
  • มีฟังก์ชันทางการ z.prettifyError สำหรับจัดรูปแบบข้อผิดพลาดให้อ่านง่ายสำหรับผู้ใช้

ฟังก์ชัน format และ template literal

  • string format เดิม (เช่น email) ถูกยกระดับเป็นฟังก์ชันระดับบน ทำให้อ่านง่ายขึ้นและ tree-shaking ทำงานได้ดีขึ้น
  • มีตัวเลือก regex สำหรับอีเมล หลายแบบ เพื่อตอบโจทย์ความต้องการในการตรวจสอบที่หลากหลาย
  • รองรับ template literal type: สร้างแพตเทิร์นสตริงและชุดการประกอบที่ซับซ้อนซึ่งระบบ type แสดงออกได้อย่างง่ายดาย

ฟอร์แมตตัวเลขและ bigint ที่เพิ่มใหม่

  • รองรับ จำนวนเต็มและจำนวนทศนิยมแบบความกว้างคงที่ (int32, uint64 เป็นต้น)
  • สามารถสร้างสคีมาที่เพิ่มข้อจำกัดค่าต่ำสุด/ค่าสูงสุดโดยอัตโนมัติภายในช่วงที่ปลอดภัย

แนะนำ z.stringbool

  • รองรับการ parse boolean จากสตริง (เช่น yes, no) และรองรับการ parse สไตล์ตัวแปรแวดล้อมด้วย
  • สามารถปรับแต่งค่า truthy/falsy ได้

รวม API สำหรับปรับแต่งข้อผิดพลาด

  • ใช้พารามิเตอร์ error แบบรวมศูนย์เพื่อจัดระเบียบทั้งข้อความข้อผิดพลาดและตรรกะการจัดการ
  • API ที่เกี่ยวข้องกับข้อผิดพลาดแบบเดิมหลายตัว (message, invalid_type_error, errorMap) ถูก deprecated

การปรับปรุงสำคัญอื่น ๆ

  • discriminated unions รองรับสคีมาหลากหลายแบบ รวมถึงการซ้อนและการประกอบ
  • .literal() รองรับหลายค่าได้พร้อมกัน
  • การตรวจสอบแบบกำหนดเองอย่าง .refine() ถูกผสานให้ใช้งานได้ตรงไปตรงมามากขึ้น
  • สำหรับการแปลงข้อมูล มี .overwrite() ให้ทำ post-processing ได้โดยไม่เปลี่ยน transform type

ความสามารถในการขยายของไลบรารีและ core ใหม่

  • แยกความสามารถหลักออกเป็นซับแพ็กเกจ zod/v4/core ช่วยให้ผสานรวมและต่อยอดกับไลบรารีหรือแพลตฟอร์มต่าง ๆ ได้
  • มีเอกสารคู่มือและตัวอย่างการขยายสำหรับผู้สร้างไลบรารี

สรุป

  • Zod 4 กลายเป็นไลบรารีตรวจสอบข้อมูลที่ยกระดับอย่างมากทั้งในด้านtype safety, ประสิทธิภาพ, ความสามารถในการขยาย และประสบการณ์นักพัฒนา
  • มีการประกาศล่วงหน้าถึงโพสต์ด้านการออกแบบและอัปเดตเพิ่มเติมในอนาคต
  • มีการเตรียมการรองรับอย่างกว้างขวางสำหรับทั้งผู้ใช้เดิมและผู้สร้างไลบรารี

ขอให้สนุกกับการ parse
— Colin McDonnell @colinhacks

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-05-20
ความคิดเห็นบน Hacker News

  • ผู้เขียนขอความคิดเห็นจากทุกคนและอธิบายแนวทางการจัดการเวอร์ชันไว้อย่างละเอียด โดยเน้นว่า npm ไม่เหมาะกับการจัดการกรณีแบบที่ Zod เจอ อีกทั้งยังมีไลบรารีจำนวนมากที่ import อินเทอร์เฟซ/คลาสของ Zod ไปใช้โดยตรง หาก Zod เปลี่ยนเมเจอร์เวอร์ชัน ไลบรารีเหล่านี้ก็จะต้องปรับตามพร้อมกันทั้งหมด และอาจเกิดปัญหาเวอร์ชันกระจัดกระจายได้ จึงใช้แนวทางคล้าย Go คือเมื่อมี breaking change ก็เพิ่ม subpath ใหม่ ในสภาพแวดล้อม TypeScript สามารถรองรับทั้ง "zod/v3" และ "zod/v4" พร้อมกันได้ด้วย zod@^3.25.0 เดียว และเปิดเส้นทางอัปเกรดแบบค่อยเป็นค่อยไปให้ผู้ใช้ปลายทาง

    • ขอบคุณสำหรับการมีส่วนร่วมกับ Zod และตั้งตารอการปรับปรุงประสิทธิภาพของ tsc กับ discriminated unions เป็นพิเศษ เข้าใจแนวทางการจัดการเวอร์ชันดี แต่ก็เสนอว่าการมีแพ็กเกจ 4.0.0 แบบเดี่ยวสำหรับผู้ใช้อย่างตนที่ไม่กังวลเรื่อง dependency ชนกันก็น่าจะดี เพราะการต้องเปลี่ยน import เป็น "zod/v4" อาจเพิ่มความรกในโค้ดและสร้างความยุ่งยากเพิ่ม เช่นชนกับ auto import ของ IDE อย่างไรก็ตาม โดยรวมยังมองว่าเป็นการอัปเกรดที่มีอนาคตมากและขอขอบคุณ

    • กำลังอ่านบทความบนมือถือ ถ้าพลาดไปก็ขออภัย อยากถามว่าปัญหาน่ารำคาญที่สุดเกี่ยวกับ .optional() ได้ถูกรวมอยู่ใน 9/10 top issues ที่แก้รอบนี้หรือไม่ บอกว่าถึงจะไม่สะดวกก็ยังใช้ Zod ต่อเพราะมันยอดเยี่ยมมาก และขอบคุณสำหรับไลบรารีที่ยอดเยี่ยม

    • ขอบคุณที่ทำให้สามารถลบโค้ดแฮ็กแบบทำมือจำนวนมากออกได้ใน Zod เวอร์ชันใหม่ ผู้แสดงความคิดเห็นใช้ zod-key-parser เพื่อลด typo โดยตรงอยู่ จึงสงสัยว่าทำไมความสามารถแบบนี้ยังไม่อยู่ในไลบรารีหลัก มองว่าอยู่นอกขอบเขต หรือยังไม่ได้ทำ พร้อมแชร์ประเด็นถกเถียงที่เกี่ยวข้อง

    • เน้นว่าหลายครั้งวิธีที่ลดความเจ็บปวดระยะสั้นได้มากที่สุดก็คือทางเลือกที่ดีที่สุด พร้อมยกตัวอย่างความโกลาหลของการย้ายจาก Python 2 ไป 3

    • แชร์ประสบการณ์ว่าเคยลำบากมากกับการใช้ recursive types ร่วมกับ discriminated union ไปพร้อมกัน เช่นกรณีฝัง XML ไว้ใน JSON และหวังว่าการอัปเดตครั้งนี้จะทำให้สถานการณ์ดีขึ้นมาก

  • มีความกังขากับ import แบบ zod/v4-mini และคาดว่าอาจกลับทำให้ขนาดบันเดิลใหญ่ขึ้น ในเมื่อเอกสารทางการบอกว่า "zod/v4 แนะนำสำหรับกรณีส่วนใหญ่" นักพัฒนาแอปก็คงใช้ zod/v4 แต่ถ้าผู้เขียนไลบรารีเพิ่ม zod/v4-mini เพื่อประหยัด bundle size ก็อาจทำให้ทั้งคู่ถูกรวมเข้าบันเดิลและเกิดความซ้ำซ้อน ถ้า zod/v4 เป็น wrapper ของ zod/v4-mini จะช่วยลดปัญหานี้ได้หรือไม่

  • เพื่อให้ย้ายไป Zod 4 ได้ง่ายขึ้น จึงมีการนำโครงสร้างที่ให้ทั้ง v3 และ v4 อยู่ร่วมกันใน zod@3.25 มาใช้ และมีเสียงวิจารณ์ว่าโครงสร้างนี้เกิดจากข้อจำกัดของการจัดการ dependency ใน npm จนต้องทำให้ v4 ดูเหมือนเป็น v3 พร้อมชี้ว่าระบบ peer dependencies ของ npm ยังไม่มีประสิทธิภาพ

    • ผู้เขียนอธิบายซ้ำถึงกลยุทธ์จัดการเวอร์ชันแบบเพิ่ม subpath ตามแนว Golang ว่าแม้จะนำมาใช้กับ ecosystem ของ Zod บน npm ได้ยาก แต่ข้อดีคือรองรับทั้ง v3 และ v4 พร้อมกันและเปิดทางให้ย้ายแบบค่อยเป็นค่อยไป

    • ไม่ค่อยเห็นด้วยกับความเห็นก่อนหน้าที่บอกว่าเพราะ peer dependencies พังจึงต้องปลอม v4 เป็น v3 โดยย้ำว่านี่เป็นวิธีเพื่อรองรับ gradual migration สามารถค่อย ๆ เปลี่ยนเป็น 'zod/v4' ทีละส่วนแล้วค่อยอัปเกรดเป็น v4 เต็มตัว

    • หลายคนตำหนิเรื่องนี้ แต่จริง ๆ แล้วไม่ใช่ข้อจำกัดเชิงแก่นของ npm เท่าไรนัก เป็นการตัดสินใจเชิงปฏิบัติเพื่อให้ไลบรารีที่มีการเปลี่ยนแปลงใหญ่สามารถถูกเปลี่ยนผ่านแบบค่อยเป็นค่อยไปได้

    • อาจเป็นเพราะใช้ npm มานานจนมีอคติ แต่ก็สงสัยว่ามีวิธีที่ดีกว่านี้หรือไม่สำหรับการรองรับจาก v3 ไป v4 แบบค่อยเป็นค่อยไป แทนที่จะย้ายรวดเดียวครั้งใหญ่

    • บอกว่าเคยได้ประโยชน์จาก Zod 4 beta มากแล้ว แต่ในโค้ดเบสขนาดใหญ่กลับอัปเกรดจริงไม่ได้เพราะตั้งค่า module resolution ยาก จึงหวังว่าจะมีการออกเป็นเมเจอร์เวอร์ชันล้วน ๆ โดยไม่มีเลเยอร์ legacy ด้วย พร้อมแชร์คำอธิบายของผู้เขียนเรื่องการป้องกัน "version avalanche" แต่ก็ยังคิดว่าการรองรับ v3 ควบคู่กันช่วยลดแรงกระแทกได้

  • ถามว่าในกรณีซับซ้อน เช่น type ที่เซิร์ฟเวอร์ส่งกลับต่างกันไปตามแต่ละ endpoint หรือบางฟิลด์อาจเป็น null ได้เหมือนกรณีผู้ใช้นิรนาม ควรจัดการ response ของเซิร์ฟเวอร์ด้วย type model แบบไหน เพราะพอแยกเป็นหลายฟังก์ชันอย่าง normalizeUser/normalizePost ก็เริ่มดูแลยากขึ้น และอยากฟังประสบการณ์ว่าทำกันอย่างไรในงานจริง

    • มีผู้เสนอวิธีแก้ด้วย discriminated union โดยอธิบายให้กำหนดส่วน schema ที่ใช้ร่วมกันเป็น object แล้วค่อยขยายตามแต่ละสถานการณ์ แม้กรณีที่หลากหลายมากจะซับซ้อนอยู่ดี แต่อย่างน้อย schema validator ก็ช่วยให้ยังรักษาความเป็นระบบได้

    • ตามอุดมคติแล้วควรกำหนดโครงสร้าง type ของ User จากแหล่งเดียว เช่นในรูปแบบ discriminated union ถ้าสมมติว่าใช้ Python backend ก็เสนอแนวทางใช้ Pydantic model หลายแบบร่วมกับ union แล้วสร้าง type ฝั่ง TypeScript client ผ่าน OpenAPI/GraphQL code generation

    • ถ้ารู้ตัวอย่างการใช้งานจริงจะตอบได้ดีกว่านี้ แต่ก็อธิบายว่าหากใส่ discriminator property ให้ union type เช่น "user_type" ก็จะเข้าถึงฟิลด์เฉพาะแต่ละแบบได้ง่ายขึ้น เพราะ type system จะรู้จักพร็อพเพอร์ตีที่เหมาะกับแต่ละกรณี

    • แนะนำตรง ๆ ว่าเซิร์ฟเวอร์ควรเป็นฝ่าย export type ออกมาเอง การให้ฝั่ง client มาเขียน type แยกใหม่ทีละตัวไม่มีประสิทธิภาพ โดยใน Python backend สามารถใช้ Pydantic สร้าง OpenAPI spec อัตโนมัติแล้ว generate type ให้ TypeScript client ได้

    • เอ่ยว่า GraphQL ถูกออกแบบมาพอดีกับเคสแบบนี้ และไลบรารี GraphQL สำหรับ TypeScript สามารถอนุมานรูปแบบผลลัพธ์ของ query ให้โดยอัตโนมัติ รวมถึงสร้าง response type ที่เปลี่ยนไปตาม field ที่เลือกได้

  • พูดถึงว่าแม้ Zod 4 จะดีขึ้นมาก แต่ ArkType ก็ยังเร็วกว่าแบบทิ้งห่าง ไลบรารีที่มีอยู่เดิมมักมีข้อจำกัดด้านประสิทธิภาพเพราะต้องรักษา backward compatibility และคงไวยากรณ์เดิมไว้ และจากการประเมินโปรเจกต์ของตนเองจึงเลือก ArkType เพราะทั้งประสิทธิภาพและประสบการณ์ใช้งานกับ TypeScript

    • เห็นตัวเลขความเร็วของ ArkType แล้ว แต่อยากรู้ว่าความเร็วนั้นส่งผลต่อการใช้งานจริงอย่างไร เพราะในกรณีทั่วไปอย่างการตรวจฟอร์มก็ดูไม่น่ามีผลมากนัก จึงถามว่าใช้ในจุดที่ไวต่อประสิทธิภาพอย่างการตรวจ input ของ API ความเร็วสูงหรือไม่

    • แม้ ArkType จะไม่ถูกรวมไว้ในการวิจัย แต่ก็กำลังมองหาเครื่องมือที่คำนึงถึงประสบการณ์ใช้งานกับ TypeScript เช่นกัน ถึงอย่างนั้นก็ยังไม่มีแผนย้ายออกจาก Zod

    • บอกว่าประสบการณ์ใช้งาน ArkType ค่อนข้างยากมาก ขณะที่ Zod ใช้ง่ายกว่า จึงชอบ Zod มากกว่า

    • ถามว่ามีเหตุผลพิเศษอะไรที่เลือก ArkType แทน TypeBox

  • ร่วมแสดงความยินดีกับทีม Zod สำหรับรีลีสใหม่ แต่เมื่อเห็นจำนวน breaking changes ที่ถาโถมอยู่ใน migration guide ก็อดกังวลไม่ได้ว่าโปรเจกต์ขนาดใหญ่ที่พึ่งพา Zod มากจะรับภาระหนักและดูแลยาก พร้อมสะท้อนจากประสบการณ์ดูแลโปรเจกต์ frontend เก่าว่าไลบรารีต่าง ๆ เปลี่ยนกันใหญ่และเอกสารก็มักไม่พอ จนรู้สึกเสียดายทิศทางการพัฒนาของโลก JS ปัจจุบัน

    • บอกว่ากำลังดูแลแอป Next.js ขนาดใหญ่หลายตัว และในปีที่ผ่านมาเจอการเปลี่ยนแปลงใหญ่และยากมากทั้ง Next.js 14→15, Next.js pages→app router, React 18→19, Eslint 8→9, Tailwind 3→4 จนเหนื่อยมาก ถึงขั้นคิดว่าน่าจะสร้างด้วย Django ไปเลย โดยเฉพาะการย้าย Tailwind 3→4 ที่ย้อนมองแล้วกลับเจ็บปวดที่สุดอย่างคาดไม่ถึง

    • มีการอธิบายว่ากลยุทธ์ออก "mini" edition ควบคู่กันถูกนำมาใช้เพื่อลดปัญหานี้ ช่วยให้ค่อย ๆ เปลี่ยนผ่านได้ง่ายขึ้น และในแง่ความเหมาะสมกับ tree-shaking การมี "mini" ก็จำเป็นเพื่อรับมือคู่แข่งทางเลือกอื่น

    • เสนอว่าสามารถใช้เครื่องมืออย่าง LLM เพื่อช่วยย้ายเวอร์ชันได้ไม่ยาก

  • กล่าวถึงว่า Zod นั้นเหนือกว่าทางเลือกอื่นเดิม ๆ มาก แต่ในโลกเว็บการต้องอธิบายโครงสร้างข้อมูลเดียวกันซ้ำหลายแบบยังเป็นเรื่องจริง ทั้ง validation ฝั่ง JS, สเปก API ผ่าน Swagger, การกำหนดแยกฝั่งเซิร์ฟเวอร์และไคลเอนต์ ล้วนซ้ำซ้อนและน่ารำคาญมาก

    • เสียดายที่ TypeScript ยืนกรานจะเป็นเครื่องมือสำหรับ static checking อย่างเดียว ไม่ได้ต้องการ runtime checks เพิ่ม แต่ก็หวังให้เอาข้อมูล type ของคลาส/ฟังก์ชัน/object ออกไปใช้ภายนอกได้ง่ายกว่านี้ ทุกวันนี้หลายเครื่องมือต้องนิยาม model และ builder ของตัวเอง จึงหลีกเลี่ยงความซ้ำซ้อนไม่พ้น แม้จะมีความพยายามสร้างมาตรฐานอย่างโครงการ Standard Schema ที่ดูเริ่มจะเชื่อมกับไลบรารี validation หลัก ๆ ได้ แต่การขยายไปยัง API spec และ ORM ยังอยู่ในช่วงเริ่มต้น

    • แก่นของเครื่องมือแบบนี้คือการนิยามครั้งเดียวแล้วกระจาย type safety ไปทั่วทั้งแอปได้ โดยสามารถใช้ Zod schema เป็นเหมือนแหล่งความจริงหนึ่งเดียวได้

    • เสริมว่าคนที่ไม่ชอบความซับซ้อนแบบนี้จำนวนมาก พอมีคนเสนอให้รวมทุกอย่างไว้ที่ TypeScript อย่างเดียวรวมถึง Zod กลับมักรู้สึกต่อต้าน

    • ทุก API และระบบล้วนเปลี่ยนแปลงและทดลองอยู่ตลอด เวลาเลเยอร์ความซับซ้อนเพิ่มขึ้นมากก็เป็นข้อเสีย แต่ในสถานการณ์ที่ "ขอแค่งานในโปรเจกต์เดินได้ก็พอ" สุดท้ายมันก็มักสร้างงานเพิ่มให้เราอยู่ดี

    • โดยรวมแล้วอาจใช้ end-to-end type safety อย่าง trpc ได้ แต่ก็ต้องแลกกับการใช้ TypeScript ทั้ง frontend และ backend และยังมีข้อจำกัดเชิงปฏิบัติเมื่อมีแพลตฟอร์มนอกเว็บอย่าง mobile เข้ามาเกี่ยวข้อง

  • บอกว่าไม่ใช่ผู้เชี่ยวชาญ แต่คิดว่า JSON-Schema ซึ่งยึด schema เป็นศูนย์กลางอาจเป็นตัวเลือกที่ดี เพราะสามารถมี validator ในภาษาอื่นนอกจาก TypeScript ได้ พร้อมยกตัวอย่างไลบรารีอย่าง ajv.js.org และถามเปรียบเทียบกับ Zod

    • มีคำตอบว่า Zod ไม่ได้ตรวจได้แค่ข้อมูลรูปแบบ JSON แต่ตรวจ JS object ทั้งหมดได้ด้วย เช่นวันที่หรือ class instance ซึ่งไม่สามารถแทนเป็น JSON ได้ และยังใช้ในกระบวนการแปลงจาก JSON ได้ด้วย จึงเขียน schema แบบอิง string แล้วตรวจพร้อมแปลง เช่นแปลง ISO date string ให้เป็น Date object ได้

    • อธิบายว่า Zod 4 รองรับการแปลง Zod schema เป็น JSON-Schema แล้ว จากเดิมที่ต้องพึ่งไลบรารีภายนอก และจุดต่างสำคัญของ Zod คือความสามารถอย่าง preprocess/refine ที่เปิดให้ใส่ callback ก่อนตรวจได้ เช่นเปลี่ยน MM/DD/YYYY เป็น DD/MM/YYYY ก่อนค่อย validate ซึ่ง JSON-Schema ทำแบบนี้ไม่ได้

    • บอกว่า JSON-Schema ก็เป็นตัวเลือกที่ดี และถ้าจะใช้แนวนี้ TypeBox เหมาะกับการสร้าง schema สามารถใช้ avj ได้หรือจะใช้ระบบ validation ของตัวเองก็ได้ ระบบของตัวเองจะเร็วกว่าแต่รองรับเฉพาะ synchronous ส่วน avj รองรับ asynchronous validation ด้วย จึงได้เปรียบเมื่อจำเป็นต้องตรวจแบบลึก

    • หากต้องใช้ข้ามหลายภาษา JSON-Schema น่าจะเป็นทางเลือกที่เป็นสากลที่สุด และถ้าห่อด้วย OpenAPI ก็ยังสร้างเอกสาร API อัตโนมัติได้ด้วย

  • เพิ่งเริ่มนำ Zod มาใช้กับโปรเจกต์ใหม่ และดีใจที่จังหวะของรีลีสนี้ลงตัวพอดี เพราะถ้าเป็นไปตามแผนเดิมคงต้องเปลี่ยนอะไรเยอะมากเพื่อย้ายไป v4 แต่ครั้งนี้จังหวะเหมาะมาก

  • มีคนบอกว่าประหลาดใจที่ความเห็นเชิงลบมีมากกว่าที่คิด ตอนทดสอบ v4 รุ่นแรกก็ชอบ API ใหม่ แต่กังวลเรื่องเส้นทาง migration ถึงขั้นเคยคิดว่าจะออกเป็นชื่อแพ็กเกจใหม่แยกไปเลย ทว่าหลังเห็นวิธีที่ผู้เขียนทำจริงก็ยกย่องว่าแก้ปัญหาได้ยอดเยี่ยมมาก ทำให้ไม่ต้องรอให้ dependency ต่าง ๆ อัปเดตก่อนก็รับ v4 มาใช้ได้ทันที

    • อีกคนเห็นด้วยว่าในงานอย่าง validation ไม่มีทางย้ายทั้งหมดรวดเดียวได้อยู่แล้ว วิธีปัจจุบันจึงเป็นทางเลือกที่เหมาะกับโลกจริงที่สุด