This course has been updated! We now recommend you take the Angular 13 Fundamentals course.
Transcript from the "Wrapping Up" Lesson
[00:00:00]
>> Have to feel like there has to be some questions in the live audience here.
>> What was the difference between that event emitter from the Angular core and events and the other one?
>> So the question is, what was the difference between the event emitter from Angular core or events or even Protractor.
[00:00:25] [LAUGH] Unfortunately, it's the same name, it's a totally different implementation, and so it just doesn't work. And so you'll emit this event, and Angular will go, I don't know what this is, and it'll just explode.. Which is embarrassing when you're trying to do a product demo. Or something where this should be working, and you realize you've done the wrong import, or just pulled it from the wrong place.
[00:00:47] So that's the difference, is one works and one doesn't.
>> I guess a curiosity thing for me that you might've touched on already, but subscribing to observables, is that a component thing or a service thing? Is there a preferred place for that?
>> So the question is, when I subscribe to an observable stream, is there kind of a preferred place to do that?
[00:01:24] And, There's a couple of things that you could do that we didn't get to today. One thing you can do Is you can actually take an observable stream and run it right into the template using an AsyncPipe. And so generally the general consensus is, is once you have an observable stream in your component class, that you don't unpack it in the class.
[00:01:52] You can, but it's actually more efficient to just put it into your, just run it right into your template using the AsyncPipe and it will unwrap it for you. And so I think there's a possibility we could possibly get into like Reactive Angular, and talk about that where we would definitely talk about state management.
[00:02:13] But that's one of those things that comes in is, you can either do it within like a service that manages that state. Or if you're piping the stream into a template, then you actually run through the component into the template and unpack it. So that's kind of where that goes.
[00:02:35] I'll either run into the template or I'll have a specific class that handles those side effects for that. So another question that Noah had, and the question is, so Noah's learning React, and he wanted to know, other than batteries included, is there anything that sets Angular apart? So I will say it's a nontrivial detail, is that you get everything just packaged up into this single thing.
[00:03:13] That's in terms of large-scale development, that's really, really handy. The other thing that I think is important for Angular Is that one, observable streams are baked right in. And so the things that I like most about Angular actually are not part of the framework by design. TypeScript, observable streams are, I think, really, really, really powerful, and I think they're fantastic.
[00:03:41] Now, In terms of choosing one framework over the other, I find that people that are classically trained, such as Java or .NET, especially .NET developers, because Anders, who created C# also created TypeScript. Is that if you know C#, it's really easy to make that leap into TypeScript. Whereas somebody who has maybe come up from a JavaScript kind of a background, some of that structure and different things is going to be weird.
[00:04:10] And so that's where I think it depends on where are you coming from, and what is the skill level and the comfort level of your team? So in React, for instance, you abstract everything out of the DOM. And it's done in JSX, which is really just a layer on top of JavaScript.
[00:04:29] For me, that feels just a little unnatural. I think having a DOM is very good for very specific reasons, and I don't think you should throw it away. But at the same time, React does a really good job. And the other thing is like, what about Vue? Well, for instance with Angular, it's kind of all or nothing a lot of times, it's kind of pre-Elements.
[00:04:55] Or Elements are the kind of the Angular like native components that you can generate. And so I've had situations where it's like, I just need to update this one little thing on this page. Well, I'm not gonna generate an entire Angular application to do that. And so that's where I think Vue comes in really nice, cuz you can just shoehorn that in and you get that functionality.
[00:05:14] With that said, is I think every framework in terms of parity, again, I'm not trying to alienate Amber, I would say even or even actually Dojo, which not a lot of people talk about. But all of these major frameworks have parity. And so one is I think not leaps and bounds ahead of another one, they all pretty much do the same thing.
[00:05:33] It's what are you most comfortable with and what kind of resonates with you philosophically and feels right for you, as well as your team? Another question here, Camilla asked, I noticed you weren't using any types even though we're using TypeScript. That was purely for velocity. That was just so that I could get three days' worth of material into a single day, which obviously I wasn't quite successful.
[00:06:07] But generally given enough time, I would go back and create interfaces and custom types. So just because I didn't do that doesn't mean I don't or do not believe in it. And so definitely, if we had another day to expand on this is, I would actually go and create interfaces for everything.
[00:06:23] So then as we pass it around, there's that type safety. So Jordan asked, when you unit tested, you mentioned that components that don't handle logic are solid, less prone to breaking. When you have many levels of logicless components, how would you go about unit testing them? That's [LAUGH] a really good question.
[00:06:44] So we have a bunch of logicless or presentation components, how do we unit test them? Well, the answer is, you don't. Now pause, and if somebody just ended the video and just like, we're done, he would get the wrong idea. I believe in really testing your components, but by removing units of logic, you don't have anything to test.
[00:07:10] So now you move that burden into end-to-end testing. And so you still test it, but you just don't do it at the unit level. Instead, you move it to end-to-end, which then allows you to test whole features and whole workflows versus single units of logic. And that's the other piece, is that when you unit test, you really wanna focus on very small, fine grained pieces of code to test.
[00:07:35] Versus just these kind of large things that you're trying to test, and being able to just dial in onto a single piece of logic versus kind of a large thing. And so I think a lot of times people approach their unit testing like they're testing the feature. And instead of just trying to test even just a couple lines of code.
[00:07:54] So the answer is, you don't unit test it, but you do end-to-end test it. And so you just are moving that burden of validating correctness further up the chain. All right, let me see here, do we have any other questions?
>> How would you go about refactoring one of those modules to be lazy loaded?
[00:08:15]
>> If we go into a app-routing.module, We have courses, so in master, courses is lazy loaded. And so if we step in here, you'll notice that I have a CoursesModule. And so that's the first thing is you say, I have this component, I need to put it in a module.
[00:08:41] From here, then when you do the path, you call loadChildren, and you essentially import that module. And then you basically unpack the CourseModule there. And so when it goes to this, essentially what happens is it's now doing this asynchronous call. So when you go to courses, it's saying, I need to import this.
[00:09:07] And when it's done, I need to unpack the CoursesModule module and make it available to Angular. Does that make sense?
>> Yep.
>> Yeah, so essentially you're just treating it as a module. You're doing an asynchronous call, which is you can see this .then. So this is actually returning a promise, which is a bit odd.
[00:09:33] And then it's saying within this module, go and unpack this LoginModule or the CoursesModule. So here it's just going to grab this and then make it available. Thank you so very much for spending a day with me learning Angular, it's been awesome.