Visual Studio Code

Introducing Type Checking

Visual Studio Code

Check out a free preview of the full Visual Studio Code course

The "Introducing Type Checking" Lesson is part of the full, Visual Studio Code course featured in this preview video. Here's what you'd learn in this lesson:

Mike introduces TypeScript's advanced type checking and error reporting functionality in regular JavaScript files.


Transcript from the "Introducing Type Checking" Lesson

>> Mike North: So we're going to dive into the next area of using visual studio code. And what we're about to talk about is type checking. So Javascript is it as well as called the dynamically typed language and that basically means we start worrying about the types of things only when we encounter like we're about to use it.

Right, so you get a value and you try to do something with it. Up until that point we don't care about the types of things. Types exist, if you've ever used type of, you can see like there's some things undefined or a function or a strength. So it's not untyped.

I mean, people use that word but really it's dynamically tight or duck tight. So let's talk a little bit about type checking as it pertains to the modern web and Javascript these days. Let me bump my phone up a little bit. So Visual Studio Code. It is written mostly in TypeScript and TypeChecking in general has become really popular as of late.

So if you've used react before and gone through the official tutorials, you will see that proptypes was formerly part of the react library as a whole. It's been refactored out into another library now. But this did what is called run time typechecking. So if you pass things to a component, the types of those things that you passed to the component are verified to make sure that you have alignment with what that component is aligned to receive.

Facebook also has a project called flow. And if you watch Brian Holt's Complete Introduction to React, version three, I believe this uses flow. And this is static type checking, which is similar to what TypeScript gives us. And TypeScript, of course it's a programming language and a library. That is built and maintained by Microsoft.

And one of the advantages of static type checking is there is no cost when your program is actually running. This is sort of, it's an advantage in terms of making sure that this eventual product of our programming efforts is fast and it ends up like having no extra weight added to it.

But it also comes with a disadvantage that we can only do so much with static analysis. Static analysis really doesn't it doesn't tell us the full set of things that could potentially go wrong with our code. Just kinda looking at all of the obvious usages without worrying about all of the particular, like paths that we can take through all the different functions and all the different objects of our code, right?

You need dynamic analysis for that. So, We're gonna be talking mostly about type script today but these concepts, this hold true for anything that cares about types. A lot of what we're gonna be dealing with today holds up equally well when dealing with something like flow or closure compiler that is an old Google project for taking some raw JavaScript and creating a minified, optimized build.

There are signs that it's sort of coming back and that a rewrite is underway, and that we might see a reboot of closure compiler. But that also involved adding type information, so there was potential to optimize in type-specific ways. So type script is, I say it's a tight superset of JavaScript, meaning that by default, most JavaScript will work, as long as it can be kind of interpreted in a strongly typed way, most JavaScript expressions will work.

There are some that won't, for example, if you had the number five double equals the string with the number five in it, in a strongly-typed world, there's really no way to deal with that kind of comparison, right? In the strongly-typed world, that's apples and oranges. Its strings and numbers.

So type script relies heavily on type inference which basically starts with some of the most obvious to determined types in your code and expands that information outward in order to figure out larger higher level type information. For example, if you say I have a variable x and that it's initial value is 65, we can say well yes, that has a type of number.

And if we have a function that eventually returns that, we can say okay, well this function returns a number. We can kind of like expand out relay and use some explicit type information that we can get some you know value literal to you know then determine like what's going on with this function, what's going on with object and you know detect and deduce.

What various types may be involved in other places. So an important part of this were these type definitions that we've been looking at, .d.ts files where we had the DOM API and we had object.freeze. We looked at that type definition. So this also, whenever you use one of those, that immediately gives TypeScript a clue as to like how this might be used cuz those functions were turn a particular type or they take a certain type of argument and like deductions can be made there.

One of the core missions of type script is you opt in to a type system here. It is not a situation where you need to like rewrite all of your code. The hope is, one of the happy paths to starting to use type script, is you take you JS files, you rename them to .ts files.

Files so they're type script and most of your code should work right away. Now you may get a ton of warnings and you may need to supply clues where type inference is not enough to figure out what's going on but it shouldn't be a situation where you must go through and explicitly define as much as possible.

So this here as Typescript 2.3 which was only a couple months ago, visual studio code can apply this type analysis to regular Javascript. You don't need to be using type script files. It will make as much sense as it can. Out of your regular Javascript and we can add comments in a way that are not going to disrupt treating these files as regular Javascript.

So if you have an existing project and maybe some subset of your code is particularly complex and type information would go a long way in order to like maintain order in that area. Maintain like that you're doing things in a consistent way. You can up in to, using type analysis in that are of your code without having to bring in the TypeScript compiler to process your files and to like you now have the whole rest of your team learn a new programming language.

It's just comments, it's just inert stuff that is not technically code, it's just sort of clues around your code. So we're gonna use these JSDoc comments. And Closure Compiler also uses JSDoc comments, so this is another example of like Let's adapt an existing standard, an existing way of doing things.

Closing compiler, I was using it last 2007, 2008 so that's been about ten years and it still works so let's keep using it. We don't need a new method to do this kind of thing.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now