This course has been updated! We now recommend you take the Angular 9 Fundamentals course.
Transcript from the "Component Driven Architecture" Lesson
[00:00:00]
>> Lukas Ruebbelke: So component driven architecture, we're going to really just talk about component driven architecture from a high level. What that means.
>> Lukas Ruebbelke: The contract that we establish, the inputs and outputs, container components, presentational components, and then we'll dig into input and output just a little bit more. But first, story time.
[00:00:24] You can't really talk about component driven architecture without at least talking about where we came from. And so those who are new to Angular, especially Angular 2, this may come as a surprise, but things weren't always this awesome. In fact, when we started Angular, this is in like the 0.9 version, when I started.
[00:00:56] That my first experience with Angular 2 and it blew everybody's mind, neatest circus trick ever was interpolation. Basically two-way data binding and you could hook up with curly brackets, and you simply had to set a property. So technically it's not two-way data binding, but it's really string interpolation.
[00:01:19] You set a property on your JavaScript and ta-da, it renders in your HTML. At the point, or at that point in time, that was actually really hard to do. And two-way data binding showed up, I had been doing flex for quite some time. And the concept of a view and a controller really struck me as kind of a view model.
[00:01:42] It really resonated with me and so I started out and I built a tiny app with a tiny view in a tiny controller. In fact, if you go to the angularjs.org museum of natural history and you look at some of their displays, these are exactly the kind of apps that are on the angularjs.org website, very simple, single page, in the case of this.
[00:02:12] I realize they're examples, but these are the kind of apps that we started writing, like, I didn't do two a day to mind you with Ang model and curly braces. Half my work is done. Amazing. And then you move into to do apps, etc. Well anyways, I was hooked.
[00:02:30] From there, I wanted to actually do things and so the application grew, but because of that when my functionality grew, so did my view, so did my controller. Well then the next logical step is, I would like to do this for money, with people. And so this is when reality hits.
[00:02:52] You need to produce something that's not trivial, and your view just keeps growing. Your controller keeps growing. And things become unmanageable. And it gets to the point where you have a 1200-line controller. And you're now negotiating who can work on what part of the controller. And this has happened, like okay.
[00:03:17] I'm working on up to line 200, don't touch anything. And anything after that you can work on. Well, this is a real sad panda moment. And so this is actually within the first year. People were running into this problem in a big way. Is that angular taught you where to put your pieces in the application, or essentially kind of your functionality, but they didn't really tell you, or didn't really have a strong opinion at the time, of how to actually compose them together.
[00:03:47] But out of that pain, two main approaches emerged. And they both, very viable, the first one is to break your application up using named routes. So again, treating your application as a state machine, you would break your application up into named routes using UI View. And then you would break your template and your controller up into smaller pieces, and kind of put them Into specific pieces via essentially UI view or the equivalent router outlet.
[00:04:25] But notice you still have your component, or rather your template controller pair in Angular one. The next version of this was using directives. So people actually started to use their directives to break up their applications. So you'd for instance have a side bar directive where your side bar went went, content footer.
[00:04:47] But you're still organizing this into component and template pairs. It's just again, an organizational mechanism. Well, because this is where the web standards were going and pretty much every other framework, Angular 2 said using directives as components, that this is a good idea. Let's just make components the thing.
[00:05:09] And so, structure. We now have, essentially out of this, a best practice around structure, which we have been talking about and learning about for the entirety of this workshop but, also this raises the question, how do we handle communication between components? When we structure them, how do they talk, how do they share information.
[00:05:37] And so this is where component driven architecture comes in. So as we've components are small, encapsulated pieces of software that we can reuse and make different contexts, so even to a point where we had a review component, and we just put it into our DOM via the selector.
[00:05:57] And then we turned around and we loaded it via a route. Because that component is self contained, we can have it in our DOM or in our application in two different places, same component instantiating it more than once in actually a totally different way. So Angular 2, by default, strongly encourages component architecture by really making it, well, not only easy but necessary, to build out every feature in the app as a component.
[00:06:28] And, more importantly, is that it allows us to kind of encapsulate everything so that one, it's predictable, but it's portable. And so when you are on a large application, especially, so as Angular kind of grows up within kind of large teams, or even small teams that need to share functionality, or share functionality between teams, you can now pick up components, and move them, and share them.