This course has been updated! We now recommend you take the Angular 9 Fundamentals course.

Check out a free preview of the full Build Web Apps with Angular 2 course:
The "Smart & Dumb Components" Lesson is part of the full, Build Web Apps with Angular 2 course featured in this preview video. Here's what you'd learn in this lesson:

Smart components are connected to a service and know how to load data and persist changes. Dumb components, on the other hand, are fully defined by their bindings and flow data through their @Input and @Output decorators. Lukas recommends building as many dumb components as possible.

Get Unlimited Access Now

Transcript from the "Smart & Dumb Components" Lesson

>> [MUSIC]

>> Lukas Ruebbelke: Let's talk about smart and dumb components. I'm going to actually start with dumb components and that is a dumb component basically gets everything that it needs to render delivered via input and it doesn't handle any logic, it just defers backup to its parent via output. And so this is what a dumb component would look like.

[00:00:29] And when I achieve this, it's a fist pump in the air moment for me. That this thing, this items list component, as long as I get the template correct, the opportunities for this thing to go awry is pretty slim, because it's not really, so it's being delivered state but there's no opportunity for one to mutate state, there's not logic for it to introduce bugs into the application.

[00:01:01] It's very simple. With that, you can pass this around and you just know that if I get an items array, or an array of items, and I call or put on the component a handler for selected and deleted, then this thing is going to work. And so this is a dumb component as opposed to a smart component, which would be in this case our top level application.

[00:01:30] I believe actually in the sample code I broke this out into a top level items component. But this is your smart component. It actually has some logic in it. That is responsible for interfacing with services and it kind of coordinates what's happening underneath of it. So the idea is you want to create a few smart components and as many dumb components as possible.

[00:01:58] And what this does is it reduces the area in which things can go wrong in your application. Kind of what I would say your testable surface in your application. Because now, everything is going up into these kind of top level components that are responsible for delegating to appropriate services.

[00:02:18] So again, create a few smart components. So where I was talking about the screen or the graphic where you had those boxes on the stage, those generally I think of these are containers. This is a smart component. And then it's responsible for coordinating the dumb components underneath of it.

[00:02:36] Then once we get into NgRx tomorrow, you'll see that we're even going to make that surface area even smaller by pulling our entire state into a single application, or single JavaScript tree within the NgRx store. But again, with Angular 1 there's a real problem of I had this, I'm calling the service, I'm getting some information and I'm storing it in my controller, and when I make a change, then I basically have to find some way to communicate this back to the controller, or to the service so that it can tell the rest of the controllers and hopefully not break anything.

[00:03:11] With angular2, by creating smart components, you are minimizing local state, which is great. Then once you've taken a step further into NGRX and the redux pattern, then it goes into a single-state tree, and it's even harder to break your application and it's much easier to test.
>> Lukas Ruebbelke: Are there any questions about that?

[00:03:37] So really, this entire module could be summed up as you have a component, it gets what it needs in, if it needs to do something, it uses output to delegate that to its parent component, and that is. It's smart component is the parent container, and you want to have as many dumb components that are just simply inputs and outputs.

>> Lukas Ruebbelke: Interestingly enough, I think that when you talk about this, I've been talking about this for maybe 25 minutes, it seems almost like I'm belaboring this point. But coming from Angular 1, this idea did not really exist, and I still see a lot of people approaching their 1 apps where they're okay sprinkling state, they don't have clear encapsulation and paths for their application to talk to each other.

[00:04:30] With Angular 2, it took me not too long but I realized I have to shift my entire with thinking and see everything is these blocks that connect onto each other via input and output.