Angular 13 Fundamentals Breaking Shared Mutable Components
Transcript from the "Breaking Shared Mutable Components" Lesson
>> What I'm going to do is in my course-details.component, guess what we need to do is we need to break the if it's shared immutable, we need to make it shared or mutable. In this case, we want to break the sharing portion of it. So, I'm going to, Change this to, Course and I'm going to update this a little bit so that we're going to turn this into a setter method.
[00:00:53] So, If there's no value, return, but if there is a value, We're going to, Now go this.currentCourse =, Value and we're going to set original title. So we're basically taking, And, Doing what we did in the parent component and we're moving it down to here. So this.originalTitle = this.currentCourse.title.
[00:01:45] We'll set this here and let me go back into my container component and, Here we go. If I type this in, and so we've broken the shared mutable relationship. And then if I go back to the course-details.component, then I can reset this to originalTitle and we are good to go.
[00:02:27] Let me refresh this. Here, holla, so it's updating here but it's not updating the title, more importantly, is it's not updating the object in the list because they're not the same object. And now what I can do is if I wanna cancel, it just throws those mutations away, no big deal.
[00:02:52] Or if I wanted to update this, then I should be able to go Save, and it's updated. Also interesting is that, if I'm not mistaken, the, I think this also updated it, the REST API. So we've actually done a lot of work in a very short amount of time.
[00:03:23] And so just to review. So how can we tell a container component from a presentation component? Well, thank you for asking. This is a pretty good indication that this is a presentation component. Now, what's cool about this is if a unit test exist to test logic, how do you test a component that doesn't have any logic?
[00:03:59] Well, the answer is you do not, at least not via unit test. There's nothing to test here that not only have we simplified the code volume and flow control, meaning we know exactly what the data is coming from. We know exactly where the events are going. But we've also eliminated the surface area in which we need to test, which is really, really, really amazing.
[00:04:31] Now, if we look at our course-details.component, there is a little bit of logic in here. But it has nothing to do with application state. The logic in this component is entirely self-contained and related to presentation state. And so this is also a very, very, very small clean component.
[00:05:02] Now, if you look at the container component, on the other hand, you'll notice that its template, all it's doing is attaching presentation components to the DOM. So it is purely for layout. But then if you look inside of the methods inside of your container component, this is where we're pulling data in.
[00:05:32] And where we're pulling data in, as well as if something happens, then we're issuing a command out. Now, let me just show one thing real quick. And this is, right now we're unpacking our courses and assigning the result to a local member. What I can also do is I can just define, An observable stream that has essentially an array of course objects.
[00:06:28] And from here, what I can do is, I'm just gonna save this off, and I can go this.courses$ = this.coursesService.all(), like so. And, Let me see if can get this to tick. I think I need to do this. Let's see if I can loosen this up just so I can get this working.
[00:07:56] This is what I do when I need to get it working or tighten up the typings later, is that now what I'm doing is I'm saying, give me all of the courses, but we're still keeping it in reservable stream. So if I go back here, obviously nothing is happening.
[00:08:17] But if I go into my courses template here, what I can do is, Pass this in this way, and I am really, really hoping that this renders. So now what's cool is you can see here that inside of the code, I am no longer required to unpack this inside of my container component.
[00:08:59] What I am doing instead is just preserving the observable stream and then using the async pipe, just pushing this into the component, which then it now gets unwrapped. And put into the courses list as a collection of course objects. So that concludes my component-driven architecture demonstration. I yield the floor to Mark to answer any questions that anybody has.
>> Do you recommend to change the detection behavior in the presentational component?
>> I recommend that, I think that's a prudent move. For a small application, it's not always necessary, but for large scale applications, I think turning change detection off, it makes sense. And so I know for large applications, because a lot of this is being handled by the observable stream, that it's pushing data out in.
[00:10:15] So Angular is not having to like, I don't know when data is coming because the observable stream is handling it. That there have been, I know certain applications that they've turned off change detection and allowed the observable streams to handle it. And they've seen phenomenal performance increases as a result of that.
[00:10:35] So, I think, for large-scale applications, you can absolutely turn off change detection because there's really no need to do that, because the observable stream is handling the flow control concerns.