[ad_1]
JavaScript có thể sớm có cú pháp kiểu riêng nếu một đề xuất do Microsoft và các nhà phát triển khác đệ trình vào đầu năm nay trở thành một phần của tiêu chuẩn ECMAScript. Sáng kiến có kế hoạch thêm hỗ trợ “loại dưới dạng nhận xét” vào ngôn ngữ JavaScript, cho phép các nhà phát triển chú thích mã với thông tin loại sẽ được các thành phần hệ sinh thái khác sử dụng.
Cú pháp
Cú pháp được đề xuất trông giống như sau:
function sayAge(name: string, age: number) { console.log(`${name} is ${age} years old.`); } sayAge("JavaScript", 26);
Nó sẽ quen thuộc với bất kỳ ai trước đây đã sử dụng TypeScript, tập hợp JavaScript được đánh máy của Microsoft. TypeScript đã được áp dụng rộng rãi trong toàn ngành; đề xuất mới này nhằm mục đích mang lại một số lợi ích của nó cho thế giới JavaScript rộng lớn hơn.
Đề xuất không phải là gì?
Nếu nó được chấp thuận, đề xuất này sẽ cho phép bạn viết JavaScript hoàn toàn hợp lệ với các loại chú thích được hiển thị ở trên. Nó sẽ được chấp nhận bởi các thời gian chạy JavaScript như trình duyệt web, Node.js và Deno tuân theo tiêu chuẩn ES.
Tuy nhiên, đề xuất không thực sự mở rộng ngôn ngữ JavaScript. Chú thích kiểu của bạn sẽ chính xác là: siêu dữ liệu trơ không ảnh hưởng đến trình biên dịch JavaScript hoặc thời gian chạy mã của bạn. Một lệnh gọi hàm chẳng hạn như sau sẽ hoạt động trong thời gian chạy:
function sayAge(name: string, age: number) { console.log(`${name} is ${age} years old.`); } // "age" is a string when it should be a number, but this is still allowed sayAge("JavaScript", "twenty");
Ý tưởng là cung cấp một cú pháp kiểu mới được hỗ trợ chính thức nhưng hoàn toàn bị các công cụ bỏ qua. Thay đổi duy nhất cho việc triển khai liên quan đến việc nhận dạng và loại bỏ các chú thích kiểu ở bất cứ nơi nào chúng được sử dụng.
Đề xuất sẽ tìm cách thiết lập hỗ trợ chú thích các loại tham số, biến và thuộc tính lớp. Nó cũng sẽ xem xét việc thêm một interface từ khóa, toán tử khẳng định như ! và asvà một ? bổ ngữ để đánh dấu các loại là tùy chọn. Mục đích là để tất cả các phần tử này phản chiếu TypeScript; như với bất kỳ đề xuất Giai đoạn 0 nào, kết quả cuối cùng có thể hoạt động khác.
Vấn đề ở đây là gì?
Nếu các chú thích kiểu không thay đổi chương trình của bạn, câu hỏi rõ ràng là liệu chúng có đáng có hay không. Đề xuất lập luận là “có” vì cú pháp có khả năng rút ngắn thời gian lặp lại và giảm gánh nặng xung quanh các công cụ JavaScript hiện đại.
Việc viết mã loại an toàn hiện tại yêu cầu bạn sử dụng TypeScript, một ngôn ngữ ngôn ngữ khác bổ sung thêm các phụ thuộc vào dự án của bạn và yêu cầu bước biên dịch thủ công. Sau đó, mã đó có thể chuyển qua các công cụ khác như gói mô-đun và trình chuyển đổi trước khi JavaScript cuối cùng của bạn được tạo ra để phân phối. Nó thêm vào một chuỗi công cụ phức tạp với nhiều bộ phận chuyển động.
Mặc dù JavaScript vốn dĩ là một ngôn ngữ được đánh máy lỏng lẻo, nhưng lợi ích của việc đánh máy mạnh hiện đã được công nhận rộng rãi bởi cộng đồng. Điều này được thể hiện rõ ràng từ động lực xung quanh dự án TypeScript. Nhập tĩnh cũng là người dẫn đầu rõ ràng trong câu hỏi về “tính năng còn thiếu” của cuộc khảo sát State of JS năm 2021.
Việc thêm cú pháp kiểu vào chính JavaScript sẽ cho phép bạn nhận được một số lợi ích của TypeScript mà không cần phải biên dịch mã của bạn. Điều này giúp đơn giản hóa việc thiết lập và bảo trì dự án trong khi phát triển JavaScript để phù hợp hơn với thực tiễn phát triển hiện đại.
Trong vài năm qua, nhiều mã đã bắt đầu quay trở lại hướng tiếp cận “JavaScript thuần túy”. Sự suy giảm của các trình duyệt cũ làm cho việc chuyển đổi ít cần thiết hơn trước đây – phần lớn các triển khai hiện đại cung cấp hỗ trợ đầy đủ cho các tính năng như lớp, hàm mũi tên, biến phạm vi khối và async/await. JavaScript thậm chí còn có một hệ thống mô-đun chính thức hoạt động trên các công cụ, bao gồm cả trong các trình duyệt.
Chỉ một vài năm trước, một chuỗi công cụ dài là yêu cầu để có thể viết những tính năng này vào mã của bạn một cách chắc chắn rằng nó sẽ hoạt động trên thiết bị của người dùng. Ngày nay, các nhà phát triển có thể đặt các quy trình xây dựng đó sang một bên một cách an toàn, quay trở lại mô hình JavaScript ban đầu của các tệp tham chiếu với <script> các thẻ.
Các loại là một trong số ít các lĩnh vực còn lại của hệ sinh thái JavaScript không được ngôn ngữ này chấp nhận. Yêu chúng hay ghét chúng, không thể phủ nhận rằng các loại đã trở thành một phần không thể thiếu trong quá trình phát triển JavaScript cho nhiều nhóm và dự án. Đề xuất cú pháp chính thức công nhận thực tế này. Nó cố gắng mang lại một mức độ hỗ trợ loại cho JavaScript mà không phá vỡ mã hiện có hoặc thực thi kiểm tra loại thời gian chạy đạt hiệu suất.
Trên thực tế các loại nên làm gì?
Vai trò của “loại” khác nhau giữa các ngôn ngữ. Ác nhân chung nằm ở khả năng của một kiểu thể hiện kiểu dữ liệu mà một biến cụ thể sẽ nắm giữ. Ý nghĩa, khả năng và hành vi bổ sung sau đó được xếp lớp trên nền tảng đó.
Trong các ngôn ngữ biên dịch được định kiểu tĩnh như C # và Java, các kiểu được thực thi tại thời điểm biên dịch. Không thể biên dịch một chương trình khi bạn có kiểu không tương thích trong mã của mình. Trong các ngôn ngữ được thông dịch với kiểu gõ mạnh tùy chọn, trong đó PHP là một ví dụ, các kiểu được thực thi trong thời gian chạy – chương trình sẽ thông báo lỗi khi kiểu của giá trị không tương thích với ngữ cảnh mà nó được sử dụng.
Một cuộc tranh luận sôi nổi trong cộng đồng JavaScript về việc chuyển tiền của bất kỳ hệ thống loại tích hợp nào sẽ kéo dài bao xa. Đề xuất này giới hạn vai trò của nó ở yếu tố nền tảng nhất, một tài liệu đơn giản về loại giá trị được mong đợi. Điều này phù hợp với vị trí của TypeScript như một cú pháp kiểu có thể xóa được bị bỏ qua trong thời gian chạy.
Mục đích của mô hình này là cung cấp cho các nhà phát triển phản hồi tức thì về các lỗi tiềm ẩn khi họ viết mã. Bạn có thể nhận được thông tin về các vấn đề loại khi bạn viết JavaScript thông thường trong một IDE tương thích. Nếu muốn, bạn cũng có thể sử dụng một công cụ hỗ trợ như TypeScript, một trình phân tích tĩnh hoặc một trình gói để kiểm tra nguồn của bạn theo yêu cầu. Điều này có thể chặn triển khai trong đường ống CI của bạn khi có vấn đề về loại.
Cảm giác hiện tại là những khả năng này đủ để điều chỉnh JavaScript với các nhu cầu phổ biến nhất của nhà phát triển. Các tính năng được tìm thấy trong các ngôn ngữ khác như xem xét nội tâm và phản ánh thường không cần thiết trong hệ sinh thái JavaScript, một phần vì các nhà phát triển đã quen với cách tiếp cận xóa của TypeScript.
Giải pháp thay thế hiện tại: Docblocks
Cần lưu ý rằng một cái gì đó tương tự như cú pháp chú thích bị xóa được đề xuất đã tồn tại: các thẻ JSDoc quen thuộc thường được sử dụng để thêm chi tiết loại vào mã JavaScript đơn giản:
/** * @param name {string} * @param age {number} */ function sayAge(name, age) { console.log(`${name} is ${age} years old.`); }
Các bình luận JSDoc được hỗ trợ bởi các công cụ phổ biến khác nhau. Tuy nhiên, chúng không phải là một phần được chuẩn hóa của ngôn ngữ và chúng yêu cầu bạn kết hợp các chi tiết về hoạt động của mã của bạn – các loại mã dự kiến - với tài liệu lấy con người làm trung tâm bao gồm phần còn lại của docblock.
Cú pháp của JSDoc cũng rất dài dòng. Bên cạnh các tên thẻ bắt buộc, nó thường yêu cầu lặp lại các phần tử đã tồn tại trong mã của bạn, chẳng hạn như tên thông số trong ví dụ trên. Nếu bạn sửa đổi một tham số trong chữ ký của hàm, bạn cũng phải nhớ thay đổi thẻ JSDoc.
Đề xuất cú pháp mới có thể tương đương về mặt chức năng với docblocks nhưng nó mang lại trải nghiệm hợp lý hơn nhiều. Các loại nằm dọc theo các mục tiêu của chúng như là một phần của nguồn của bạn, thay vì trong một docblock mà bạn cần tạo và duy trì riêng biệt.
Cái gì tiếp theo?
Nhóm TypeScript của Microsoft và các đồng tác giả bao gồm Bloomberg, Igwalia và một số cộng tác viên độc lập đã đệ trình đề xuất Giai đoạn 0 trong phiên họp toàn thể TC39 tháng 3 năm 2022. Đề xuất kể từ đó đã chuyển sang Giai đoạn 1. Mặc dù vậy, việc chấp nhận vẫn còn một số chặng đường, với việc triển khai bên trong các động cơ có thể sẽ không đến trong “nhiều năm”.
Mục tiêu tổng quát của đề xuất này là cân bằng đuôi dài của mã không định kiểu JavaScript với nhu cầu hiện tại về trải nghiệm phát triển được nhập tĩnh hơn. Việc sử dụng một cú pháp hoàn toàn tùy chọn đã xóa đảm bảo khả năng tương thích ngược nhưng làm tăng triển vọng rằng nó sẽ không hiệu quả trong việc khuyến khích áp dụng và củng cố hệ sinh thái. Cuộc tranh luận xung quanh vấn đề này có vẻ sẽ phát triển với nhiều ý kiến và quan điểm mới khi đề xuất tiến triển thông qua quá trình theo dõi tiêu chuẩn.
[ad_2]
