Sử dụng các loại cấu trúc nội tuyến và cấu trúc nội tuyến có thể làm tổn thương cơ sở mã TypeScript của bạn

Gần đây, tôi đã thấy một tweet của Jamie Kyle về việc sử dụng cấu trúc hủy, tham số mặc định và các loại nội tuyến:

Dòng tweet đó và một vài thành phần React mà tôi đã thấy gần đây trong công việc hàng ngày của mình đã truyền cảm hứng cho tôi để viết bài đăng trên blog này. Tôi muốn chỉ cho bạn cách sử dụng các kiểu cấu trúc và nội tuyến có thể làm cho TypeScript của bạn khó đọc hơn!

Định nghĩa hàm TypeScript trông như thế nào?

Trong JavaScript và TypeScript, bạn có thể xác định một hàm bằng cách sử dụng từ khóa function hoặc hàm lambda / arrow. Cả hai cách đều hợp lệ nhưng có sự khác biệt của chúng. Chúng ta hãy xem xét chức năng sendMessage đơn giản. Logic triển khai không liên quan đến chúng tôi.

 // sendMessage function written using `function` keyword function sendMessage(message: string) { // function logic } // same sendMessage written as arrow function const sendMessage = (message: string) => { // function logic };

Khi định nghĩa hàm khá đơn giản, hàm chấp nhận một vài tham số thuộc kiểu khác. Nếu chúng là nguyên thủy như chuỗi hoặc số, mọi thứ đều có thể đọc được.

Giả sử bạn muốn chuyển một số thông tin bổ sung cùng với nội dung tin nhắn của mình vào chức năng sendMessage .

 function sendMessage(message: { content: string; senderId: string; replyTo?: string; }) { // you can assess content using `message.content` here }

Như bạn có thể thấy, TypeScript cho phép bạn viết định nghĩa kiểu nội tuyến cho đối tượng message mà bạn muốn chuyển mà không chỉ định kiểu bằng cách sử dụng từ khóa type hoặc interface .

Hãy thêm Hủy cấu trúc. Khi bạn chuyển một đối tượng message lớn vào hàm của mình, TypeScript cho phép chia nhỏ các đối số đã truyền ra để giảm phần mã soạn sẵn của biến message lặp lại nhiều lần.

 function sendMessage({ content, senderId, replyTo, }: { content: string; senderId: string; replyTo?: string; }) { // you have access to `content` directly }

Tại sao tôi nghĩ đó là một ý tưởng tồi và làm thế nào bạn có thể làm cho nó tốt hơn?

Rốt cuộc thì nó có vẻ là một ý tưởng hay, bạn không cần phải viết message nhiều lần như vậy, phải không? Hóa ra nó không phải là tuyệt vời. Hãy nói về 5 lý do tại sao tôi nghĩ đó là một phản vật chất.

1. Bạn không chắc dữ liệu của mình đến từ đâu

Khi bạn đang đọc nội dung hàm, bạn thấy senderId , bạn phải kiểm tra kỹ để chắc chắn rằng hàm đó đến từ đâu. Nó được truyền dưới dạng đối số hay được tính toán ở đâu đó trong hàm?

2. Thật khó để viết tài liệu

Không có chỗ tự nhiên để viết các bình luận về tài liệu khi tất cả các loại đều chật chội với cấu trúc hủy trong định nghĩa hàm. Bạn có thể viết nhận xét giữa mỗi trường loại, nhưng điều đó làm cho toàn bộ định nghĩa hàm thậm chí còn dài hơn. Nó chủ động không khuyến khích bạn viết một bản tóm tắt nhanh về dữ liệu bạn đang chuyển.

3. Thật khó để chuyển dữ liệu đó về phía trước

Khi dữ liệu của bạn bị hủy, bạn cần phải cấu trúc lại nó thành một đối tượng mới nếu bạn muốn chuyển nó về phía trước. Điều này không khuyến khích tạo các chức năng trợ giúp nhỏ hơn và dựa vào thành phần để xây dựng logic chức năng chính của bạn.

4. Bạn không thể sử dụng lại các loại đối số bên ngoài hàm này

Nếu bạn cần sử dụng lại các đối số hàm của mình trong các hàm trợ giúp khi soạn logic hàm chính, bạn phải nhập lặp lại cùng một nhóm kiểu. Điều này giúp bạn không phải viết các kiểu dễ dàng hơn.

5. Nó chỉ tốn rất nhiều không gian

Hãy đối mặt với nó. Nó chỉ là rất nhiều dòng mã chiếm nhiều không gian màn hình. Và ngoài ra, nó tập trung vào chi tiết triển khai - kiểu bên trong của các đối số mà bạn đang chuyển cho một hàm, mà hầu hết thời gian không liên quan khi bạn đang xem hàm đó.

Chỉ cần tạo một loại cho nó

Giải nén kiểu và đặt nó ngay trên hàm làm cho nó dễ đọc hơn nhiều. Có một nơi để nhận xét tài liệu, bạn có thể sử dụng lại kiểu đó trong một số chức năng trợ giúp khác và thay đổi định nghĩa kiểu ở một nơi nếu cần.

 /** * Message to send using XYZ API */ export type MessageToSend = { /** * Markdown string of the user's message */ content: string; /** * Id of the sender user */ senderId: string; /** * Other message ID if this is a reply */ replyTo?: string; }; function sendMessage(message: MessageToSend) { // function logic } function getUserIdsToNotify(message: MessaageToSend) { // function logic }

Tài nguyên

Tìm danh sách các tài nguyên tôi đã sử dụng khi nghiên cứu bài đăng trên blog này:

• https://www.typescriptlang.org/docs/handbook/variable-decl Tuyên.html#object-dest Structure