Check out a free preview of the full Building Awesomer Apps with Angular course:
The "Container and Presentational Components" Lesson is part of the full, Building Awesomer Apps with Angular course featured in this preview video. Here's what you'd learn in this lesson:

Lukas reviews container and presentational components. Container components are connected to services and know how to load their own data and persist changes. Presentational components are defined by their bindings. Lukas takes questions from students.

Get Unlimited Access Now

Transcript from the "Container and Presentational Components" Lesson

[00:00:00]
>> Lukas Ruebbelke: Imagine you have a component, with a child component, and you have this very clear line of communication of inputs and outputs. Now let's expand this mental model out. So, you could have a parent component that has multiple child components within it that communicates to the children components via inputs and outputs.

[00:00:27] So based on what I'm saying, I think this model right here, this kind of simple diagram, is pretty easy to wrap our minds around. Of course, we have a parent component like home and we start dropping things into it and from there, we can start communicating to those children components via inputs and outputs.

[00:00:47]
>> Lukas Ruebbelke: Well, this is called Container and Presentational Components. And so how this works is you have a container component that serves as well a container. So what it does is it's responsible for consuming the data that that feature, if you will, needs. And so it does very little layout, it's simply concerned with essentially getting the data and satisfying the dependencies of it's children components.

[00:01:25] So I think of, really, a container component as the kind of the air traffic controller. So they know how to load the data, they know how to persist changes, and when an event happens within a component from a child component, it gets delegated up and they know how to actually communicate outside to the services.

[00:01:49]
>> Lukas Ruebbelke: Presentational components, on the other hand, they're generally stateless and fully defined by their bindings, and this is amazing. So all data goes in as inputs, gets immediately rendered in the template, and every change comes out is an output. And so the idea is create as few container components as possible, and as many presentation components as you can.

[00:02:19] So what I would usually do, I would usually organize my application by feature, and I would do a feature, or a route, for every feature. So if you go into widgets, then you're gonna load a top level widgets component, which is a container component. So if you actually look at the items, and how I've done that, this is how this works, you have an items route that routes to an items component.

[00:02:44] The items component being a container component is responsible for basically pulling in the data from the service, and when something happens, communicating back to the service that something, like, hey this thing happened, go do this thing, persist it. It then communicates state and events to the children components.

[00:03:07]
>> Lukas Ruebbelke: So, this is a completely valid presentational component. Totally functional, and this component class is completely defined by its bindings, there is zero logic in this component.
>> Lukas Ruebbelke: This is very, very stable.
>> Lukas Ruebbelke: Even to the point, the question is how would your unit test this?
>> Lukas Ruebbelke: I mean, unit testing, by nature, is you're testing a unit of logic.

[00:03:51] What do you do with a component that doesn't have any logic? It's just going to work the same every single time, because there's no moving parts. And unless angular is broken, or you're passing in some bad data, there's a bad assumption further up the stream, this will work the same way every single time, complete referential transparency.

[00:04:17] So now, having components that are so simple that you do not need, it's actually hard to test at a unit level, I would not even try to unit test this, I would do end-to-end testing, or integration testing. This reduces the possibility, or the footprint, for something going wrong.

[00:04:40] So I mean this is kind of the equivalent of, I have a real bad habit of I love delicious food, and so if there's junk food in the house, I'm gonna eat it. So how do I keep myself from eating junk food? I don't buy it, I don't bring it in the house.

[00:04:52] Same thing is, if there's logic that's gonna go wrong, the best way to fix that problem it's get rid of it. That's some one of the best test you can write, is the test you don't have try, because its logic doesn't exist. And a
>> Lukas Ruebbelke: Container component, so the items component is kinda the poster child for this.

[00:05:16] This is responsible for pulling in the item's service, and communicating to that service to persist the changes to the backend. Let me see here,
>> Lukas Ruebbelke: So, the question is, if you want to get data from a child component to another child component, how does that work? Well, one child component emits it up to the parent component, then the parent component is responsible for sending that back down to the other child component.

[00:05:48] So, the container component serves as the air traffic controller, or the communication control center, for communicating state to children.