JSON to TypeScript Converter

Tính năng nổi bật

• Suy kiểu cho từng trường từ giá trị mẫu và sinh khai báo TypeScript có từ khóa xuất
• Công tắc chọn giữa khai báo dạng interface và khai báo dạng type
• Ô đặt tên cho khai báo gốc, mặc định là Root
• Công tắc đánh dấu toàn bộ thuộc tính là tùy chọn bằng dấu chấm hỏi
• Tự tách mỗi đối tượng lồng nhau thành một khai báo riêng, tên lấy từ tên khóa viết hoa chữ đầu
• Suy kiểu mảng: mảng đồng nhất thành kiểu phần tử kèm dấu ngoặc vuông, mảng hỗn hợp thành hợp kiểu
• Mảng rỗng được suy thành mảng kiểu chưa biết thay vì đoán bừa
• Có sẵn nút nạp một khối JSON mẫu để bạn thử ngay, và nút sao chép kết quả

Vì sao gõ tay kiểu cho một phản hồi giao diện lập trình lại tốn thời gian

Một phản hồi giao diện lập trình thật thường có ba tới bốn tầng lồng nhau và hàng chục trường. Gõ tay toàn bộ khai báo kiểu cho nó là công việc thuần cơ học, mất nửa tiếng, và trong nửa tiếng đó bạn sẽ gõ sai ít nhất một tên trường. Cái sai đó không lộ ra ngay: trình biên dịch không thể biết máy chủ trả về tên nào, nó chỉ biết những gì bạn khai báo, nên mã vẫn dịch được và lỗi chỉ hiện ra khi chạy dưới dạng một giá trị không xác định. Dán thẳng phản hồi thật vào đây tránh được hoàn toàn nhóm lỗi đó, vì tên trường được lấy nguyên văn từ dữ liệu chứ không qua tay bạn. Đây cũng là lý do nên dán phản hồi thật lấy từ tab mạng của trình duyệt chứ đừng dán ví dụ chép từ tài liệu, vì tài liệu và thực tế không phải lúc nào cũng khớp.

Lợi ích khi sử dụng

• •Tên trường lấy nguyên văn từ dữ liệu nên không còn lỗi gõ sai tên
• •Cấu trúc lồng nhau được tách sẵn thành từng khai báo riêng, dễ tái sử dụng
• •Có ngay khung kiểu để bắt đầu, việc còn lại chỉ là tinh chỉnh chứ không phải viết từ đầu
• •Hai chế độ interface và type để khớp với quy ước sẵn có của dự án
• •Dữ liệu phản hồi không rời khỏi trình duyệt nên dùng được với giao diện lập trình nội bộ

Cách sinh khai báo kiểu từ một phản hồi

1. 1Mở tab mạng trong công cụ dành cho lập trình viên, chép nguyên phần thân phản hồi thật của lời gọi bạn quan tâm.
2. 2Dán vào ô bên trái, đặt tên cho khai báo gốc theo tên tài nguyên chứ đừng để nguyên tên mặc định.
3. 3Chọn interface hay type, và cân nhắc bật chế độ thuộc tính tùy chọn nếu bạn chưa chắc trường nào luôn có mặt.
4. 4Bấm chuyển đổi rồi đọc kết quả từ dưới lên, vì khai báo gốc nằm ở cuối và các khai báo con nằm phía trên.
5. 5Sửa tay ba nhóm: trường có giá trị rỗng, trường tùy chọn, và tên khai báo con bị trùng hoặc chưa đúng quy ước.

Luật suy kiểu mà công cụ áp dụng

Với giá trị nguyên thủy, kiểu được lấy trực tiếp từ kiểu thời gian chạy của giá trị, nên chuỗi thành string, số thành number, đúng sai thành boolean. Giá trị rỗng được suy thành đúng chữ null chứ không ghép thành hợp kiểu với kiểu khác, đây là chỗ bạn gần như luôn phải sửa tay. Với mảng, công cụ duyệt từng phần tử và gom lại tập kiểu tìm được: nếu mọi phần tử cùng kiểu thì kết quả là kiểu đó kèm dấu ngoặc vuông, nếu có nhiều kiểu khác nhau thì kết quả là hợp kiểu đặt trong ngoặc tròn rồi mới thêm dấu ngoặc vuông, còn mảng rỗng thì thành mảng kiểu chưa biết vì không có gì để suy. Với đối tượng lồng, công cụ sinh một khai báo riêng và đặt tên bằng cách viết hoa chữ cái đầu của tên khóa, sau đó trường cha nhận chính tên khai báo đó làm kiểu. Cuối cùng, các khai báo được ghép lại theo thứ tự đảo ngược so với thứ tự tạo, nên khai báo con hiện lên trước và khai báo gốc nằm cuối cùng.

Suy kiểu từ một mẫu dữ liệu là suy đoán, không phải hợp đồng

Đây là giới hạn cơ bản của mọi công cụ loại này, không riêng công cụ ở đây. Kiểu sinh ra mô tả đúng một mẫu dữ liệu bạn vừa dán, chứ không mô tả tất cả những gì máy chủ có thể trả về. Ba trường hợp hay gây rắc rối. Thứ nhất là trường chỉ xuất hiện trong một số bản ghi, ví dụ đơn hàng có mã giảm giá thì mới có trường giảm giá; mẫu của bạn không có nó thì kiểu cũng không có, và về sau ai đó truy cập trường ấy sẽ bị trình biên dịch chặn dù dữ liệu thật vẫn có. Thứ hai là trường có thể nhận giá trị rỗng nhưng trong mẫu lại đang có giá trị, khi đó kiểu sinh ra bỏ mất khả năng rỗng và mã của bạn sẽ vỡ lúc chạy thật. Thứ ba là khi mảng ở tầng gốc, công cụ chỉ đọc phần tử đầu tiên để dựng kiểu, nên nếu các phần tử khác nhau về cấu trúc thì phần khác biệt không được phản ánh. Nếu giao diện lập trình có sẵn đặc tả chính thức, hãy sinh kiểu từ đặc tả đó thay vì suy từ mẫu.

Trường tùy chọn và trường có thể rỗng là hai chuyện khác nhau

Trong TypeScript, đánh dấu một thuộc tính bằng dấu chấm hỏi nghĩa là thuộc tính đó có thể không tồn tại trong đối tượng. Còn khai báo kiểu là hợp kiểu với null nghĩa là thuộc tính luôn tồn tại nhưng giá trị có thể rỗng. Hai chuyện này dẫn tới hai cách xử lý khác nhau trong mã và không thay thế cho nhau được. Công tắc thuộc tính tùy chọn trong công cụ áp dấu chấm hỏi cho toàn bộ thuộc tính một cách đồng loạt, tiện khi bạn muốn nhanh nhưng không đúng về mặt mô hình, vì trường mã định danh của một tài nguyên gần như chắc chắn luôn có mặt. Cách làm đúng là bật công tắc để có khung, rồi bỏ dấu chấm hỏi ở những trường bạn biết chắc luôn có. Với trường có thể rỗng, hãy sửa từ chữ null đơn độc thành hợp kiểu của kiểu thật với null, và nhớ bật chế độ kiểm tra giá trị rỗng nghiêm ngặt trong cấu hình dự án, vì không bật thì khai báo đó cũng không có tác dụng bảo vệ gì.

Tên khai báo con được đặt từ tên khóa, và điều đó gây ra hai vấn đề

Vấn đề thứ nhất là xung đột tên. Nếu trong dữ liệu của bạn có hai khóa cùng tên ở hai nhánh khác nhau, chẳng hạn cả người mua lẫn người bán đều có khóa address với cấu trúc khác nhau, cả hai đều sinh ra khai báo cùng tên và khai báo tạo sau ghi đè khai báo tạo trước, khiến một trong hai nhánh bị gán sai kiểu. Hãy đếm số khai báo trong kết quả và đối chiếu với số đối tượng lồng trong dữ liệu để phát hiện. Vấn đề thứ hai là quy ước đặt tên: công cụ chỉ viết hoa chữ cái đầu, nên khóa viết theo kiểu gạch dưới sẽ cho ra một tên nửa vời, còn khóa số nhiều dùng cho một mảng sẽ sinh ra khai báo mang tên số nhiều dù nó mô tả một phần tử. Ngoài ra, tên khóa trong JSON không phải lúc nào cũng là định danh hợp lệ của TypeScript: khóa có dấu cách, dấu gạch nối hay bắt đầu bằng chữ số sẽ khiến mã sinh ra sai cú pháp, và bạn phải bọc chúng trong dấu nháy khi khai báo.

Có kiểu rồi thì vẫn cần kiểm tra dữ liệu lúc chạy

Đây là điều dễ quên nhất. Kiểu trong TypeScript chỉ tồn tại ở thời điểm biên dịch và biến mất hoàn toàn trong mã chạy thật; khai báo rằng phản hồi có kiểu này không hề bắt máy chủ trả về đúng như vậy. Nếu bạn ép kiểu cho kết quả trả về của một lời gọi mạng, bạn chỉ đang nói với trình biên dịch hãy tin tôi, và khi máy chủ đổi tên trường hay trả về giá trị rỗng ngoài dự kiến thì lỗi vẫn xảy ra, chỉ khác là nó xảy ra ở chỗ xa hơn và khó lần ra hơn. Cách làm chắc chắn là mô tả cấu trúc bằng một lược đồ kiểm định chạy được lúc thực thi, kiểm tra dữ liệu ngay tại ranh giới với bên ngoài, rồi để thư viện tự suy ra kiểu tĩnh từ chính lược đồ đó; như vậy chỉ có một nguồn định nghĩa duy nhất. Với dự án lớn, hướng bền vững hơn nữa là sinh cả kiểu lẫn hàm gọi từ đặc tả chính thức của giao diện lập trình, để mỗi lần đặc tả đổi thì mã kiểu cũng đổi theo và trình biên dịch chỉ ra ngay chỗ vỡ.

Câu hỏi thường gặp (FAQ)

Từ khóa liên quan

• json to typescript
• sinh interface từ json
• chuyển json sang typescript
• typescript interface là gì
• interface và type khác nhau
• kiểu dữ liệu cho response api
• strictNullChecks typescript
• thuộc tính tùy chọn typescript
• union type trong typescript
• kiểm tra dữ liệu lúc chạy
• zod schema validation
• sinh kiểu từ openapi
• khai báo kiểu cho fetch
• typescript array type
• đặt tên interface chuẩn
• json parse typescript
• type safety khi gọi api
• công cụ typescript online
• generate types from json
• công cụ cho lập trình viên miễn phí