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:   https://twitter.com/buildsghost/status/1577030375158607872?s=20&t=0qa78fG7TzsSdxrsM1sCvg?embedable=true  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   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   đơn giản. Logic triển khai không liên quan đến chúng tôi. function sendMessage   // 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   mà bạn muốn chuyển mà không chỉ định kiểu bằng cách sử dụng từ khóa   hoặc   . message type interface  Hãy thêm Hủy cấu trúc. Khi bạn chuyển một đối tượng   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   lặp lại nhiều lần. message message   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   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. message  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   , 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? senderId  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

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Alongside

Twitter

Read My Stories

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Make resilience your competitive advantage

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

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

189 Stories To Learn About Reading Books

240 Stories To Learn About Astounding Stories

581 Stories To Learn About Non Fiction

178 Stories To Learn About Essay

189 Stories To Learn About Reading Books

240 Stories To Learn About Astounding Stories

581 Stories To Learn About Non Fiction

178 Stories To Learn About Essay

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps