Check out a free preview of the full TypeScript Fundamentals, v3 course:
The "this Types & Best Practices" Lesson is part of the full, TypeScript Fundamentals, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Mike discusses how to handle and invoke a function that uses a this element, such as a click handler. A this type needs to be created in order for TypeScript to know which element this is talking about. Best practices for coding function types by explicitly defining return types is also covered in this segment.

Get Unlimited Access Now

Transcript from the "this Types & Best Practices" Lesson

[00:00:00]
>> So, when we talk about this types, what we mean is the type of this within a function when it's invoked. And this has the most relevance when talking about freestanding functions because methods on classes, they kind of already have this wired up in a convenient way. Here is example of what we might care about this, so a button or a DOM element of any kind.

[00:00:28] If we wire up a handler, like a click handler of some sort, when the buttons clicked, this function will be invoked and this within the function will be whichever DOM element emitted the event. So, if we tried to operate on that, we would kinda be busted on it because what we're being told here is look, I don't know that you wired up my click handler to a Dom element.

[00:01:00] Like you could be using it that way or a different way, but you can't start consuming this, unless you tell me what it should be, so I can help you stay on the tracks, right? And use it responsibly, so in this case, we happen to be fine, because we have no opinion about this, right?

[00:01:25] We can directly invoke it takes the argument as it should, but it's the use of this that's kind of causing an error message to pop up. So what we need to do is define what's called a this type and it's sort of just an argument that's passed behind the scenes, which makes sense to me because that's kind of, when you think about how function apply, function call works, right?

[00:01:52] We pass this along with the arguments there, it's part of the information that goes to the function when we want to invoke it, so it kind of makes sense that it's included alongside the arguments. And now we can see that we're fine and, in fact, that's the type of this it's an HTML button element.

[00:02:13] And down here now we're busted on that, because the only safe way of invoking this click handler It would be either using function call like that, or creating a bound version of the function. And if we look at this bound handler, it may not show it on the tooltip, no, it does show it on the tooltip, so now notice that my click handler has this HTML button element.

[00:02:42] While the act of binding this, it means that we're creating a new function that doesn't care about which this, is being used because we're baking the right context into that function that bind returns. So it makes sense that this bound handler, you can just pass it in an event, because it's already got the right this.

[00:03:08] If anyone here have seen this pattern before, where you're doing function bind, to hook things up to DOM elements, maybe in a react component, right? This is kind of a common way of like you pull methods off of your class and you say this dot action equals this dot action dot bind, so there you go, this is the kind of thing we're talking about here.

[00:03:37] And bind call and apply, at least for modern versions of TypeScript, should work very very nicely with the concept we just talked about. So, let's end our section on functions by talking about best practices, I already asked you to explicitly define return types. So, here's an example of a piece of code, where if we made what appears to be an innocent change, so you see here we're fetching some data and then if the promise resolves, we'd like to log it to the console.

[00:04:12] What if over here, when we decode the body of our response, we start to only do that for successful responses only, right? We add a guard around it. Errors would start to pop up, where we consume the result that the promise resolves to, right? You start to see these errors where they break as opposed to where you need to fix it, right?

[00:04:44] This is the change, right? Get data now has the possibility of returning undefined, you can see it right in the tooltip or promise that resolves to undefined. I'd like my errors to pop up closer to where I must fix them, we did talk about that a little bit.

[00:05:04] And so, this is what you would see if we had this explicit return type and this error right on the function, and it's really clear how we can address it.