TypeScript là gì và tại sao tôi lại sử dụng nó thay cho JavaScript? [đóng cửa]


1696

Bạn có thể vui lòng mô tả ngôn ngữ TypeScript là gì không?

Nó có thể làm gì mà JavaScript hoặc các thư viện có sẵn không thể làm được, điều đó sẽ cho tôi lý do để xem xét nó?



Dưới đây là một số suy nghĩ về điều này: blog.priceandcost.com/development/ trộm
Jefim

Câu trả lời:


1299

Ban đầu tôi đã viết câu trả lời này khi TypeScript vẫn còn nóng hổi. Năm năm sau, đây là một tổng quan OK, nhưng hãy xem câu trả lời của Lodewijk dưới đây để có thêm chiều sâu

Chế độ xem 1000ft ...

TypeScript là một siêu bộ JavaScript, chủ yếu cung cấp các kiểu gõ, lớp và giao diện tĩnh tùy chọn. Một trong những lợi ích lớn là cho phép các IDE cung cấp một môi trường phong phú hơn để phát hiện các lỗi phổ biến khi bạn nhập mã .

Để hiểu ý tôi muốn nói, hãy xem video giới thiệu về ngôn ngữ của Microsoft .

Đối với một dự án JavaScript lớn, việc áp dụng TypeScript có thể dẫn đến phần mềm mạnh hơn, trong khi vẫn có thể triển khai được khi ứng dụng JavaScript thông thường sẽ chạy.

Nó là nguồn mở, nhưng bạn chỉ nhận được Intellisense thông minh khi bạn nhập nếu bạn sử dụng IDE được hỗ trợ. Ban đầu, đây chỉ là Visual Studio của Microsoft (cũng được ghi chú trong bài đăng trên blog từ Miguel de Icaza ). Ngày nay, các IDE khác cũng cung cấp hỗ trợ TypeScript .

Có những công nghệ khác giống như nó?

CoffeeScript , nhưng điều đó thực sự phục vụ một mục đích khác. IMHO, CoffeeScript cung cấp khả năng đọc cho con người, nhưng TypeScript cũng cung cấp khả năng đọc sâu cho các công cụ thông qua việc gõ tĩnh tùy chọn (xem bài đăng trên blog gần đây để biết thêm một chút phê bình). Ngoài ra còn có Dart nhưng đó là sự thay thế hoàn toàn cho JavaScript (mặc dù nó có thể tạo mã JavaScript )

Thí dụ

Ví dụ: đây là một số TypeScript (bạn có thể chơi với cái này trong Sân chơi TypeScript )

class Greeter {
    greeting: string;
    constructor (message: string) {
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
}  

Và đây là JavaScript nó sẽ tạo ra

var Greeter = (function () {
    function Greeter(message) {
        this.greeting = message;
    }
    Greeter.prototype.greet = function () {
        return "Hello, " + this.greeting;
    };
    return Greeter;
})();

Lưu ý cách TypeScript định nghĩa loại biến thành viên và tham số phương thức lớp. Điều này được loại bỏ khi dịch sang JavaScript, nhưng được IDE và trình biên dịch sử dụng để phát hiện lỗi, như chuyển một kiểu số cho hàm tạo.

Nó cũng có khả năng suy ra các kiểu không được khai báo rõ ràng, ví dụ, nó sẽ xác định greet()phương thức trả về một chuỗi.

Gỡ lỗi TypeScript

Nhiều trình duyệt và IDE cung cấp hỗ trợ gỡ lỗi trực tiếp thông qua các tài liệu. Xem câu hỏi Stack Overflow này để biết thêm chi tiết: Gỡ lỗi mã TypeScript với Visual Studio

Bạn muốn biết thêm?

Ban đầu tôi đã viết câu trả lời này khi TypeScript vẫn còn nóng hổi. Kiểm tra câu trả lời của Lodewijk cho câu hỏi này để biết thêm chi tiết hiện tại.


103
WebStorm cung cấp IntelliSense đẹp trên TypeScript ngay bây giờ và là đa nền tảng.
Radek

26
Vấn đề với các công cụ này là bạn không bao giờ có được hiệu suất đầy đủ từ javascript. Vâng, nó cung cấp khả năng đọc tốt nhưng mã được biên dịch đôi khi rất lộn xộn. Bạn dựa vào một công cụ của bên thứ ba để viết javascript gốc, tôi nghĩ rằng đây không phải là cách để đi, nó giống như chuyển đổi một ngôn ngữ sang ngôn ngữ khác. Muốn thay đổi một ngôn ngữ không phải là ngôn ngữ khác để hành xử như ngôn ngữ khác mà bạn thích, đó là điều ngu ngốc và ngớ ngẩn. ...... (kết thúc phần 1) ......
Codebeat

56
@Erwinus: Bạn vẫn lập trình với trình biên dịch chương trình?
VikciaR

11
@Erwinus Bạn đang đưa ra các giả định về cách thức hoạt động của TypeScript. Bạn có thể viết JavaScript đơn giản dưới dạng TypeScript và có trình biên dịch chỉ thực hiện kiểm tra kiểu thời gian biên dịch. Không có mất hiệu suất bằng cách làm điều đó.
thinkrepo

41
@Erwinus Điểm của TypeScript là cung cấp kiểm tra kiểu thời gian biên dịch. Nếu bạn không thấy giá trị trong đó, điều đó hoàn toàn tốt. TypeScript đã được coi là "bài kiểm tra đơn vị đầu tiên của bạn". Có nhiều tài nguyên thảo luận về việc kiểm tra loại tùy chọn có giá trị hay không và chi tiết hơn những gì chúng ta có thể làm ở đây. Tôi không cố gắng thuyết phục bạn về bất cứ điều gì, chỉ sửa chữa một quan niệm sai lầm.
thinkrepo

1053

Mối quan hệ của TypeScript với JavaScript

TypeScript là một siêu ký tự gõ JavaScript được biên dịch thành JavaScript đơn giản - typecolang.org .

JavaScript là ngôn ngữ lập trình được phát triển bởi Ủy ban Kỹ thuật 39 của EMCA , là một nhóm gồm nhiều bên liên quan khác nhau. TC39 là một ủy ban được tổ chức bởi ECMA : một tổ chức tiêu chuẩn nội bộ. JavaScript có nhiều triển khai khác nhau bởi nhiều nhà cung cấp khác nhau (ví dụ: Google, Microsoft, Oracle, v.v.). Mục tiêu của JavaScript là trở thành ngôn ngữ chung của web.

TypeScript là một siêu ngôn ngữ của JavaScript có một trình biên dịch mã nguồn mở duy nhất và được phát triển chủ yếu bởi một nhà cung cấp duy nhất: Microsoft. Mục tiêu của TypeScript là giúp sớm bắt lỗi thông qua một hệ thống loại và giúp phát triển JavaScript hiệu quả hơn.

Về cơ bản, TypeScript đạt được mục tiêu theo ba cách:

  1. Hỗ trợ cho các tính năng JavaScript hiện đại - Ngôn ngữ JavaScript (không phải thời gian chạy) được chuẩn hóa thông qua các tiêu chuẩn ECMAScript . Không phải tất cả các trình duyệt và thời gian chạy JavaScript đều hỗ trợ tất cả các tính năng của tất cả các tiêu chuẩn ECMAScript (xem tổng quan này ). Nguyên cảo cho phép sử dụng của nhiều mới nhất ECMAScript tính năng và dịch chúng sang các mục tiêu ECMAScript cũ của lựa chọn của bạn (xem danh sách các mục tiêu biên dịch dưới --targettùy chọn biên dịch). Điều này có nghĩa là bạn có thể sử dụng một cách an toàn các tính năng mới, như mô-đun, chức năng lambda, lớp, toán tử trải rộng và phá hủy, trong khi vẫn tương thích ngược với các trình duyệt cũ hơn và thời gian chạy JavaScript.

  2. Hệ thống loại nâng cao - Hỗ trợ loại không phải là một phần của tiêu chuẩn ECMAScript và có thể sẽ không bao giờ do bản chất được giải thích thay vì bản chất được biên dịch của JavaScript. Hệ thống loại của TypeScript vô cùng phong phú và bao gồm: giao diện, enum, kiểu lai, tổng quát, loại kết hợp / giao cắt, sửa đổi truy cập và nhiều hơn nữa. Các trang web chính thức của nguyên cảo đưa ra một tổng quan về các tính năng này. Hệ thống loại bản in ngang bằng với hầu hết các ngôn ngữ đánh máy khác và trong một số trường hợp mạnh hơn nhiều.

  3. Hỗ trợ công cụ dành cho nhà phát triển - Trình biên dịch của TypeScript có thể chạy như một quy trình nền để hỗ trợ cả quá trình biên dịch gia tăng và tích hợp IDE để bạn có thể dễ dàng điều hướng, xác định các vấn đề, kiểm tra các khả năng và cấu trúc lại cơ sở mã của bạn.

Mối quan hệ của TypeScript với các ngôn ngữ nhắm mục tiêu JavaScript khác

TypeScript có một triết lý duy nhất so với các ngôn ngữ khác biên dịch thành JavaScript. Mã JavaScript là mã TypeScript hợp lệ; TypeScript là một siêu ký tự của JavaScript. Bạn gần như có thể đổi tên các .jstệp của mình thành .tscác tệp và bắt đầu sử dụng TypeScript (xem "Khả năng tương tác JavaScript" bên dưới). Các tệp TypeScript được biên dịch thành JavaScript có thể đọc được, do đó việc di chuyển trở lại là có thể và hiểu được TypeScript đã biên dịch hoàn toàn không khó. TypeScript xây dựng dựa trên những thành công của JavaScript trong khi cải thiện những điểm yếu của nó.

Một mặt, bạn có các công cụ bằng chứng trong tương lai lấy các tiêu chuẩn ECMAScript hiện đại và biên dịch nó thành các phiên bản JavaScript cũ hơn với Babel là công cụ phổ biến nhất. Mặt khác, bạn có các ngôn ngữ hoàn toàn khác với JavaScript nhắm mục tiêu JavaScript, như CoffeeScript, Clojure, Dart, Elm, Haxe, Scala.js và toàn bộ máy chủ lưu trữ (xem danh sách này). Các ngôn ngữ này, mặc dù chúng có thể tốt hơn so với nơi mà tương lai của JavaScript có thể dẫn đến, có nguy cơ lớn hơn là không tìm thấy đủ sự chấp nhận cho tương lai của chúng được đảm bảo. Bạn cũng có thể gặp nhiều khó khăn hơn trong việc tìm kiếm các nhà phát triển có kinh nghiệm cho một số ngôn ngữ này, mặc dù những ngôn ngữ bạn sẽ tìm thấy thường có thể nhiệt tình hơn. Tương tác với JavaScript cũng có thể được tham gia nhiều hơn một chút, vì chúng được loại bỏ xa hơn so với JavaScript thực sự là gì.

TypeScript nằm ở giữa hai thái cực này, do đó cân bằng rủi ro. TypeScript không phải là một lựa chọn rủi ro theo bất kỳ tiêu chuẩn nào. Phải mất rất ít nỗ lực để làm quen nếu bạn quen thuộc với JavaScript, vì nó không phải là một ngôn ngữ hoàn toàn khác, có hỗ trợ khả năng tương tác JavaScript tuyệt vời và gần đây nó đã được chấp nhận rất nhiều.

Tùy chọn gõ tĩnh và gõ suy luận

JavaScript được gõ động. Điều này có nghĩa là JavaScript không biết loại biến là gì cho đến khi nó thực sự được khởi tạo vào thời gian chạy. Điều này cũng có nghĩa là nó có thể quá muộn. TypeScript thêm hỗ trợ loại cho JavaScript. Lỗi được gây ra bởi các giả định sai của một số biến thuộc một loại nhất định có thể bị xóa hoàn toàn nếu bạn chơi đúng thẻ của bạn (bạn nhập mã nghiêm ngặt như thế nào hoặc nếu bạn nhập mã hoàn toàn tùy thuộc vào bạn).

TypeScript làm cho việc gõ dễ dàng hơn một chút và ít rõ ràng hơn bằng cách sử dụng suy luận kiểu. Ví dụ: var x = "hello"trong TypeScript giống như var x : string = "hello". Các loại chỉ đơn giản là suy ra từ việc sử dụng nó. Ngay cả khi bạn không gõ các loại một cách rõ ràng, chúng vẫn ở đó để cứu bạn khỏi làm điều gì đó nếu không sẽ dẫn đến lỗi thời gian chạy.

TypeScript được tùy chọn gõ theo mặc định. Ví dụ, function divideByTwo(x) { return x / 2 }là một hàm hợp lệ trong TypeScript có thể được gọi với bất kỳ loại tham số nào, mặc dù việc gọi nó bằng một chuỗi rõ ràng sẽ dẫn đến lỗi thời gian chạy . Giống như bạn đã quen với JavaScript. Điều này hoạt động, bởi vì khi không có loại nào được gán rõ ràng và loại không thể được suy ra, như trong ví dụ splitByTwo, TypeScript sẽ ngầm định gán loại any. Điều này có nghĩa là chữ ký loại của hàm splitByTwo sẽ tự động trở thành function divideByTwo(x : any) : any. Có một cờ biên dịch để không cho phép hành vi này : --noImplicitAny. Kích hoạt cờ này mang lại cho bạn mức độ an toàn cao hơn, nhưng cũng có nghĩa là bạn sẽ phải gõ nhiều hơn.

Các loại có một chi phí liên quan đến chúng. Trước hết, có một đường cong học tập, và thứ hai, tất nhiên, nó sẽ khiến bạn tốn thêm một chút thời gian để thiết lập một cơ sở mã bằng cách sử dụng kiểu gõ đúng. Theo kinh nghiệm của tôi, những chi phí này hoàn toàn xứng đáng với bất kỳ cơ sở mã hóa nghiêm trọng nào mà bạn đang chia sẻ với người khác. Một nghiên cứu quy mô lớn về ngôn ngữ lập trình và chất lượng mã trong Github cho thấy rằng "các ngôn ngữ được gõ tĩnh, nói chung, ít bị lỗi hơn các loại động và gõ mạnh hơn tốt hơn so với gõ yếu trong cùng một vấn đề".

Thật thú vị khi lưu ý rằng chính bài báo này phát hiện ra rằng TypeScript ít bị lỗi hơn JavaScript:

Đối với những người có hệ số dương, chúng tôi có thể mong đợi rằng ngôn ngữ được liên kết với, ceteris paribus, một số lượng lớn hơn các sửa lỗi. Các ngôn ngữ này bao gồm C, C ++, JavaScript , Objective-C, Php và Python. Các ngôn ngữ Clojure, Haskell, Ruby, Scala và TypeScript , tất cả đều có hệ số âm cho thấy các ngôn ngữ này ít có khả năng dẫn đến các lỗi cam kết sửa lỗi.

Hỗ trợ IDE nâng cao

Trải nghiệm phát triển với TypeScript là một cải tiến tuyệt vời so với JavaScript. IDE được trình biên dịch TypeScript thông báo theo thời gian thực về thông tin loại phong phú của nó. Điều này mang lại một vài lợi thế lớn. Ví dụ, với TypeScript, bạn có thể thực hiện tái cấu trúc một cách an toàn như đổi tên trên toàn bộ cơ sở mã của mình. Thông qua việc hoàn thành mã, bạn có thể nhận trợ giúp nội tuyến về bất kỳ chức năng nào mà thư viện có thể cung cấp. Không cần phải nhớ chúng hoặc tìm kiếm chúng trong các tài liệu tham khảo trực tuyến. Lỗi biên dịch được báo cáo trực tiếp trong IDE với một dòng nguệch ngoạc màu đỏ trong khi bạn đang bận mã hóa. Nói chung, điều này cho phép tăng năng suất đáng kể so với làm việc với JavaScript. Người ta có thể dành nhiều thời gian hơn cho việc mã hóa và ít thời gian hơn để gỡ lỗi.

Có một loạt các IDE có hỗ trợ tuyệt vời cho TypeScript, như Visual Studio Code, WebStorm, Atom và Sublime.

Kiểm tra null nghiêm ngặt

Lỗi thời gian chạy của biểu mẫu cannot read property 'x' of undefinedhoặc undefined is not a functionrất phổ biến do lỗi trong mã JavaScript. TypeScript đã loại bỏ khả năng xảy ra các loại lỗi này, vì người ta không thể sử dụng một biến mà trình biên dịch TypeScript không biết (ngoại trừ các thuộc tính của anycác biến được nhập). Mặc dù vẫn có thể sử dụng nhầm một biến được đặt thành undefined. Tuy nhiên, với phiên bản 2.0 của TypeScript, bạn có thể loại bỏ tất cả các loại lỗi này thông qua việc sử dụng các loại không thể rỗng. Điều này hoạt động như sau:

Với các kiểm tra null nghiêm ngặt được kích hoạt ( --strictNullCheckscờ trình biên dịch), trình biên dịch TypeScript sẽ không cho phép undefinedđược gán cho một biến trừ khi bạn tuyên bố rõ ràng nó là loại nullable. Ví dụ, let x : number = undefinedsẽ dẫn đến một lỗi biên dịch. Điều này hoàn toàn phù hợp với lý thuyết loại vì undefinedkhông phải là một con số. Người ta có thể định nghĩa xlà một loại tổng numberundefinedđể sửa điều này : let x : number | undefined = undefined.

Khi một loại được biết là không thể, có nghĩa là loại đó cũng có thể là giá trị nullhoặc undefined, trình biên dịch TypeScript có thể xác định thông qua phân tích loại dựa trên luồng điều khiển xem mã của bạn có thể sử dụng biến một cách an toàn hay không. Nói cách khác, khi bạn kiểm tra một biến là undefinedthông qua một ifcâu lệnh, trình biên dịch TypeScript sẽ suy ra rằng kiểu trong nhánh điều khiển của mã của bạn không còn có thể bị vô hiệu hóa nữa và do đó có thể được sử dụng một cách an toàn. Đây là một ví dụ đơn giản:

let x: number | undefined;
if (x !== undefined) x += 1; // this line will compile, because x is checked.
x += 1; // this line will fail compilation, because x might be undefined.

Trong quá trình xây dựng, đồng thiết kế hội nghị năm 2016 của TypeScript Anders Hejlsberg đã đưa ra lời giải thích và trình diễn chi tiết về tính năng này: video (từ 44:30 đến 56:30).

Biên soạn

Để sử dụng TypeScript, bạn cần một quy trình xây dựng để biên dịch thành mã JavaScript. Quá trình xây dựng thường chỉ mất vài giây tùy thuộc vào quy mô dự án của bạn. Trình biên dịch TypeScript hỗ trợ biên dịch gia tăng ( --watchcờ trình biên dịch) để tất cả các thay đổi tiếp theo có thể được biên dịch ở tốc độ lớn hơn.

Trình biên dịch TypeScript có thể nội tuyến thông tin bản đồ nguồn trong các tệp .js được tạo hoặc tạo các tệp .map riêng. Thông tin bản đồ nguồn có thể được sử dụng bằng cách gỡ lỗi các tiện ích như DevTools của Chrome và các IDE khác để liên kết các dòng trong JavaScript với các tiện ích đã tạo ra chúng trong TypeScript. Điều này giúp bạn có thể đặt các điểm dừng và kiểm tra các biến trong thời gian chạy trực tiếp trên mã TypeScript của bạn. Thông tin bản đồ nguồn hoạt động khá tốt, nó đã có từ rất lâu trước TypeScript, nhưng việc gỡ lỗi TypeScript thường không tuyệt vời như khi sử dụng JavaScript trực tiếp. Lấy thistừ khóa làm ví dụ. Do ngữ nghĩa đã thay đổi của thistừ khóa xung quanh các lần đóng kể từ ES2015, thisthực tế có thể tồn tại trong thời gian chạy dưới dạng một biến được gọi _this(xem câu trả lời này). Điều này có thể làm bạn bối rối trong quá trình gỡ lỗi nhưng nhìn chung không phải là vấn đề nếu bạn biết về nó hoặc kiểm tra mã JavaScript. Cần lưu ý rằng Babel phải chịu cùng một loại vấn đề.

Có một vài thủ thuật khác mà trình biên dịch TypeScript có thể làm, như tạo mã chặn dựa trên các trình trang trí , tạo mã tải mô-đun cho các hệ thống mô-đun khác nhau và phân tích cú pháp JSX . Tuy nhiên, bạn có thể sẽ yêu cầu một công cụ xây dựng bên cạnh trình biên dịch Typecript. Ví dụ: nếu bạn muốn nén mã của mình, bạn sẽ phải thêm các công cụ khác vào quy trình xây dựng của mình để thực hiện.

Có các trình biên dịch TypeScript có sẵn cho Webpack , Gulp , Grunt và khá nhiều công cụ xây dựng JavaScript khác hiện có. Tài liệu TypeScript có một phần về tích hợp với các công cụ xây dựng bao gồm tất cả. Một kẻ nói dối cũng có sẵn trong trường hợp bạn muốn kiểm tra thời gian xây dựng nhiều hơn. Ngoài ra còn có một số lượng lớn các dự án hạt giống sẽ giúp bạn bắt đầu với TypeScript kết hợp với một loạt các công nghệ khác như Angular 2, React, Ember, SystemJS, Webpack, Gulp, v.v.

Khả năng tương tác JavaScript

Vì TypeScript có liên quan mật thiết đến JavaScript nên nó có khả năng tương tác tuyệt vời, nhưng một số công việc bổ sung được yêu cầu để làm việc với các thư viện JavaScript trong TypeScript. Định nghĩa nguyên cảo là cần thiết để trình biên dịch nguyên cảo hiểu rằng cuộc gọi chức năng như _.groupByhoặc angular.copyhoặc $.fadeOutđang không ở trong báo cáo bất hợp pháp thực tế. Các định nghĩa cho các chức năng này được đặt trong .d.tscác tập tin.

Hình thức đơn giản nhất mà một định nghĩa có thể thực hiện là cho phép một định danh được sử dụng theo bất kỳ cách nào. Ví dụ: khi sử dụng Lodash , một tệp định nghĩa một dòng declare var _ : anysẽ cho phép bạn gọi bất kỳ chức năng nào bạn muốn _, nhưng sau đó, tất nhiên, bạn vẫn có thể mắc lỗi: tất nhiên _.foobar()sẽ là một cuộc gọi TypeScript hợp pháp, nhưng dĩ nhiên là , một cuộc gọi bất hợp pháp vào thời gian chạy. Nếu bạn muốn hỗ trợ loại đúng và hoàn thành mã, tệp định nghĩa của bạn cần phải chính xác hơn (xem ví dụ về định nghĩa lodash ).

Các mô-đun Npm được đóng gói sẵn với các định nghĩa kiểu riêng của chúng được trình biên dịch TypeScript tự động hiểu (xem tài liệu ). Đối với hầu hết mọi thư viện JavaScript bán phổ biến khác không bao gồm các định nghĩa riêng của nó, một số người đã đưa ra các định nghĩa kiểu thông qua một mô-đun npm khác. Các mô-đun này có tiền tố là "@ type /" và đến từ kho lưu trữ Github có tên DefiniteTyped .

Có một cảnh báo: các định nghĩa loại phải phù hợp với phiên bản của thư viện bạn đang sử dụng vào thời gian chạy. Nếu không, TypeScript có thể không cho phép bạn gọi một hàm hoặc hủy bỏ một biến tồn tại hoặc cho phép bạn gọi một hàm hoặc hủy đăng ký một biến không tồn tại, đơn giản vì các kiểu không khớp với thời gian chạy tại thời gian biên dịch . Vì vậy, hãy đảm bảo bạn tải đúng phiên bản định nghĩa loại cho phiên bản đúng của thư viện bạn đang sử dụng.

Thành thật mà nói, có một rắc rối nhỏ với điều này và đó có thể là một trong những lý do bạn không chọn TypeScript, nhưng thay vào đó, hãy tìm một thứ như Babel không phải chịu đựng định nghĩa kiểu nào cả. Mặt khác, nếu bạn biết những gì bạn đang làm, bạn có thể dễ dàng khắc phục mọi loại sự cố gây ra bởi các tệp định nghĩa không chính xác hoặc bị thiếu.

Chuyển đổi từ JavaScript sang TypeScript

Bất kỳ .jstệp nào cũng có thể được đổi tên thành .tstệp và chạy qua trình biên dịch TypeScript để lấy mã JavaScript về mặt cú pháp như một đầu ra (nếu nó đúng về mặt cú pháp ở vị trí đầu tiên). Ngay cả khi trình biên dịch TypeScript gặp lỗi biên dịch, nó vẫn sẽ tạo ra một .jstệp. Nó thậm chí có thể chấp nhận .jscác tập tin như đầu vào với --allowJscờ. Điều này cho phép bạn bắt đầu với TypeScript ngay lập tức. Thật không may, lỗi biên dịch có khả năng xảy ra ngay từ đầu. Bạn không cần phải nhớ rằng đây không phải là các lỗi dừng hiển thị như bạn có thể sử dụng với các trình biên dịch khác.

Các lỗi biên dịch bắt đầu khi chuyển đổi dự án JavaScript sang dự án TypeScript là không thể tránh khỏi bởi bản chất của TypeScript. TypeScript kiểm tra tất cả các mã cho tính hợp lệ và do đó nó cần biết về tất cả các hàm và biến được sử dụng. Do đó, định nghĩa kiểu cần phải được đặt ra cho tất cả chúng nếu không các lỗi biên dịch sẽ bị ràng buộc. Như đã đề cập trong chương trên, đối với hầu hết mọi khung JavaScript đều có .d.tscác tệp có thể dễ dàng có được bằng cách cài đặt các gói DefiniteTyped. Tuy nhiên, có thể là bạn đã sử dụng một số thư viện tối nghĩa mà không có định nghĩa TypeScript nào có sẵn hoặc bạn đã điền vào một số nguyên hàm JavaScript. Trong trường hợp đó, bạn phải cung cấp định nghĩa loại cho các bit này để các lỗi biên dịch biến mất. Chỉ cần tạo một .d.tstệp và đưa nó vào filesmảng của tsconfig.json , để nó luôn được trình biên dịch TypeScript xem xét. Trong đó khai báo các bit mà TypeScript không biết về kiểu any. Khi bạn đã loại bỏ tất cả các lỗi, bạn có thể dần dần đưa vào các phần đó theo nhu cầu của mình.

Một số công việc trên (tái) cấu hình đường ống xây dựng của bạn cũng sẽ cần thiết để đưa TypeScript vào đường ống xây dựng. Như đã đề cập trong chương về biên soạn, có rất nhiều nguồn lực tốt và tôi khuyến khích bạn tìm kiếm các dự án hạt giống sử dụng kết hợp các công cụ mà bạn muốn làm việc.

Rào cản lớn nhất là đường cong học tập. Tôi khuyến khích bạn chơi xung quanh với một dự án nhỏ lúc đầu. Nhìn cách nó hoạt động, cách xây dựng, sử dụng tệp nào, cách cấu hình, cách thức hoạt động trong IDE của bạn, cách cấu trúc, công cụ sử dụng, v.v. Chuyển đổi một cơ sở mã JavaScript lớn sang TypeScript là có thể thực hiện được khi bạn biết những gì bạn đang làm Đọc blog này ví dụ về việc chuyển đổi 600k dòng thành bản in trong 72 giờ ). Chỉ cần chắc chắn rằng bạn có một nắm bắt tốt về ngôn ngữ trước khi bạn thực hiện bước nhảy.

Con nuôi

TypeScript là mã nguồn mở (được cấp phép Apache 2, xem GitHub ) và được Microsoft hỗ trợ. Anders Hejlsberg , kiến ​​trúc sư trưởng của C # đang dẫn đầu dự án. Đó là một dự án rất tích cực; nhóm TypeScript đã phát hành rất nhiều tính năng mới trong vài năm qua và rất nhiều tính năng tuyệt vời vẫn được lên kế hoạch (xem lộ trình ).

Một số sự thật về việc áp dụng và phổ biến:

  • Trong khảo sát nhà phát triển StackOverflow 2017, TypeScript là trình chuyển mã JavaScript phổ biến nhất (vị trí thứ 9 tổng thể) và giành vị trí thứ ba trong hạng mục ngôn ngữ lập trình được yêu thích nhất.
  • Trong trạng thái khảo sát js năm 2018, TypeScript được tuyên bố là một trong hai người chiến thắng lớn trong danh mục hương vị JavaScript (với ES6 là loại khác).
  • Trong cuộc khảo sát deverloper StackOverlow năm 2019, TypeScript đã vươn lên vị trí thứ 9 trong số các ngôn ngữ phổ biến nhất trong số các nhà phát triển chuyên nghiệp, vượt qua cả C và C ++. Nó một lần nữa chiếm vị trí thứ ba trong số các ngôn ngữ được yêu thích nhất.

25
"Mã JavaScript là mã TypeScript hợp lệ" - điều này thực sự không phải lúc nào cũng đúng. Ý tôi là mã như if (1 === '1') {} cung cấp cho bạn một lỗi trong TS và trong JS thì không. Nhưng hầu hết thời gian, nếu mã JS được viết tốt thì đó là sự thật.
Maciej Bukowski

3
Nếu bạn đã mất thời gian sản xuất quý giá của mình khi lo lắng về một dấu chấm phẩy bị thiếu, viết bằng Bản in sẽ là một cứu tinh.
SoSufi

3
Các kiểu chữ đã bị phản đối, và cách thực hành tốt nhất hiện nay là chỉ npm(hoặc yarn) install @types/foo. Bạn có thể cập nhật câu trả lời của bạn?
Jed Fox

13
TL; DR sẽ tiết kiệm hơn trong câu trả lời này;)
Qback

8
@MaciejBukowski Ngay cả khi TypeScript thực sự phàn nàn trong trường hợp này, bạn vẫn nhận được một đầu ra JS hợp lệ (sẽ là mã JS mà bạn đã biên dịch / dịch mã với TypeScript). Vì vậy, đó là "biên dịch có lỗi" và không phải là TypeScript không hợp lệ. Nó được ghi trong đặc tả TypeScript rằng mọi mã JS hợp lệ phải là mã TS hợp lệ.
Pac0

83

TypeScript làm một cái gì đó tương tự như những gì ít hoặc sass làm cho CSS. Chúng là các tập hợp siêu của nó, có nghĩa là mọi mã JS bạn viết đều là mã TypeScript hợp lệ. Ngoài ra, bạn có thể sử dụng các tính năng khác mà nó thêm vào ngôn ngữ và mã được dịch mã sẽ là js hợp lệ. Bạn thậm chí có thể đặt phiên bản JS mà bạn muốn mã kết quả của mình.

Hiện tại TypeScript là một bộ siêu ES2015, vì vậy có thể là một lựa chọn tốt để bắt đầu tìm hiểu các tính năng js mới và dịch mã theo tiêu chuẩn cần thiết cho dự án của bạn.


4
TL tốt nhất là trang của TS: "TypeScript là một siêu ký tự gõ JavaScript được biên dịch thành JavaScript đơn giản."
Juan Mendes

1
Nó không trả lời "tại sao tôi nên sử dụng nó". Ở đây tl; dr sẽ là: 1) Để thêm các loại tĩnh tùy chọn vào JavaScript. Các loại có thể giúp bắt lỗi tại thời gian biên dịch và tài liệu tốt hơn cho chương trình của bạn. 2) Bạn có thể viết JavaScript mới (ES6 / ES7 / ESnext) và biên dịch lại thành ES5, cần thiết để hỗ trợ các trình duyệt cũ hơn; Tôi đã xây dựng thêm một chút tại tsmean.com/articles/vs/typescript-vs-javascript cho những người quan tâm nhiều hơn một tl; dr
bersling

1
"Mã được mã hóa sẽ là mã JS hợp lệ" - và đó là gót chân Achilles của TypeScript nếu bạn hỏi tôi. Điều đó có nghĩa là họ không thể thêm một số tính năng rất hữu ích vào JS; đáng chú ý nhất là kiểm tra loại thời gian chạy . Thật khó chịu khi chỉ có an toàn loại thời gian của trình biên dịch để mất nó cho bất kỳ dữ liệu thời gian chạy nào được đọc từ I / O hoặc bất cứ khi nào mã được mã hóa của bạn được gọi một cách không an toàn từ JS khác.
Jez

44

" TypeScript Fund basicals " - một khóa học video đa năng của Dan WahlinJohn Papa là một khóa học thực sự tốt, hiện tại (ngày 25 tháng 3 năm 2016) được cập nhật để phản ánh TypeScript 1.8, giới thiệu về Typecript.

Đối với tôi, các tính năng thực sự tốt, bên cạnh các khả năng tốt cho intellisense, là các lớp , giao diện , mô-đun , dễ dàng triển khai AMD và khả năng sử dụng trình gỡ lỗi Visual Studio Formscript khi được gọi bằng IE.

Tóm lại : Nếu được sử dụng như dự định, Typecript có thể giúp lập trình JavaScript đáng tin cậy hơn và dễ dàng hơn. Nó có thể tăng năng suất của lập trình viên JavaScript đáng kể so với SDLC đầy đủ.


9
SDLC là gì? AMD?
Oooogi

15
@Oooogi, SDLC == Vòng đời phát triển phần mềm. AMD == Định nghĩa mô-đun không đồng bộ. Cái sau là đặc trưng cho JavaScript, trong khi cái trước là chung chung về phạm vi.
Dimitre Novatchev

2
"Dễ thực hiện AMD, ..." - Tôi đọc nó và nghĩ rằng đó là một loại tối ưu hóa luồng nào đó hoặc một cái gì đó.
jrh

15

Tập lệnh Ecma 5 (ES5) mà tất cả trình duyệt hỗ trợ và được biên dịch trước. ES6 / ES2015 và ES / 2016 đã xuất hiện trong năm nay với rất nhiều thay đổi vì vậy để bật lên những thay đổi này, có một cái gì đó ở giữa cần phải quan tâm đến TypeScript.

• TypeScript là Kiểu -> Có nghĩa là chúng ta phải xác định kiểu dữ liệu của từng thuộc tính và phương thức. Nếu bạn biết C # thì Typecript rất dễ hiểu.

• Ưu điểm lớn của TypeScript là chúng tôi xác định sớm các vấn đề liên quan đến Loại trước khi đi vào sản xuất. Điều này cho phép kiểm tra đơn vị thất bại nếu có bất kỳ loại không phù hợp.


2
Không phải là bạn thân mỗi năm! .. họ đã thay đổi thông số sau khi chờ đợi rất lâu
Subham Tripathi

... Và, những thay đổi mà bạn có thể tương quan với việc Microsoft có được những ngón tay trong đó. ;-)
Trober

2
@SubhamTripathi Nó rất nhiều mỗi năm. ES2015, ES2016, ES2017, và từ giờ cho đến khi ngôn ngữ chết. Nó không phải là mỗi năm, trước năm 2015, nhưng bây giờ là bây giờ. Tìm kiếm "quy trình TC39" để tìm hiểu thêm.
daemonexmachina

1
Có nhu cầu lớn về kiểm tra loại trong cộng đồng javascript không? Tôi chỉ không có nhiều lỗi liên quan đến kiểm tra loại.
Box và Cox
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.