Check out a free preview of the full TypeScript 5+ Fundamentals, v4 course

The "Explicit Function Return Types" Lesson is part of the full, TypeScript 5+ Fundamentals, v4 course featured in this preview video. Here's what you'd learn in this lesson:

Mike discusses best practices for functions in TypeScript. Without an explicit return type, errors may pop up in unexpected places, making it difficult to track down and fix the issue. The value of explicit return types, even if it may require extra typing is also discussed in this segment.

Preview
Close

Transcript from the "Explicit Function Return Types" Lesson

[00:00:00]
>> All right, the last thing I want to wrap up with here is just best practices for functions. So first, I feel like I have some dead code in there. I do, this shouldn't be in here, sorry, folks. So here's an example that illustrates why having explicit return types is valuable.

[00:00:32]
So let's say that we have a function as follows. And here, we're sort of like awaiting a response to come back from the fetch that we're making. And then here, we're saying, okay, let's wait for the last byte of the response to come in, serialize it into JSON.

[00:00:49]
So wait for all of that to happen. And get the data here, properties, it's a string array. And here we're gonna load the data, which is calling this getData function. So what if we were to add a branch or a condition around this that says okay, I only wanna wait for the data to come in and to return it if the response is okay?

[00:01:16]
If I have a status code that is below 400, right? So I get an error here, says result is possibly undefined. And this is where I would say the error's popping up in the wrong place. It's not an ideal place for the error to pop up. Because, imagine that getData is used in 100 places throughout a piece of code.

[00:01:46]
And we just added that little change, and now errors light up all over the place. We're gonna have to go to those call sites and track down what's going on. Figure out what's happening here. If we have an explicit return type, we could surface an error right at the declaration site.

[00:02:04]
And what it would look like is the following. It's a promise, and we'll talk about this syntax in a bit. It's a promise that resolves to, An object containing a properties field and a string. If you look down here, error is not popping up here anymore. So we're effectively saying we have an upfront commitment to return a particular thing.

[00:02:37]
And we have not lived up to that commitment. And now we've got not 100 errors, we've got one error, and that one error is actionable. It's in the place where a fix needs to happen. I mean, if you wanted to intentionally return an undefined, I would advise that you explicitly state so here, and then go and fix all of the call sites.

[00:03:00]
But to me, this is a lot more useful. And it's why I sort of have a bias towards explicit function return types. I've just gone on the wild goose chase too many times. And this is just, regardless of what your preference is, I think there's a point where searching around for the source of a bug.

[00:03:22]
Like there's a point where this kind of pays for itself, even if it looks ugly to you and feels like it's extra typing to provide.

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