Announcing #TypeScript 2.4 #RC

Server & Tools Blogs > Developer Tools Blogs > TypeScript
Sign in Menu
#TypeScript
TypeScript
Announcing TypeScript 2.4 RC
โ˜…โ˜…โ˜…โ˜…โ˜…โ˜…โ˜…โ˜…โ˜…โ˜…โ˜…โ˜…โ˜…โ˜…โ˜…
June 12, 2017 by Daniel Rosenwasser // 0 Comments

91
1
Today weโ€™re releasing our RC of TypeScript 2.4. To get started with the latest stable version of TypeScript, you can grab it through NuGet, or use the following command with npm:

npm install -g typescript@rc
Visual Studio 2015 users (who have Update 3) can install TypeScript from here, and Visual Studio 2017 users using Update 2 will be able to get TypeScript by simply installing it from here.

To get it working elsewhere, you can easily configure Visual Studio Code and our Sublime Text plugin to pick up whatever version you need. Other editors may have different approaches to swapping TypeScript in.

Dynamic Import Expressions
TypeScript 2.4 is bringing support for ECMAScriptโ€™s new import() calls. These calls import a module and return a promise to that module.

For example, imagine a webpage that allows you to create and edit images. When youโ€™re working with one file, the page will allow you to download that file immediately; but if youโ€™re working on multiple images, you can save all of them as a .zip file.

You might have a utility library to create a zip file, but since downloading multiple files isnโ€™t that common, youโ€™d want to load that functionality lazily. import() expressions let you load a module on the fly as a Promise like so:

async function getZipFile(name: string, files: File[]): Promise<File> {
const zipUtil = await import(‘./utils/create-zip-file’);
const zipContents = await zipUtil.getContentAsBlob(files);
return new File(zipContents, name);
}
This feature is so incredibly useful in situations where you want to conditionally import modules. Projects that use bundlers like Webpack can operate on these import() calls and split code into smaller bundles that can be lazily loaded.

What all of this means in the end is

you can send less JS over the wire for more common scenarios
your users can get faster page load times for critical content
Safer callback parameter checking
When checking whether two functions are assignable to one another, TypeScript checks whether their parameters are bidirectionally assignable. We call this function parameter bivariance. There are a number of reasons for this, but it mainly stems from TypeScriptโ€™s structural nature and how weโ€™ve tried to match peopleโ€™s intuition.

Our experience has been that users generally donโ€™t run into issues with this all that much; however, we did start to see that this model broke down on containers which handed internal data off through callbacks โ€“ specifically, Promises. For example, a Promise<Animal> was assignable to Promise<Dog>, which is incorrect. You can see similar behavior in the following sample:

interface Animal { animalStuff: any }
interface Dog extends Animal { bark(): void }

interface BasicCollection<T> {
forEach(callback: (value: T) => void): void;
}

declare let animalCollection: BasicCollection<Animal>;
declare let dogCollection: BasicCollection<Dog>;

// This should be an error, but TypeScript 2.3 and below allow it.
dogCollection = animalCollection;
To solve this issue, TypeScript 2.4 now tightens things up and compares the parameters which are callbacks specially. When checking callbacks, TypeScript will be strict about checking parameters contravariantly with respect to the current check. Parameter bivariance still applies otherwise, but we found this to be an effective safety check without drastically changing the type system.

Since this may be a bit technical, you can read more on the original pull request. The short story is that youโ€™ll see much better checking when using Promises, Observables, and anywhere else youโ€™ve been using callbacks.

Be aware though โ€“ this new check can introduce new type-checking errors in existing codebases. For more details, see our Breaking Changes section.

Weak types
Back in TypeScript 1.6, we added a check for excess properties in object literals. This check looked for unexpected properties in object literals, and it happened to catch a large class of bugs. The only shortcoming of the check was that if you didnโ€™t immediately pass your object literal to something of the appropriate type, the check wouldnโ€™t be triggered.

In TypeScript 2.4, weโ€™re adding a similar check for what we call weak types. Any type that contains only optional properties is considered a weak type since it provides few restrictions on what can be assigned to it. For example, this Options type is a weak type:

interface Options {
data?: string,
timeout?: number,
maxRetries?: number,
}
In TypeScript 2.4, itโ€™s now an error to assign anything to a weak type when thereโ€™s no overlap in properties. For example:

function sendMessage(options: Options) {
// …
}

const opts = {
payload: “hello world!”,
retryOnFail: true,
}

// Error!
sendMessage(opts);
// No overlap between the type of ‘opts’ and ‘Options’ itself.
// Maybe we meant to use ‘data’/’maxRetries’ instead of ‘payload’/’retryOnFail’.
You can think of this as TypeScript โ€œtoughening upโ€ the weak guarantees of these types to catch what would otherwise be silent bugs.

Since this is a breaking change, you may need to know about the workarounds which are the same as those for strict object literal checks:

Declare the properties if they really do exist.
Add an index signature to the weak type (i.e. [propName: string]: {}).
Use a type assertion (i.e. opts as Options).
String enums
Enums were an early feature TypeScript provided that have been handy for marking a set of well-knwon related numeric values.

enum E {
A = 1,
B = 2,
C = 3,
}
In TypeScript 1.8, we also released string literal types which could be used in a union.

function setStatus(status: “ready” | “running” | “finished”) {
// …
}

setStatus(“ready”);

setStatus(“stopped”);
// ~~~~~~~~~
// Error: Type
//
// ‘”stopped”‘
//
// is not assignable to type
//
// ‘”ready” | “running” | “finished”‘.
There were benefits to both constructs, but each group of users wanted some functionality from the other.

For example, string literal types serialize very well over transfer protocols and during debugging โ€“ after all, theyโ€™re just strings. But this isnโ€™t the case for numeric enums, which end up as plain numbers with obvious meaning.

But string literal unions can be cumbersome for more advanced scenarios. If you want a well-known set of constants for each string, then you typically have to declare them yourself.

Thatโ€™s why for TypeScript 2.4, weโ€™re introducing string enums!

enum ActionType {
AddUser = “ADD_USER”,
DeleteUser = “DELETE_USER”,
RenameUser = “RENAME_USER”,

// Aliases
RemoveUser = DeleteUser,
}
String enums have a simple representation, but come with the caveat that they donโ€™t create a reverse-mapping. In other words, you canโ€™t index into ActionType with the string “ADD_USER” (by writing ActionType[“ADD_USER”]) to get the name of AddUser.

Have fun!
You can see the full list of whatโ€™s new in 2.4 here on our wiki.

Then give TypeScript 2.4 RC a try and let us know what you think! If youโ€™re having an awesome experience, use the #iHeartTypeScript hashtag on Twitter and let us know.

If you run into any places you think we could improve, weโ€™re always all-ears on suggestions.

Download Visual Studio
Download Visual Studio Code

Search this blog Search all blogs
Share This Post

ShareShareShareShareShare
Recent Posts

Announcing TypeScript 2.4 RC June 12, 2017
New TypeScript Quick Starts and Updates from Build 2017 May 19, 2017
Announcing TypeScript 2.3 April 27, 2017
Announcing TypeScript 2.3 RC April 10, 2017
RSS Live Now on Developer Tools Blogs

LLBLGen Pro for .NET and .NET Core โ€“ Database Entity Modeling with any ORM
Because itโ€™s Friday: Subway maps to scale
Schedule for useR!2017 now available
Tags

0.8.1 debugging release typescript VisualStudio walkthrough interfaces
Related Resources

Visual Studio Developer Center
Visual Studio Product Website
Archives

June 2017 (1)
May 2017 (1)
April 2017 (2)
March 2017 (1)
February 2017 (2)
December 2016 (2)
All of 2017 (7)
All of 2016 (11)
All of 2015 (16)
All of 2014 (8)
All of 2013 (16)
All of 2012 (3)
Join the conversation
Add Comment
ยฉ 2017 Microsoft Corporation.
Terms of Use Trademarks Privacy & Cookies

Source: Announcing TypeScript 2.4 RC

Advertisements

Published by

Engineer IP Dev Crash Browser

Dad #engineering automatic ๐Ÿš€๐Ÿš€๐Ÿš€๐Ÿš€๐Ÿš€๐Ÿš€๐Ÿš€๐Ÿš€๐Ÿ‡ฒ๐Ÿ‡ฆ https://www.freecodecamp.org/barkinet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s