Lets talk about TypeScript Ive only been working with TypeScript - PDF document

Let’s talk about TypeScript I’ve only been working with TypeScript since the first of the year, so some of you may know more about it than I do. If so, great! You can keep me honest and help answer quesCons from everyone else. My aim here today is to give a fairly high-level overview. What is TypeScript? Really simple descripCon is JavaScript plus types. Of course there’s more… 1

ECMA goes way back. JavaScript was subject of much compeCCon in its early history. StandardizaCon was the seRled-on soluCon. Current version, ECMAScript 5, enjoys nearly universal support. Next version, ECMAScript 6, has widely varying levels of support across different browsers. 2

This URL gives a preRy up-to-date status for browser support of ES6. To determine whether you can use ES6, you need to know which features are important to you, and also which browsers you must support, then scan the table and find where the features and browsers intersect. If all those cells are green, you’re good. If not, complicaCons will arise. If you only need to worry about very new desktop browsers, things look good. If you have to support older browsers, or mobile browsers, the picture gets more complicated. 3

Why change anything about JavaScript? -Top reason: large projects in JavaScript are hard. -Dynamic typing can be great for small efforts, but can turn large efforts into (effecCvely) read -only code. -No built-in support for modularity. We tend to develop fairly verbose paRerns to surmount other limitaCons. Perhaps most important: developer intent is o`en not clear. We need an ability to reason about code intelligently. - developers need it - tools need it too. 4

What’s good about JavaScript? Omnipresent. More libraries than I can count. Extremely flexible. These comments mostly apply to ES5. 5

We can expand on our earlier simple definiCon of TypeScript. Addresses large scale JavaScript development issues. Compiles to plain old JS. BeRer expression of developer intent. Next, let’s discuss the origins of TypeScript…. 6

Typescript originated at Microso`, which carries a wide variety of connotaCons…. 7

Created by Anders Hejlsberg, who has a good track record. He has worked on many well known and successful projects. 8

TypeScript is very open. Clearly this is not the old Microso`! 9

The approach the seem to have is: - keep the good parts of JavaScript - add staCc types, plus other features - add IDE support and tooling - compile back to plain old JavaScript (ES5) 10

TypeScript is well supported by a wide variety of IDEs. SomeCmes with plugins or other add-ons, but the results are o`en very good. My personal favorite is Atom. I have also used VSCode from Microso`, and the PalanCr plug-in for Eclipse. 11

Some of the examples (including the next one) will use screen shots from this IDE: Atom. Hit “atom.io” in your browser if you’re interested. Easy to try. Great TypeScript support out-of-the-box. 12

Here’s an example of IDE tooling for Typescript. ( autocomplete AKA intellitype AKA intellisense ) This screenshot is taken from Atom on Mac OS. As the user edits a file, on the right side of an assignment they type “Math.”. A pop-up appears that lists available properCes and methods. The user can simply navigate to the one they need. They are relieved from the small (but real) extra cogniCve load of (a) remembering all those properCes and methods, or (b) taking acCon to look them up. A single Cme, that’s a small saving. MulCplied over days and weeks, it becomes a substanCal saving, not merely in Cme saved but also in errors avoided. 13

We can say more now about TypeScript. Recent release dates. 14

Here is a list of features of TypeScript Many of the features proposed as part of ES6. We’ll examine these as we proceed. 18

I should menCon the TypeScript Playground. It’s a purely web-based small IDE. Set-up effort is about as small as you can get. Great way to learn about and become familiar with TypeScript. 19

Arguably most basic, also most important, feature -- Type AnnotaCons. Visually these are fairly small addiCons to your code, and when your code compiles down to plain old JavaScript they all get stripped away, so they add zero run-Cme cost, but they add huge value by enabling the compiler to automaCcally check for many kinds of errors, and also by conveying developer intent to subsequent modifiers. 20

This slide illustrates the value of Type AnnotaCons. Both lines will compile, and both lines will produce the same error at run$me . But the JavaScript error will not be seen unCl runCme; the TypeScript error will show up at compile $me . So the error is seen earlier, and can be fixed earlier, requiring fewer mental context switches from the developer. 21

Inference Even without declaring types explicitly, TypeScript offers some benefits by inferring types based on visible usage. In both of the these examples, an error will be shown at compile Cme. Both examples sCll compile to runnable JS. That is the norm for TS, even if it produces warnings and errors. 22

Here we show some of the built-in support for basic types: Boolean, Number, and String are preRy straighoorward. We have two supported syntaxes for Array types. Enum types are also straighoorward. They will start enumeraCng from zero unless you specify a different starCng value. They also offer you complete control over the values used if you choose, as shown in the third example. 23

“Any” is a basic type which tells the compiler to default to standard JavaScript behavior. I.E., we can’t assume anything about this type. Finally, “Void” signals the explicit absence of a type. 24

TypeScript Interfaces What problem do they solve? They begin to move beyond basic primiCve types and get more advanced. They describe anything that has properCes and methods (i.e., an object). 25

First, in the parameter list for the greeter funcCon we see a type annotaCon just like what we’ve seen before. In this case the type “Person” is actually referring to an interface that is defined above. It’s defined to have - three properCes that are all strings, - one of which is opConal (denoted by the “?”), - one method, with no parameters, that returns a string. 28

TypeScript Interfaces They describe anything that has properCes and methods. Two things are considered compaCble if they have the same “shape”; i.e., numbers and types of members. Having differing names, or addiConal members, does not interfere. The name of an interface is not really significant, but rather what TypeScript users refer to as the “shape”. This is the number and types of the properCes and methods. Members can be defined, but considered opConal, if their name is followed by “?” a quesCon mark. 29

TypeScript Interfaces What problem do they solve? Bring full-fledged object oriented programming to JavaScript InstanCaCon Inheritance Extensibility 30

To see a TypeScript class let’s return to the same example as before… We see a class of name “Student” which implements interface “Person” because it has the same “shape”. (Remember, “shape” refers to the numbers and types of members.) We can see that it has an explicitly declared method “getFullName” that matches that of interface Person. It also uses the constructor “public” shorthand to declare properCes “firstname” and “lastname” of type string. So it matches the “shape” of interface Person. 33

TypeScript supports the current ECMAScript six proposal for class-based object oriented programming. This means: - It can implement interfaces - It has inheritance - It can have instance and/or staCc methods and members 34

Here we show, on the le`, some of the TypeScript from the previous example, and, on the right, the JavaScript that results when it is compiled. Not all lines are shown; those below the boRom line, funcCon declaraCon “greeter,” are idenCcal in both files. I added some line returns to make text fit on screen beRer. 35

Typescript modules What problem do they solve? They offer a way to organize code They can minimize cluRer in the global space And finally they can divide code across mulCple source files. 36

Here we have a basic example of a type script module On the le` is some code with no modular organizaCon It contains some variables, an interface, and a class The class is invoked on the boRom line On the right we have the same elements organized into a mpdule. Global namespace is reduced because all the idenCfiers are now isolated to the module namespace, except for those that we explicitly export. Now when we invoke one of those idenCfiers outside the module we must supply the module name, as shown. 38

The module from the previous example shown on the le` of this slide. On the right we illustrate how this can be divided into mulCple files. For a small code sample like this it offers liRle value, but for a large code base the value can be significant. 39

TypeScript declaraCon files What problem do they solve? They help us interface with exisCng JavaScript. 40