Tại Sao Nên Thay Thế any Bằng unknown Trong TypeScript

Giới thiệu

Trong quá trình phát triển phần mềm với TypeScript, có một vấn đề phổ biến mà nhiều lập trình viên thường gặp phải: việc sử dụng any như một giải pháp tạm thời cho các kiểu dữ liệu khó khăn. Tuy nhiên, việc làm này có thể dẫn đến nhiều rắc rối trong tương lai. Hãy cùng khám phá lý do tại sao unknown là lựa chọn an toàn và thông minh hơn, giúp bạn tránh được những cơn đau đầu không cần thiết.

Nguy cơ từ việc sử dụng any

Một lời hứa "Tin tôi đi" với Compiler 🙈

Sử dụng any giống như bạn đang yêu cầu compiler của TypeScript bỏ qua kiểm tra kiểu. Khi bạn định nghĩa một biến là any, bạn đang nói: "Hãy tắt tất cả các kiểm tra kiểu cho biến này. Tôi biết mình đang làm gì."

Điều này có nghĩa là bạn có thể làm bất cứ điều gì với biến đó mà không bị TypeScript ngăn cản cho đến khi xảy ra lỗi tại thời điểm chạy.

Ví dụ điển hình:

let myData: any;

myData = "Đây là một chuỗi";

// TypeScript không vấn đề gì với dòng này...
// nhưng nó sẽ làm ứng dụng của bạn bị sập!
console.log(myData.toFixed(2)); 
// 😱 Lỗi TypeError: myData.toFixed không phải là một hàm

// Compiler cũng không có vấn đề gì với những lỗi hiển nhiên này:
myData.someMethodThatDoesNotExist();
const result = myData * 10;

Mỗi lần bạn sử dụng any, bạn đang tạo ra một lỗ hổng trong tính an toàn kiểu mà chúng ta dựa vào TypeScript. Điều này biến các lỗi có thể phát hiện tại thời điểm biên dịch thành những lỗi khó chịu tại thời điểm chạy, và làm cho việc refactor trở thành một trò chơi đoán mò nguy hiểm.

Giải pháp: unknown đến cứu giúp! 🦸

Đây là lúc unknown xuất hiện và cứu rỗi bạn. Giống như any, bạn có thể gán bất kỳ giá trị nào - một chuỗi, một số, một đối tượng - cho một biến có kiểu unknown.

Vậy điều gì làm nên sự khác biệt lớn? Điểm khác biệt quan trọng là unknown sẽ không cho phép bạn làm bất cứ điều gì với giá trị cho đến khi bạn chứng minh được nó là gì. Bạn buộc phải xử lý sự không chắc chắn trước khi có thể sử dụng nó.

Hãy nghĩ về một biến unknown như một chiếc hộp khóa. Bạn biết rằng có gì đó bên trong, nhưng bạn phải kiểm tra xem đó là gì trước khi có thể sử dụng một cách an toàn.

Hãy sửa ví dụ trước đó với unknown:

let myData: unknown;

myData = "Đây là một chuỗi";

// Compiler ngay lập tức ngăn bạn. Đây là điều tốt!
// ❌ Lỗi: Đối tượng có kiểu 'unknown'.
console.log(myData.toFixed(2));

// Đây là cách bạn làm việc với nó một cách an toàn:
if (typeof myData === 'number') {
  // OK, bên trong khối này, TypeScript giờ đây biết myData là một số.
  console.log(myData.toFixed(2));
} else if (typeof myData === 'string') {
  // Và ở đây, nó biết đó là một chuỗi.
  console.log(myData.toUpperCase());
}

Bằng cách chuyển sang unknown, bạn được khuyến khích viết mã an toàn hơn, mạnh mẽ hơn. Nó buộc bạn phải xử lý các trường hợp khác nhau một cách rõ ràng với các kiểu bảo vệ như typeof hoặc instanceof, dẫn đến một ứng dụng ổn định hơn.

Sổ tay của người xem xét mã

Việc phát hiện any trong quá trình xem xét mã là một cơ hội tuyệt vời để dạy bảo. Dưới đây là cách tiếp cận một cách xây dựng:

1. Hiểu "Tại sao": Lập trình viên có thể chỉ đang cố gắng giải quyết vấn đề kiểu một cách nhanh chóng. Không cần phải chỉ trích.
2. Giải thích Nguy cơ: Ngắn gọn đề cập rằng any bỏ qua tính an toàn kiểu và có thể che giấu các lỗi chỉ xuất hiện tại thời điểm chạy.
3. Đề xuất Giải pháp: Gợi ý thay thế any bằng unknown. Sau đó, hướng dẫn họ thêm kiểm tra kiểu cần thiết (ví dụ: một khối if) để truy cập biến một cách an toàn. Điều này không chỉ giải quyết rủi ro ngay lập tức mà còn làm rõ ý định của mã cho mọi người.

Kết luận

Mặc dù any là một lối tắt hấp dẫn, nhưng nó làm suy yếu lý do chính mà chúng ta sử dụng TypeScript. unknown mang lại cho bạn sự linh hoạt tương tự để chấp nhận bất kỳ kiểu giá trị nào nhưng không hy sinh tính an toàn kiểu.

Bằng cách khuyến khích sử dụng unknown trong các mã xem xét của chúng ta, chúng ta đang xây dựng thói quen viết mã có chủ đích, có thể dự đoán và mạnh mẽ hơn. Nó buộc chúng ta phải đối mặt với sự không chắc chắn một cách trực tiếp, dẫn đến ít lỗi hơn và một mã nguồn khỏe mạnh hơn. Vì vậy, lần sau khi bạn bị cám dỗ sử dụng any, hãy dừng lại và chọn unknown thay vào đó. Bản thân bạn trong tương lai - và các đồng đội của bạn - sẽ biết ơn.

Các thực hành tốt nhất

• Luôn sử dụng unknown thay vì any khi có thể.
• Viết các kiểm tra kiểu rõ ràng và cụ thể để đảm bảo tính an toàn.

Những cạm bẫy phổ biến

• Sử dụng --no-verify trong quá trình kiểm tra mã, dẫn đến việc bỏ qua các cảnh báo.

Mẹo hiệu suất

• Tránh lạm dụng any để không làm giảm hiệu suất của ứng dụng.

Giải quyết vấn đề

• Nếu gặp lỗi tại thời điểm chạy liên quan đến kiểu dữ liệu, hãy xem xét lại cách bạn đang sử dụng unknown và đảm bảo rằng bạn đã thực hiện các kiểm tra kiểu cần thiết.

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

1. unknown có an toàn hơn any không?
   • Có, vì unknown yêu cầu bạn phải kiểm tra kiểu trước khi sử dụng giá trị.
2. Khi nào nên sử dụng any?
   • Nên hạn chế sử dụng any và chỉ sử dụng trong những tình huống thực sự cần thiết khi không có lựa chọn nào khác.

So sánh giữa any và unknown