So we've talked about architecture. We've talked about service oriented communication which means that we have one application that actually communicates with another application, be either giving data or receiving it. But now I want to take a step back and talk about how an angular application is structured because this is going to be very different especially if you're coming from a Rail's background.

In Rails you know that everything is based in terms of the file structure. It's all based on what the feature is. I know that's a little bit fuzzy so let me kind of cleared up a little bit. I'll create a traditional tree. Say we have a Rails app right here. Here you have a directory called controllers, then you have a directory called models, and then you have a directory called views.

So far so good. It's pretty straightforward. This is a way all the rails applications come scaffolded by default. And if you follow the rails way this is way that you're going to build it. Inside of controllers you might have a post's controller and a user controller and an application controller and all of them are nested in what they actually do. So it doesn't really matter what the feature is. It could be creating a post, it could be creating an invoice, whatever it is if it's in the application and it's a controller it's going to go into the controller directory. Same thing with models and with views. So that is the way a Rails application has their set up.

Now this is completely different from the way that you do this in angular. Angular is very flexible but I'm going to follow a pattern that the angular team actually subscribes to and I think it's a smart one to do which is instead of taking this kind of approach where we nest each one of the items based on what their role is, we're going to take what's called a component based approach. Which means that we're going to look at each one of our features and we're going to place all of our code for that feature inside of that directory.

I kind of like this. It's pretty neat because what it allows you to do is really encapsulate all of your code. It doesn't feel as natural if you were to write bad code. So in other words, in a Rails application having multiple files that are communicating with each other that shouldn't be. If you have a user's controller it might be too tightly coupled with a post controller or a model file for a user and that model file for the post. It's too easy to say, oh yeah I want to have that one wired up to this other model and whenever the files are right next to each other for some reason mentally it makes it really easy to write bad code and have them communicating with each other which means that if you make a mistake in one of them or you change one of them it could have a domino effect and change the other ones or cause the other ones to break.

What we're going to do is use a component based system where all of our features are grouped together. So let's take our app again. I'm going to create another app tree but this time it's going to be different. So this one I'm going to follow with the application that we're actually building. We're not going to have models, views, and controllers. Instead what we're going to have is proposals. Underneath that we're going to have docs for our documents. Then we're going to have a home page etc..

So here, notice what the difference is. We're going to be organizing our code based on a feature driven approach. The proper term is a component driven approach and that's what angular two has completely embraced.

By the end of this course you're going to be sick and tired of how many times I've said component but it's not my fault it's because the component is actually key word that we're going to use pretty much in every guide. So everything in angular, in terms of these features are going to be tied to components. And you could take this to where it gets really crazy detailed.

So let's take a couple of examples on that. With proposals, inside of it, it's going to have its own directory. This is where our new component is going to be. So to create a new proposal we're going to have a new component inside of it. We're going to have a show component inside of it. We're going to have a list component. This is going to be the one that lists all the proposals that we get back in the API and will go down and down.

So far I've kept our components really kind of straight forward but components can be anything in an application. Pretend that you have a button that did a lot of cool stuff. You could have some kind of, we're not going to have it in this course because there is not really a good use for it, but we could have a proposal button right here and all of the logic, everything inside of it would be inside of that proposal button component. So that's one thing I really wanted to take a lecture and dedicate it specifically in talking about components because it's going to be really the foundation that our entire angular application is going to be built on. So all of our features are going to be going to reside inside of their own directories and then from there all of the logic and everything that we're going to be using from an organizational standpoint will be nested inside of those. Now they have a good idea on how we're going to create the application let's actually get in and start developing the app.