Importing & Exporting Types

[00:00:00]
>> Anjana Vakil: So, for example, in events.ts, this is somewhere where I would love to be able to tell TypeScript to please stop yelling at me about these implicit any by giving it an event But interestingly, if I do that, it says host ID does not exist on event And if I go to the.. Sorry, what I just did there is I want to see what is this interface event that it knows about

[00:00:45]
How did it know about it Where was it defined Is it the one that I wrote And sure enough, if we go to the.. So what I just did is I clicked on, I right-clicked on the event or on the event type itself, or I could go to the actual instance here, and then there's an option in VS Code to go to type definition, which I can click, and now it's taking me not to my types file, but to node_modules, @types, blah blah blah blah blah blah, and this is sure enough looking like it's something else that is coming from the browser idea of what an event is, a click or a scroll

[00:01:38]
Thank you I could not think of one single other thing you could do on a browser But so once again, we've got to make sure that TypeScript knows exactly what event we're talking about We don't want it to be the built-in And so we want to make sure that right here it's like, "Well, I don't know what other events you're talking about, so let's make it be the browser event," and then it's confused

[00:02:05]
So if I go back to my types file, sure enough, we do have a host ID, and yet this is all grayed out because we declared this, but we never actually used it anywhere because this is just declarations and not actually annotating anything as having this type So similarly to how I could write a bunch of functions in one module and use them in another by using imports and exports, we can do the same thing in TypeScript with types

[00:02:44]
So we can share types between modules by importing and exporting them, similarly to how we import and export functions and other things in JavaScript It's just that we're going to have an extra word when we're importing types When we import values, we can say import and then often it's like curly braces, and then whatever this module exports We can also import only types

[00:03:19]
So for example, if I have some module that doesn't exist, values.ts, that exports a type for me, I can import that in another module with import whatever blah blah, and then type the type I want Or if I just want to import a whole bunch of types without having to rewrite type, type, type, type, type, I can put the type keyword before the curly braces, and everything within the curly braces, TypeScript will understand that we're just importing the types for that

[00:03:55]
We're not looking for like values that would exist at runtime in our JavaScript So without the type keyword, regular JavaScript importing, whatever it is, functions, classes, you name it With the keyword, just the type So that means that hopefully we need somewhere to be exporting types as well And just like we can export variables or functions or what have you in JavaScript, we can export types in TypeScript by putting the export word in front of the thing that we want to export

[00:04:46]
And then we can import those types either.. If we're importing a bunch of types, we can just put one type keyword in front, or if we just know that like we want a bunch of values and things from some other module, but one of those is extra type information, we can put the type keyword before just that type, and then we get to use them normally in our TypeScript code here

[00:05:18]
So if we go back to our types.ts and add an export in front of this interface, it stops being grayed out Similarly to how you might have like sometimes get "oh, unused variable, whatever," if you export it, JavaScript is like, "Well, I guess you could be using it somewhere else, so I am no longer bothered." And similarly, TypeScript is no longer bothered because we might be able to use this somewhere else, like, for example, in events.ts, source routes, event.ts

[00:05:50]
You feel me And so now we can add, just like we're importing functions like get user from users.ts or we're importing utilities that we need, tools and whatever, from our various other helpful dependencies, we can do import type event from.. Hmm Huh, okay, so maybe I was a little too quick here, but if we start typing, then it actually is going to autocomplete for me and say, "Hey, did you mean you want the one from that types.ts that's in that directory yet?" And I'd be like, "Sure did, thanks VS Code," and press tab, and it autocompleted the rest of the line for me

[00:06:45]
So if I save now, I see that I have one squiggle fewer in my file, which I'm going to take as a massive win, because again, there's a lot of squiggles I'll take 11 down, 90 million to go All right, so we can keep using this as we are used to doing anywhere where we might need an event And here's one where maybe we're getting a little bit of a preview here, which we'll get to in a moment

[00:07:25]
Now we've got something like an event ID that we want to get, and if we look at our types here, we didn't.. We could have, for example, made an ID type alias Yeah, like type ID We did this a couple other places, equals.. I don't know, number or maybe we want it to be number or string, and then we could use that here Yeah And we can export that and add it here to our import statement

[00:07:59]
ID And now we're starting to get the sense of like if I want to keep importing type after type after type after type that I'm going to get a lot of the type keyword here So I can also do this in front of the curly brackets to save me the headache But essentially for right now, we have a handful of types and we're going to need to use them in different places

[00:08:23]
So it would be.. It kind of makes it, at least for me as a developer, a little bit easier if I can see all the types I'm working with are coming from one place, and I don't need to be like, "Did I declare this one over here, or was it in that module, or was it in this module?" So for our purposes, for this size, very small of a project, we can leave them all in types

[00:08:48]
And I think for now it's good to be very explicit about the types that we are importing in each module for the same reason that we don't want to be importing like things that we end up not using because not only, yeah, there might, you know, in JavaScript there would be performance, but readability, maintainability, all that stuff matters too So we're going to keep doing it this way for now, but it's a great topic to explore in more depth

[00:09:27]
Okay, now, since we have our ID, we can give one less any to TypeScript, and we still have some problems We have some problems, and we're getting some things like unknowns and things we don't expect And okay, ID here now is something else that's coming back from some kind of.. This is now coming from the types that we got from SQLite, our better-sqlite3 package, and so this is now our work as developers

[00:10:01]
We're kind of going to have to drill into all of these errors, figure out what's going on, and make sure that we're getting types for the things that we need in the places that we need them.