Check out a free preview of the full TypeScript 3 Fundamentals, v2 course:
The "Call & Construct Signatures" Lesson is part of the full, TypeScript 3 Fundamentals, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Mike demonstrates how to utilize an interface to describe call and construct signatures.

Get Unlimited Access Now

Transcript from the "Call & Construct Signatures" Lesson

[00:00:00]
>> Mike North: We can use an interface to describe a call signature. And we're simply using parenthesis here to this describe a function. Now, what we're starting to see is interfaces can describe objects, interfaces can describe functions. In a moment, we'll see that interfaces can describe arrays. So we're dealing exclusively with JavaScript values that extend from the JavaScript object type.

[00:00:31] We've not yet seen, and we won't see, an interface being able to handle primitive types, or operators used with types, like string or number. There is no way to describe that with an interface. So that's one clear difference we're seeing here. Type aliases are extremely flexible. They can handle the primitive stuff.

[00:00:53] They can handle most things that an interface can handle. Everything that an interface can handle. But interfaces are limited to JavaScript object and sub types which includes arrays and functions. Things that have prototypes, think of it that way. So here is a function signature. And here is the equivalent with the type, right?

[00:01:17] The wrapping is a little unfortunate here, but same idea. This is one signature and the only difference I wanna really point out cuz it's a little subtle, the return is void here, :void. And just to make parsing possible, we use a fat arrow here to define a function type with a type alias, this would not be valid.

[00:01:52]
>> Mike North: One cool thing about function types, a little prettier it's supposed to be right here. One cool thing about function types is we get something called contextual inference. So we've already defined this type. Contactmessenger1. That's right up here, right?
>> Mike North: It turns out like we don't need any additional work.

[00:02:18] No additional type information in order to figure out what the return type should be. What should these arguments type be. Or what should the argument times be. That's all coming along for free because that information exist here. You'll see the same benefit come through with call backs, right?

[00:02:34] If you say I accept the call back and it's value like the signature should be this. Now, at every invocation site, every time you pass a call back along, you can forget the type information. The type checking still happens exactly as it would, but you don't need to be so explicit along the way.

[00:02:57]
>> Mike North: Construct signatures look very similar to call signatures. All you need is new head of that. You're used to seeing this in a class, right? Classes are something, they're new-able, we can use the new keyword with them. So this would be a way of describing a constructor that instantiates either things that have an email address or a phone number, and definitely have a name.