Transcript from the "Review" Lesson
>> Steve Kinney: So we've got it wired up in that case, and we can do it also for NewItem. If you recall, NewItem was getting a method passed into it as well, that we don't need to do anymore. So let's go into that one as well.
>> Steve Kinney: So here, we're going to take in the onSubmit from this.props that we're receiving from application.
[00:00:22] But we don't need to do that anymore, right? We can receive that from the actions.
>> Steve Kinney: Actions, just verify that I called it addItem. Cool, so now addItem, really just needs the value, cuz we're doing the rest of it in there. So we can get rid of this that was passed in from the outside world.
[00:00:53] And we can change this with
>> Steve Kinney: AddItem value, right? We're getting that directly from the store, we don't need to necessarily do that in this case. For the application itself, it does make sense, because we are splitting it between the two item lists. It is like a rational place to do it.
[00:01:17] There is a refactoring that we might try to do tomorrow morning where we could break that out a little more. But let's start with the simplest possible thing, which is to register that with the store to get the state. And then we should have the basics up and running at this point.
[00:01:31] So we go to application and we don't need this default state anymore, so get rid of that. Deleting code is the best. We know that the new item can handle adding items itself. We know that the individual item can handle that. MarkAsPacked which is we call title item, that we don't need to do anymore.
[00:01:53] This markAsUnpacked is responsibility of the application component cuz it has all of the items from both lists in this case. So we know that we need that here, unless we broke that out into it's own component, cuz we can do that. We can bring in the store there, we could parse in all the items, just lke component.
[00:02:09] We have a lot more flexibility with how we break stuff apart, without having to worry about parsing everything down all the time. Let's just make this a no op for a little bit, because we aren't actually gonna set the state here anymore.
>> Steve Kinney: Cool, and so we'll just say the defaultState is gonna be itemStore.getItems.
[00:02:29] And what we'll do is we will say, onComponentDidMount.
>> Steve Kinney: Yeah, I was like, where's my auto complete? [LAUGH] onComponentDidMount, we will,
>> Steve Kinney: Whenever it changes
>> Steve Kinney: Update. Nope.
>> Steve Kinney: UpdateItems and we don't have that method yet. And then,
>> Steve Kinney: ComponentWillUnmount, we'll take it off.
>> Steve Kinney: And what we'll do is we'll say,
>> Steve Kinney: UpdateItems
>> Steve Kinney: And we'll say this.setState
>> Steve Kinney: and the items will be ItemStore.getItems.
>> Steve Kinney: Alright, and so we don't need this in the state anymore. We do need that one, we have this. What we don't want is, this now can handle itself, it doesn't need to be parsed in.
[00:04:08] This now can handle itself, it doesn't need to be parsed in. Same
>> Steve Kinney: Let's see what we got.
>> Steve Kinney: Let's go pack some cheese.
>> Steve Kinney: Check that one out in a second, see the other ones, all right so
>> Steve Kinney: It's fun. All right, so we're getting an updateItem.
[00:04:44] We're getting them in the store.
>> Steve Kinney: OnComponentDidMount. I'm a little worried about, cuz just componentDidMount.
>> Steve Kinney: When auto complete doesn't work, it's probably your fault.
>> Steve Kinney: Cool, we can remove one. We can add one. We can check them off, back and forth. We've now separated our state management from the component hierarchy.
[00:05:28] We can give each component what it needs. Tomorrow morning, we're gonna look a little bit about a tiny re-factor that we can do. And then we'll talk about other ways to do this. Cuz there's a lot to be desired, even from the flux pattern, right? We have stuff in closures and we're still pulling it in module state.
[00:05:48] Whenever you're doing that it becomes a little bit harder to test than if it's simple, things come in, things go out, right? And so we'll look at a way to just have a very simple pattern of pure functions where the state of the world, and an action go in, a new state of the world comes out.
[00:06:04] We're not necessarily always modifying by hand in a closure scope. All right, so kinda look at that. What happens if we have multiple stores? Flux has ways of waiting for one store to do its thing before doing the other one, but it's not optimal, right? So we'll look at some options beyond just flux for managing state outside of the component hierarchy.
[00:06:26] But we today managed to accomplish pulling that off. Beginning with suffering from passing stuff down and again, in a relatively small application still feeling the pain a little bit. Figuring out some patterns that give us flexibility to swap out different approaches. And then pulling our state management outside of the component hierarchy.
[00:06:45] All right, so we accomplished all those things today, which I think is pretty good.