#1 Hãy nghĩ theo {tập hợp (Set)}
#2 Hiểu về kiểu đã khai báo và kiểu đã được thu hẹp (narrowed)
#3 Dùng discriminated union thay cho trường tùy chọn
#4 Dùng type predicate để tránh type assertion
#5 Kiểm soát sự phân phối của union type
#6 Kiểm tra triệt để để phát hiện các trường hợp chưa được xử lý ở thời điểm biên dịch
#7 Dùng type thay vì interface
#8 Trong những tình huống phù hợp, hãy dùng tuple thay vì mảng
#9 Kiểm soát để kiểu được suy luận mang tính tổng quát hoặc cụ thể
#10 Dùng infer để tạo thêm tham số kiểu generic
#11 Phát huy sự sáng tạo với thao tác trên kiểu để giữ mã DRY
Kết luận
6 bình luận
Có vẻ mục số 7 được viết từ góc nhìn của React.
Tôi thì thích
interfacehơntype. Đây cũng là cú pháp có trong các ngôn ngữ khác nữa.Tôi cũng vậy. Tôi nhớ trước đây trong TypeScript Handbook cũng có lời khuyên rằng nên ưu tiên dùng interface khi có thể.
Nội dung là đây.
Mọi thứ đều ổn, nhưng việc dùng
typethay vìinterfaceở mục 7 thì có cần thiết không? Khó mà gọi đó là một mẹo được. Có những trường hợpinterfacecó khả năng biểu đạt tốt hơn, ví dụ:interface Foo {(b: number): A; (): B}Tôi không hẳn là đang bênh vực
type, nhưng tôi không hiểu rõ ví dụ nào có tính biểu đạt tốt hơn. Chẳng phải ví dụ đó cũng có thể được biểu diễn y hệt bằngtypesao?interface Foo {(b: number): A; (): B}
type Foo = {(b: number): A; (): B}
Trong sách Effective TypeScript có một phần tóm tắt nên dùng
typehayinterface, nên tôi xin trích lại.Nếu là một dự án chưa định hình phong cách rõ ràng, thì cần nghĩ xem về sau có khả năng cần mở rộng hay không. Nếu bạn phải viết khai báo kiểu cho một API nào đó thì nên dùng
interface. Vì khi API thay đổi, người dùng có thể gộp thêm các trường mới thông quainterface, nên sẽ rất hữu ích. Nhưng việc xảy ra declaration merging với các kiểu chỉ được dùng nội bộ trong dự án là dấu hiệu của thiết kế không tốt. Vì vậy trong trường hợp này nên dùngtype.