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

• ther 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

• ne 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

TypeScript declaraCon files By convenCon their extension is dot D dot TS They perform a funcCon similar to header files from

• ther languages

If necessary they can be wriRen by hand for exisCng JavaScript libraries For most popular public JavaScript libraries this is not necessary, as a large number have exisCng declaraCon files are freely available at definitely typed.org.

42

Look on the website definitely typed.org for many declaraCon files for a huge list of popular public JavaScript libraries

43

For this example suppose we have an exisCng JavaScript file that defines an animalFactory. The animalFactory contains a single method called create which takes as parameters a name string and

• pConally a height number and a weight number and

returns an object of type animal. This is captured by the typescript declaraCon file on the le`. On the right we see some usage examples, three valid followed by one invalid.

44

45

A few words about funcCons in TypeScript…. They’re quite similar to funcCons in JavaScript, with a few extra features. Both parameters and return value can have type annotaCons. Parameters can be marked as opConal by a trailing quesCon-mark (“?”). Parameters can be given a default value when declared.

46

TypeScript FunCons Here’s a simple example of adding two numbers. We have type annotaCons much like what we’ve seen before. The funcCon itself also has a type, which is based on the “shape” idea. Quanity, type, & sequence of parameters, plus type of return value.

47

TypeScript FunCons, OpConal Parameters In JavaScript, every parameter is opConal, and users may

• mit them at call Cme as they see fit. When they do,

their value is undefined. We can get this behavior in TypeScript by adding a ? to the end of parameters we want to be opConal. In this example, the last name parameter from above is opConal. Any opConal parameters must follow required

• parameters. Had we wanted to make the first name
• pConal rather than the last name, we would need to

change the order of parameters in the funcCon, putng the first name last in the list.

48

TypeScript FunCons, Default Parameters We can also set a value that a parameter will be assigned if the user does not provide one at call Cme, or if the user passes undefined in its place. These are called default-iniCalized parameters. Here we have modified the previoius example and defaulted the last name to "Smith". Default-iniCalized parameters that come a`er all required parameters are treated as opConal, and just like opConal parameters, can be omiRed when calling their respecCve funcCon.

49

Typescript generics What problem do they solve? They’re used when a funcCon or class needs to work with a variety of data types.

51

Here’s a simple example We define a simple idenCty funcCon which returns the parameter passed in. This should work regardless of the parameter type. The two usage examples both show it working with a string passed in. In the first case the string type is explicitly declared. In the second case the string type is inferred.

53

We can use the same example to illustrate some issues that can occur. Here we had added one line to print the length of the passed in parameter. But the parameter can be of any type; it may not support a length property or method. In that case TypeScript will give us a compile Cme warning. The danger is equivalent to JavaScript but the warning

• ccurs earlier.

54

This example shows how we can fix the problems from the previous one. Here we want to ensure that the passed in parameter has a length property. We define an interface with name “hasLength” and explicitly state that the generic type must extend that interface. This allows a very rich expression of intent which is valuable to (1) any human coder who must understand this code and also to (2) tools which must support navigaCon and modificaCon of this code.

55

Typescript offers a convenience called string interpolaCon. As a convenience typescript will evaluate expressions, inside of strings, which are wrapped with braces, preceded by $, and will then insert the result into the string.

56

Because TypeScript compiles to plain old JavaScript, it results and absolutely no changes to HTML nor CSS.

57

Script currently has very rich support and it’s constantly expanding. With a Microso` product, as you would expect, it is fully supported in Visual Studio, and it also enjoys rich support in a large number of IDEs as shown here. Microso` has also produce a product called VS Code, which is a version of Visual Studio but wriRen enCrely in node.js. It has very rich support for TypeScript.

58

Here is a screenshot of the VS Code IDE running on Macintosh

59

Here’s a screenshot of the Atom IDE running on Macintosh

60

This screenshot shows some of the informaCve displays that pop-up as the cursor hovers over source code in a type script IDE like VS code

61

Here are just a few of the features offered by VS code

62

Type script is open-source Any browser, any operaCng system, any plaoorm

63

Here are some valuable resources. I strongly recommend the YouTube video of Anders Hejlsberg presenCng at Google.

64