5.1 Creating the Front-End Models

Now we're gonna be switching gears a little bit and moving to the front-end of our Angular application, the A part of your mean.io application. Now, at this point, you might be saying, okay, we can jump in and start creating the UI, and you could do that. But typically, when I'm creating an application like this, and I've done all this work from the back-end and moving up to the front-end. At this point, I've probably already created some models on the back-end to talk about whatever the domain of this application is. And we've already done that, we've created this concept of a lawn and of an application, and that is a living thing on the back-end. So the first thing that I like to do is I like to take that kind of concept and translate it into something that I can use on the front-end. Because that's where I'm gonna be needing to communicate with the back-end using a very similar object structure for a lawn, for an application. And I'm gonna need that model structure so that I can deal with it in my TypeScript within Angular, not only to just be able to represent that information, but I also wanna be able to use that in my service that I'm gonna use in Angular to communicate with the back-end. Now, I know that sounds like a lot, but it's actually quite simple. So let's go ahead and go through that process. So like I said, what I wanna do is I basically wanna mirror what it is these models look like on the back-end for lawn and for application, and mirror those things as models on the front-end. So how do we do that? Well, I'm gonna go into my source directory here, cuz remember, that's where our Angular app lives, and I'm gonna go into app. And so within here, I want to create a new folder, so I'm gonna create a new folder and I'm gonna call this models, quite similarly to how I did for the back-end. And then within here, I wanna create some TypeScript classes that are gonna be used to represent the same information for the lawn and for the application. So we will come in here, we're gonna create two files. The first new file is going to be Application.ts. Now, remember, we're gonna be using TypeScript on the front-end for our Angular application. So we have Application.ts, and then we're also gonna create another file here called Lawn.ts. So we're gonna be using application in Lawn. So let's go ahead and start with Application. So this is gonna be pretty straightforward, it's gonna be very similar to what we did for the back-end. We're gonna export interface and we're going to call this Application. And then within here, we need to give this a definition. So in this case, we are going to say that we want to have a name because we had a name before, and that's gonna be a string. And we are gonna have a date, and this is going to be of type date. And then we're also gonna have an amount, which is gonna be of type number. And we're gonna need to put a space on the end here. But now, remember, as I said before, when we're dealing with Mongoose and the MongoDB, when we're creating new instances of this application in the database, where I've the lawn in the database, it's going to, behind the scenes, create a unique identifier and assign it to that particular object. And so we wanna have that In place here for application as well as in lawn, even if it's not there yet. Which means we gonna have to create this and at least put it in there and make it so that it's optionally there. So we can use it if it's there, but if it's not there, we don't have to worry about it. So we're gonna put that in the top here. And remember, as I kinda mentioned before, in MongoDB, when it creates that ID, it's gonna be _id. So let's go ahead and mirror that same thing here. We'll say _id, and that's gonna be of type string because in MongoDB the unique identifiers, by default, are gonna be known as object IDs, which are actually GUIDs but they're just referred to as object IDs. So in this case, the closest representation we have for that on the TypeScript side in Angular is going to be a string. Now, remember, this is not always gonna be there because if I haven't saved this yet, it's not gonna be populated, so it's kind of like an optional. So i'm gonna do the same basic thing here by adding in a question mark to say it may or may not be populated. So that's just kind of another way to identify that. So let's go ahead and save this. So now we have our application class here ready to be used as a model. And now we wanna do something similar for lawn. So we'll go ahead and once again do another export statement. And we're gonna export interface, and this is gonna be Lawn. And we´re gonna do the same thing, we´re gonna have an ID for this, which may or may not be populated, which will be a string. Then we´re gonna have a title for this, which is once again going to be a string. We have our address, that´s gonna be a string, and then we also have a size, which is going to be a number. Now, we also are gonna have this concept of applications. And recall that the applications are actually going to be an array of application objects. So I can say application, and it's gonna be an array here, and I wanna bring that in. And so when you're using Visual Studio code, if you are referring to a type, in this case application, that Visual Studio code can find somewhere within structure of your application here. You can sometimes get away and use the command period shortcut if you are on a Mac, and you would able to see that what I wanna do is I want to import application from module application. And then it'll go ahead and bring in the appropriate reference at the top of the file. And the reason it's complaining here is because the TSLint wants to see single quotes, not double quotes. And then the very end here, this is complaining because it's saying there should be a new line at the end of the file. So the reason those things are showing up there is simply because when we created our application, it gave us this default tslint.jason which is showing the configuration of all the Linting rules that it's really taking advantage of and that it's enforcing on us. So you can once again go in here and you can kind of replace these or change them to be whatever you want so you either get those squigglies or you don't. It really doesn't bother me too much. I like to be consistent, so I usually just leave the defaults in there, unless there's really a reason for me not to. So now I have this Lawn.ts file and I also have this Application.ts file. So now, anywhere in my Angular application, I can be talking about a lawn and the applications that have been applied to the lawn so that I can use the same terminology on the front-end and as I was doing the back-end. So now that I have this, let's go ahead and start to take this to the next level and start to create the service that's gonna be using these lawns and applications to speak to the back-end in Express that we just finished completing.