Thiết kế thư viện xác thực lược đồ typcript hoàn hảo

Có một số thư viện xác thực cực kỳ phổ biến trong hệ sinh thái Javascript với hàng ngàn ngôi sao trên GitHub.

Khi tôi bắt đầu hành trình tìm kiếm Thư viện xác nhận / xác thực lược đồ lý tưởng, tôi cho rằng phần khó nhất sẽ là xác định tùy chọn Tuyệt vời nhất từ ​​một biển tuyệt vời.

Nhưng khi tôi tìm hiểu sâu hơn về nhiều công cụ được yêu thích trong hệ sinh thái, tôi đã ngạc nhiên rằng không ai trong số họ có thể cung cấp các tính năng và trải nghiệm nhà phát triển mà tôi đang tìm kiếm.

Tôi đang xây dựng API cho ứng dụng chăm sóc sức khỏe với Bản đánh máy. Đương nhiên, tôi muốn phần mềm y tế quan trọng này trở nên vững chắc, vì vậy mục tiêu của tôi là xây dựng một lớp dữ liệu an toàn kiểu đầu cuối hoàn toàn.

Tất cả dữ liệu truyền từ máy khách đến máy chủ VÀ máy chủ đến máy khách phải được xác thực khi chạy. Hơn nữa, cả máy khách và máy chủ đều phải có định nghĩa kiểu tĩnh của tất cả các tải trọng, vì vậy tôi có thể gặp nhiều lỗi hơn trong thời gian biên dịch.

Tôi cũng không ghét bản thân mình, vì vậy tôi không muốn giữ kiểu tĩnh và trình xác nhận kiểu thời gian chạy đồng bộ hóa bằng tay khi mô hình dữ liệu của tôi thay đổi. Điều đó có nghĩa là chúng ta cần một công cụ hỗ trợ 🚀StAtIc TyPe InFeReNcE !! * vuvuzela âm thanh *

Hãy xem xét các tùy chọn của chúng tôi!

Không hỗ trợ suy luận kiểu tĩnh. Boo.

Yup là thư viện xác thực lấy cảm hứng từ Joi của Jquense, được triển khai đầu tiên trong vanilla JS, với các kiểu đánh máy được thêm vào sau.

Yup hỗ trợ suy luận kiểu tĩnh! Nhưng với một cảnh báo nhỏ: các lỗi đánh máy là sai.

Ví dụ, gói yup coi tất cả các thuộc tính đối tượng là tùy chọn theo mặc định.

Tuy nhiên, loại suy ra chỉ ra rằng tất cả các thuộc tính được yêu cầu. 😕

Yup cũng nhập sai loại mảng "bắt buộc".

Cuối cùng, Yup không hỗ trợ rõ ràng các loại kết hợp và giao cắt chung. Đây là một nguồn định kỳ của sự thất vọng đối với cộng đồng Yup.

Những thứ này nghe có vẻ giống như nitpicks. Nhưng loại hình suy luận không thực sự phản ánh loại thực tế của trình xác nhận mà nó xuất phát.

Hơn nữa, không có kế hoạch khắc phục những vấn đề này theo suy luận kiểu của Yup vì những thay đổi đó sẽ tương thích ngược. Xem thêm về nơi này.

Cuối cùng, một thư viện được thiết kế cho Bản mô tả từ dưới lên!

Hãy nhìn, io-ts là thư viện tuyệt vời. Người tạo ra nó, gcanti, đã làm nhiều hơn bất kỳ ai để đưa lập trình chức năng bậc cao thích hợp vào Thư mục với thư viện `fp-ts` của mình.

Nhưng trong tình huống của tôi, và tôi nghĩ nhiều người khác ', io-ts ưu tiên độ tinh khiết của lập trình chức năng với chi phí cho trải nghiệm của nhà phát triển. Độ tinh khiết chức năng là một mục tiêu thiết kế hợp lệ và đáng ngưỡng mộ, nhưng nó làm cho io-ts đặc biệt khó tích hợp vào một cơ sở mã hiện tại với xu hướng hướng đối tượng hoặc hướng thủ tục hơn. Thật khó để tích hợp dần dần io-ts mà không hoàn toàn tái cấu trúc mã của bạn với một hương vị chức năng hơn.

Ví dụ, hãy xem xét cách xác định lược đồ đối tượng với các thuộc tính tùy chọn trong io- ts :

Bạn phải xác định các đạo cụ cần thiết bằng một cuộc gọi đến t.type ({...}) xác định đạo cụ tùy chọn của bạn bằng một cuộc gọi đến t.partial ({...}) và hợp nhất chúng với t.intersection () .

io-ts cũng yêu cầu sử dụng thư viện lập trình chức năng của gcant fp-ts để phân tích kết quả và xử lý lỗi. Từ các tài liệu io-ts đây là ví dụ cơ bản nhất về cách chạy xác thực:

Cách tiếp cận chức năng ở đây là xa lạ đối với các nhà phát triển không quen với nó.

Một lần nữa: fp-ts là tài nguyên tuyệt vời dành cho các nhà phát triển muốn giữ cho cơ sở mã hóa của họ hoạt động nghiêm ngặt. Nhưng tùy thuộc vào fp-ts nhất thiết phải đi kèm với rất nhiều chi phí trí tuệ; một nhà phát triển phải làm quen với các khái niệm lập trình chức năng, danh pháp của fp-ts và đơn vị Either để thực hiện xác nhận lược đồ đơn giản. Nó xa lánh các nhà phát triển không có nền tảng chức năng và nó đưa họ đến các thư viện như Yup, trả về các loại không chính xác.

Vì vậy, theo truyền thống của nhiều lập trình viên nitpicky, tôi đã quyết định xây dựng riêng của mình thư viện từ đầu. Điều gì có thể sai?

Kết quả cuối cùng: https://github.com/vriad/zod.[19459003[[19459002[ZodlàmộtthưviệnxácthựcđượcthiếtkếchotrảinghiệmnhàpháttriểntốiưuĐólàmộtthưviệnkhaibáolượcđồđầutiêncủaKiểuchữvớicáckiểusuyluậnnghiêmngặt(vàchínhxác!)Trảinghiệmnhàpháttriểnđángkinhngạcvàmộtvàitínhnăngsátthủbịthiếutrongcácthưviệnhiệncó

• Sử dụng suy luận chung về Kiểu để suy luận tĩnh các loại lược đồ của bạn
• Loại bỏ sự cần thiết phải giữ các kiểu xác thực tĩnh và trình xác thực thời gian chạy đồng bộ bằng tay
• Có API khai báo có thể tổng hợp giúp dễ dàng xác định chính xác các loại phức tạp

]

Zod cũng được thiết kế với một số nguyên tắc cốt lõi được thiết kế để làm cho tất cả các tuyên bố là không ma thuật và thân thiện với nhà phát triển nhất có thể:

• Các trường được yêu cầu trừ khi được đánh dấu rõ ràng là tùy chọn (giống như Bản mô tả! )
• Các lược đồ là bất biến; các phương thức (tức là .optional () ) trả về một thể hiện mới.
• Các lược đồ Zod hoạt động trên Phân tích, không xác thực! cơ sở!

Để nhảy thẳng tới README, hãy đi tới https://github.com/vriad/zod. Nếu bạn cảm thấy khó chịu, hãy để lại một ngôi sao 🌟🤏👍

Giống như trong io-ts bạn có thể trích xuất loại Bản mô tả của bất kỳ lược đồ nào với z.TypeOf <> .

Chúng tôi sẽ bao gồm các ví dụ về các loại được suy luận trong phần còn lại của tài liệu.

Ngoài ra, bạn có thể xác định rõ ràng một lược đồ mảng không trống, một cái gì đó io -ts không hỗ trợ.

Bao gồm các loại Không thể và Không bắt buộc.

Zod bao gồm phương thức z.union tích hợp để soạn các loại "HOẶC"

Các hiệp hội là cơ sở để xác định các giá trị không thể và giá trị tùy chọn.

Ngoài ra còn có một cách viết tắt để tạo một lược đồ "tùy chọn":

Tương tự, bạn có thể tạo nullable các loại như vậy:

Bạn có thể tạo liên hiệp của bất kỳ hai lược đồ nào.

Giao lộ rất hữu ích để tạo các loại "logic VÀ".

arly hữu ích để xác định "mixins lược đồ" mà bạn có thể áp dụng cho nhiều lược đồ.

Trong các ví dụ ở trên, giá trị trả về của z.intersection là một ví dụ của ZodIntersection một lớp chung bao bọc hai lược đồ được truyền vào dưới dạng đối số.

Nhưng nếu bạn đang cố gắng kết hợp hai lược đồ đối tượng, có một tốc ký:

Lợi ích của việc sử dụng tốc ký này là giá trị được trả về là một lược đồ đối tượng mới ( ZodObject ), thay vì một ví dụ chung ZodIntersection . Bằng cách này, bạn có thể kết nối thành thạo nhiều cuộc gọi .merge :

Chúng khác với các mảng ở chỗ chúng có số lượng phần tử cố định và mỗi phần tử có thể có một loại khác nhau .

Bạn có thể định nghĩa một lược đồ đệ quy trong Zod, nhưng do giới hạn của Bản mô tả, loại của chúng không thể được suy luận tĩnh. Nếu bạn cần một lược đồ Zod đệ quy, bạn sẽ cần xác định định nghĩa kiểu thủ công và cung cấp cho Zod dưới dạng "gợi ý kiểu".

Zod cũng cho phép bạn xác định "lược đồ hàm". Điều này giúp dễ dàng xác thực các đầu vào và đầu ra của một hàm mà không trộn lẫn mã xác thực của bạn và "logic nghiệp vụ".

Bạn có thể tạo một lược đồ hàm với z.feft (args, returnType ) chấp nhận những lập luận này.

• args: ZodTuple Đối số đầu tiên là một tuple (được tạo bằng z.tuple ([...]) và xác định lược đồ của các đối số Hàm. Nếu hàm không chấp nhận đối số, bạn có thể chuyển một tuple trống ( z.tuple ([]) ).
• returnType: ZodType đối số thứ hai là kiểu trả về của hàm. Đây có thể là bất kỳ lược đồ Zod nào.

z.f ghép trả về một "nhà máy chức năng" bậc cao. Mọi "nhà máy" đều có .validate () phương thức chấp nhận một hàm làm đầu vào và trả về một hàm mới. Hàm được trả về sẽ tự động xác nhận cả hai đầu vào và giá trị trả về của nó đối với các lược đồ được cung cấp cho z.f ghép . không hợp lệ, hàm ném.

Điều này cho phép bạn tự tin thực hiện logic nghiệp vụ trong một "hàm được xác thực" mà không phải lo lắng về inva nắp đầu vào hoặc loại trả về, trộn lẫn xác thực và logic nghiệp vụ của bạn hoặc viết các loại trùng lặp cho các chức năng của bạn.

Đây là một ví dụ.

Điều này đặc biệt hữu ích để xác định điểm cuối HTTP hoặc RPC chấp nhận tải trọng phức tạp yêu cầu xác nhận. Hơn nữa, bạn có thể xác định điểm cuối của mình một lần với Zod và chia sẻ mã với cả mã máy khách và mã máy chủ của mình để đạt được an toàn loại đầu cuối.

Tôi nghĩ rằng có rất nhiều chỗ để cải thiện cách chúng tôi xử lý sự phức tạp của mô hình hóa dữ liệu, xác nhận và vận chuyển như các nhà phát triển. Bản in, GraphQL và Prisma là những bước tiến lớn trong tương lai nơi công cụ của chúng tôi có thể đảm bảo tính toàn vẹn dữ liệu. Nhưng vẫn còn một chặng đường dài để đi.

Nếu bạn thích những gì bạn thấy, hãy đến https://github.com/vriad/zod và đập vỡ nút ⭐STAR⭐️