Transcript from the "Challenge 2: Account Manager" Lesson
>> Mike North: All right. So, this is our second exercise here. And in this exercise we're going to really be working with interfaces more than just those explicit type annotations. So, you're gonna open up the exercise folder. There's a sub-folder in there called accounts. You're gonna run npn test accounts and that'll start your tests up.
[00:00:22] And what you've got here think of it as the, a like authentication system for like a blog or something like that, where you can register a new user, you can try to log a user in and you've got two concepts. You've got a user and an admin. So you're gonna want to design interfaces as appropriate for structures that represent what various, accounts in certain states look like.
[00:00:52] So users have an email and a password. When a user is activated it gets an is active property and that will have a value of true. Admins additionally have an admin since property which is a type of date. So I'll let you figure out how to do that.
[00:01:09] You can experiment. Export the interfaces from the account manager file as IUser and IAdmin. So you can export an interface the same way you can export anything else. Update the account manager class that has been started for you such that any type mismatching is caught by the typescript compiler at build time.
[00:01:30] And you should see a bunch of red squiggles in that file if you look right now. It should be complaining.
>> Mike North: And so just to be clear like a new user registers for an account and administrator has to activate them, at which point they can log in, and an administrator can also promote a user to admin status, so you sort of got a couple different states, a user that just signed up, a user that is confirmed, and then a user that's an admin.
[00:02:00] So there are three potential structures you have to think about. So apply interfaces and snuff out all of the complaints in this file that you're getting from TypeScript which should largely be based around implicit anys. Yes?
>> Speaker 2: [INAUDIBLE]
>> Mike North: All right questions online? So I see one saying we can have multiple interfaces with the same name.
[00:02:28] So Rob was asking that online. You can't have, when you refer to an interface of a given name. You're basically referring to the same interface over and over. So you can think of that as us modifying the same interface and adding additional properties to it. When we talk about interfaces being open, that means we can extend it, we can describe additional fields by sort of having another interface declaration there.
[00:02:56] It's not a declaration but an interface expression.
>> Mike North: So, if we find out that the interface page, wait, can we find out about the interface page having multiple interfaces with the same name before we start this? So Liz pointed out rightly. This is not the same as a Java interface in that here we can have property names whereas in Java you can only have method signatures.
[00:03:25] So that is that rightly so. It's been a while since I wrote Java. Years and years. You have a question.
>> Speaker 3: Can interfaces extend other interfaces?
>> Mike North: Yes. Feel free to use that in this.
>> Speaker 3: Syntax for that would be?
>> Mike North: Extend, like interface foo extends bar. Same thing with classes.
[00:03:44] You don't have to use that for this, cuz remember it's just about structure. So if you define another structure that happens to be a super set that we would say that like yes, that is like, one is assignable to the other in the same way.
>> Speaker 3: Right, right.
>> Mike North: Does that make sense? All right.