Transcript from the "A Brief History of Angular" Lesson
>> We are going to talk about [SOUND] my favorite subject in the world, component driven architecture. And one of the things that I want to call out here is that when it comes to application development, there's a quote that I have in the testing slides about complexity. And one of the things that they're talking about is that complexity comprises of really three main things, managing of state, flow control, and code volume.
[00:00:43] With managing of state being kind of the primary driver for complexity and then control flow and code volume being kind of like byproducts of our inability to be effective. And what I like about component driven architecture is that it kind of a mezzo or kind of mid level range, it allows us to manage complexity between components by managing state flow control and code volume.
[00:01:20] In a micro level, I believe that observable streams handle complexity very, very nicely in these really tight, small, encapsulated, observable streams. And at a kind of a macro level that this is where like NGRX comes in and handles very, very, very, very nicely manage the state flow control and code volume.
[00:01:45] But you'll see here as I talk about this that within a microcosm, this is representative of an approach that is effective at a micro level, mezzo level, macro level, and even I guess universal level, if you will. But it's when we talk about component of an architecture, just know that it's kind of it foreshadows or it is a pattern that has a lot of implications outside of just component communication.
[00:03:32] That I think I haven't been to the AngularJS site in a long time, but in just a couple lines of code I was able to define a property and then bind to it in my HTML, change that property, and the HTML would automatically update, that was like a really big thing a couple years ago.
[00:03:53] Being able to have two way data binding that just worked was a really, really kind of a shiny cool party trick. And so you had a tiny app that really consisted of a very tiny view and a tiny controller. Then in my case, I decided I wanted to make money with this possibly even move to Hollywood and make movies about this.
[00:04:19] And so my application started to grow with my aspirations and eventually I got the green light to do AngularJS for real, for money, and so I'm just in my mansion in Malibu, and I've achieved everything that I want. And I'm laying there in my bed with my snakeskin rug, and I realized that like I'm dying inside that in all seriousness that these applications had grown to where what seemed to be like this really cool novel thing is we had essentially painted ourselves into a corner.
[00:05:08] So yeah, we kind of had this huge mansion in Malibu style application but it was just on tenable. So back to me laying in my bed and my snakeskin comforter. And I was in a problem, we were in a problem that this was a real issue, at least within the AngularJS community is what do we do about the fact that we're writing applications or we have one view, one controller, and they're literally I've seen them like controllers that are 5,000 plus lines of code.
[00:05:44] How do you work with that in a team to where it's like, okay, you need to work in the first 1,000 lines, and I'm gonna work in the last 1,000 lines and don't touch anything else. So it was almost like if you've ever done any real time document editing on my Google Docs.
[00:06:00] That's kind of what it felt like, but with code that had to compile and work. So let's just take a moment. Let's appreciate this because that's the place that we found ourselves in. And there emerged two kind of reasonable approaches to this. The first one was to create named routes.
[00:06:22] And so you had these named router outlets, if you will, in your application, like maybe like sidebar, content footer. And what that would do is then load in a controller and a template. So you still had that pair, but it was going into a route. And another, I think more that gained more momentum over time was to just create directives that would encapsulate certain functionality that you would then attach to pieces of the page.
[00:06:56] So you would have like a sidebar directive, a content directive, which was in a way it just kind of foreshadowed where we ended up with angular with instead of directors, we used components. So any angular application, and if I'm being honest, I believe that this is pretty much like any react application and probably any view application, potato, there might be some differences, but I know at least when I write react, this is the same exact approach that I take.
[00:07:30] In fact, a lot of the ways that we think about components is because of the work or the innovations that react did in that space. So I pour out champagne on the ground him for the react team for really bringing components front and center into the public consciousness.
[00:07:49] And this helped us solve a couple of things, one, the problem was structure as well as the problem with communication. So remember, complexity is mentioned of state, flow control, and code volume, and by solving the structure issue, that it helped alleviate some of the code volume problems. But also by giving us a clean way to structure our code but then establishing ways for us to communicate, this helps solve a communication problem which falls firmly under the flow control category.