Transcript from the "Introduction to the Container Pattern" Lesson
>> Steve Kinney: So, now we're gonna think about some of the patterns for solving this. I'd like to introduce you to the Lightning Round. We're gonna look at three patterns. And these patterns are agnostic to Flux or Redux or MobX or anything along those lines, right? When we discuss them, you're gonna be like, I remember that one from redux if you've ever played Redux before.
[00:00:25] I've seen this one over here. Cuz they are patterns that you can do with regular Redux state as well as any of these other libraries. And they have different trade-offs. They have different benefits, and we'll kind of look at each one of those and kind of discuss them.
[00:00:39] So here's the deal. Each stage of the Lightning Round, there are three parts to the Lightning Round. It's gonna have the same flow to it, which is, I'm gonna talk about the pattern. Then I'm going to get to do a simple example and then you're gonna get to do a slightly more complicated example.
[00:00:56] And then I will do a slightly more complicated example to kind of clear up in case anyone gets stuck along the way. And the important part is, once we have these patterns in our vocabulary, we'll be able to revisit them and play with them when we get to Flux or Redux.
[00:01:13] And some of them will come for free in some of these libraries, and we'll see them along those lines. So, let's start with the first one. Lifting State, what's called the container pattern. And the Container Pattern has a very sweet savor, and this is true actually of all three, but this would be the first one that we see.
[00:01:29] Where it draw's a line between state and presentation. Right. And this isn't like, a lot of take this for granted at a certain point, that we might have things that are managed over the state and things that manage the presentation. I mean that's effectively two parts of NBC, right?
[00:01:43] [LAUGH] The model and the view and the control and the coordinate between the two of them. But if you look at some of that original react documentation, one of the selling points was that your state is encapsulated in your view objects. This is not kind of the original like, a sales pitch for react.
[00:02:00] But we now know that this idea of like, just components that take prompts and show stuff and don't have any state of their own. And we saw that in some other texts about components that hold state and can pass it down into prompts. And this has a lot of really great advantages to it Right?
[00:02:18] The presentational components just receive prompts and render UI. And one of the great things about this is, this makes it incredible easy to test. You can theoretically take a, what we'll call a stateful component. A component that has state and also has presentation. And you can load it up in Enzyme and you can mount it and you can trigger a bunch of stuff and you can check things.
[00:02:38] But it's really easy to test a component where, based on the propmpts it receives, it comes out the other end like this. It becomes incredibly easy to test. If the state of my application is in such a way, this component will definitely look like this. And you can just write a unit test where you pass in that state, and you expect a component to look a certain way.
[00:02:59] Clearly those presentational components in the name, present themselves to the user, right? Which means they are going to be the ones that the user clicks on and changes, and stuff along those lines. So, they do need a way to be able to communicate back up to the container.
[00:03:16] Right? The container holds all the state and can modify the state. And the presentational component is gonna receive those call backs. And we did a little bit of this. We saw in the individual items. The individual items, didn't really manage their own state. They received from either the items list and eventually the application, right?
[00:03:34] They were effectively presentational components. So we did it, we were starting to use this pattern a little bit, but this is kind of a different way of thinking about it. So, they either, the idea of a presentation component, you know, only has a render method. Or it's what we call a stateless functional component, which is just a function that takes prompts and returns some JSX.
[00:03:54] Personally I used to be all about the function that like, returns some JSX. I am now I am sold on the all render. Cuz remember when we saw like, hey it's great to have class, to have instance methods that take some helpers like, full name and pull it out of the render function.
[00:04:14] If you need one of those you can just add it onto a class. Versus, if it's a presentation component, you have to do a re-factor. You have to change it into a class. If you wanna keep track of this, and stuff along those lines. I'm gonna stick with using class, the name of the component, extend this component, for most of this.
[00:04:32] Just a render method. If that's not your style, You don't have to, we'll see a little bit of both in some of the examples, but that's kinda gonna be in mind. But just in case you've never seen the stateless functional component before, this is effectively what it looks like.
[00:04:45] It literally is just an arrow function. Prompts go in, component comes out. There's no this stuff's at stake, everything this component needs is passed to the component. So this would be the presentational component in this case. What would the container component do? So this counter container, at this point I put two counters in here just to show that they both get the same state and you just see two of the same counter on the page, which is kinda silly.
[00:05:14] But I could fit in on a slide, so it's what I went with. All this component does effectively is keep track of the state, have the method that allows the state to be modified, and passes that down into the presentational component. It doesn't actually show anything itself. It's just showing these presentational components.
[00:05:34] So let's actually implement this. We're gonna get to something what looks very close on the slide. But I'm gonna show you the process of refactoring that basic counter that I forced you to make before. And I'm going to then move it to a container pattern. And then we'll take a slightly more complicated example.
[00:05:49] You'll do it, and then I'll go over it. And we'll do this for all three of the patterns that we're going to see. Cool.